Coding mode decision based on color format

Abstract

To provide a method of video processing for use by an image or video bitstream decoder to improve the quality of decompressed or decoded digital video or images.SOLUTION: A video processing method includes determining (2142) the applicability of a partitioning scheme to a current video block according to a rule for conversion between a current video block of a video and a coding representation of the video, and performing (2144) the conversion on the basis of the determination, and the rule specifies that the determination determines applicability on the basis of at least one of the mode type used during conversion or the dimensions of the current video block. The partitioning scheme includes binary tree partitioning and / or ternary tree partitioning.SELECTED DRAWING: Figure 21D

Description

[Technical field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application is a divisional application of Japanese Patent Application No. 2022-513853 based on International Patent Application No. PCT / CN2020 / 112974 filed on September 2, 2020, which claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 103959 filed on September 2, 2019. The entire contents of all the above patent applications are incorporated by reference.

[0002] [Technical field] This document relates to video and image encoding and decoding technologies. [Background technology]

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

[0004] The disclosed techniques may be used by any video or image decoder or encoder embodiment in which reference pictures are used in video encoding or decoding.

[0005] In one example aspect, a method of video processing is disclosed, the method including: determining intra-coding characteristics of a video domain based on a color format of the video according to a rule for conversion between a video domain of a video and a coding representation of the video; and performing the conversion according to the intra-coding characteristics.

[0006] In another example aspect, another method of video processing is disclosed that includes performing a conversion between a current video block of video and a coding representation of the video, where the coding representation conforms to a format rule, where the format rule specifies a syntax element modeType indicating a coding mode of the current video block equal to either MODE_TYPE_NO_INTER to restrict use of inter coding modes for the conversion, or MODE_TYPE_NO_INTRA to restrict use of intra modes for the conversion.

[0007] In another example aspect, another method of video processing is disclosed, the method including performing a conversion between a video and a coding representation of the video, the coding representation conforming to a format rule specifying that if a chroma format of the video is 4:2:2, 4:0:0, or 4:4:4, then a flag indicating a prediction mode constraint is not included in the coding representation.

[0008] In another example aspect, another method of video processing is disclosed, the method including determining whether and / or how a restriction on a size of a minimum chromintra prediction block to a video domain is enabled for conversion between a video domain and a coding representation of the video according to a rule, and performing the conversion based on the determination, the rule depending on whether a color format of the video is 4:2:0 or 4:2:2.

[0009] In another exemplary aspect, another method of video processing is disclosed. The method includes: determining whether a restriction on a size of a minimum chromintra prediction block to a video domain according to a rule is valid for conversion between a video domain of a video and a coding representation of the video; and performing the conversion based on the determination, the rule being dependent on a color format of the video and / or a width (M) and height (N) of the video domain, and the rule further specifies that for a video domain that is a coding tree node having a BT (binary tree) partition, the restriction on the minimum chromintra prediction block is invalid if 1) the color format of the video is 4:2:2, and 2) the multiplication of M and N is a value from a set of values, the set of values ​​including 64.

[0010] In another example aspect, another method of video processing is disclosed, the method including performing a conversion between a video domain of the video and a coding representation of the video, the coding representation conforming to format rules that specify values ​​of syntax fields in the coding representation for a 4:2:2 color format of the video, subject to a constraint on a minimum chroma intra-prediction block size.

[0011] In another example aspect, another method of video processing is disclosed, for conversion between a current video block of a video and a coded representation of the video, the method including determining applicability of a partitioning scheme to a current video block according to a rule, and performing the conversion based on the determination.

[0012] In another example aspect, another method of video processing is disclosed that includes determining, for a conversion between a video block of a video and a coding representation of the video, whether an inter mode is valid according to a rule, and performing the conversion based on the determination, the rule specifying that the inter mode is valid if a dual tree partitioning of luma samples is valid for the video block.

[0013] In another example aspect, another method of video processing is disclosed, the method including: determining, based on a rule, whether use of a palette mode is allowed for a video region for conversion between a video region of the video and a coding representation of the video; and performing the conversion based on the determination, the palette mode including encoding the video region using a palette of representative sample values.

[0014] In another example aspect, another method of video processing is disclosed that includes performing a conversion between a current video block of a video and a coded representation of the video, the coded representation conforming to a format rule, the format rule specifying a syntax element modeType including MODE_TYPE_IBC to enable use of an intra block copy mode for the conversion or MODE_TYPE_PALETTE to enable use of a palette mode for the conversion, the intra block copy mode including encoding the current video block using at least a block vector that points to a video frame that includes the current video block, and the palette mode including encoding the current video block using a palette of representative sample values.

[0015] In another example aspect, another method of video processing is disclosed that includes, for conversion between a current video block of a video and a coded representation of the video, determining, according to rules that depend on a coding mode type used to represent the current video block in the coded representation and dimensions of the current video block, whether a particular partitioning scheme is allowed for the current video block, and performing the conversion based on the determination.

[0016] In another example aspect, another method of video processing is disclosed that includes performing a conversion between a video block of a video and a coded representation of the video, the coded representation conforming to a format rule, the format rule specifying that characteristics of the video block control whether a syntax element in the coded representation indicates a prediction mode of the video block.

[0017] In another example aspect, another method of video processing is disclosed that includes performing a conversion between a video domain of a first component of the video and a coded representation of the video, where the coded representation conforms to a format rule, the format rule specifying whether and / or how a syntax field is configured in the coded representation to indicate a differential quantization parameter for the video domain depends on a partitioning scheme used to partition samples of the first component.

[0018] In another example aspect, another method of video processing is disclosed, the method including performing a conversion between a video domain of a first component of the video and a coding representation of the video according to a rule, the rule specifying that when a dual tree and / or a local dual tree coding structure is applied to the video domain, a variable associated with a differential quantization parameter of the first component is not changed during a process of decoding or parsing a second component of the video.

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

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

[0021] In yet other example aspects, the methods may be embodied in processor-executable instructions and stored on a computer-readable program medium.

[0022] These and other aspects are described further herein. [Brief description of the drawings]

[0023] [Figure 1] 1 shows an example of an intra-block copy coding tool. [Diagram 2] 1 shows an example of a block coded in palette mode. [Diagram 3] 13 illustrates an example of the use of a palette predictor to signal palette entries. [Figure 4] 4 shows examples of horizontal and vertical traverse scans. [Diagram 5] An example of palette index coding is shown below. [Figure 6] 67 examples of intra prediction modes are shown. [Figure 7] Examples of left and top neighbors of the current block are shown below. [Figure 8] Examples of ALF filter shapes (chroma: 5x5 diamond, luma: 7x7 diamond) are shown. [Figure 9] 13 shows an example of a subsampled Laplacian computation. [Figure 10] 13 shows an example of modified block classification with virtual boundaries. [Figure 11] 13 illustrates an example of modified ALF filtering for the luma component at the virtual boundary. [Figure 12] 4 shows examples of 1D 3-pixel patterns for pixel classification in EO. [Figure 13] The four bands are grouped together and represented by their starting band position. [Figure 14] 1 shows the upper and left neighboring blocks used in the CIIP weight derivation. [Figure 15] 1 illustrates luma mapping with a chroma scaling architecture. [Figure 16] Here is an example of SCIP. [Figure 17]FIG. 1 is a block diagram of an example hardware platform that may be used to implement the techniques described herein. [Figure 18] 1 is a flow chart of an example method of video processing. [Figure 19] 13 shows examples of spatial merge candidate locations. [Figure 20] 13 shows examples of candidate pairs considered for redundancy checking of spatial merge candidates. [Figure 21A] 1 is a flow chart of an example method of video processing. [Figure 21B] 1 is a flow chart of an example method of video processing. [Figure 21C] 1 is a flow chart of an example method of video processing. [Figure 21D] 1 is a flow chart of an example method of video processing. [Figure 21E] 1 is a flow chart of an example method of video processing. [Figure 21F] 1 is a flow chart of an example method of video processing. [Figure 21G] 1 is a flow chart of an example method of video processing. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0026] 1. Overview This document relates to video coding techniques. In particular, it relates to palette coding, which uses representations based on primary colors in video coding. It may be applied to existing video coding standards such as HEVC, or standards to be finalized (Versatile Video Coding). It may also be applicable to future video coding standards or video codecs.

[0027] 2. Initial discussion Video coding standards have evolved primarily 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 H.262 / MPEG-2 Video, H264 / MPEG-4 Advanced Video Coding (AVC), and H.265 / HEVC standards. Since H.262, video coding standards have been based on a hybrid video coding structure where temporal prediction plus transform coding is used. To explore future video coding technologies beyond HEVC, the Joint Video Exploration Team (JVET) was jointly established by VCEG and MPEG in 2015. Since then, many new methods have been adopted by JVET and put into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Expert Team (JVET) was formed between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) to study the VVC standard, which aims to achieve a 50% bitrate reduction compared to HEVC.

[0028] 2.1 Intra-block copy Intra block copy (IBC), also known as current picture referencing, is adopted in the HEVC Screen Content Coding extension (HEVC-SCC) and the current VVC test model (VTM-4.0). IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding. As shown in FIG. 1, the current block is predicted by a reference block in the same picture when IBC is applied. The samples in the reference block have already been reconstructed before the current block is encoded or decoded. Although IBC is not very efficient for most of the sequences captured by a camera, it shows a significant coding improvement for screen content. The reason is that there are many repeating patterns, such as icons and text characters, in screen content pictures. IBC can effectively remove the redundancy among those repeating patterns. In HEVC-SCC, an inter-coded coding unit (CU) can apply IBC if it selects the current picture as its reference picture. MV is renamed as block vector (BV) in this case, and BV always has integer pixel precision. To be compatible with 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 in the Multiview / 3D Video Coding standard, inter-view reference pictures are also marked as "long-term" reference pictures.

[0029] Following the BV to find its reference block, a prediction can be generated by copying the reference block. A residual is obtained by subtracting the reference pixels from the original signal. Then, transformation and quantization can be applied as seen in other coding modes.

[0030] FIG. 1 is an example of intra block copying.

[0031] However, if 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 limited by some constraint, some or all pixel values ​​are undefined. Basically, there are two solutions to handle such problems. One is to not allow such situations, for example in bitstream conformance. The other is to apply padding to those undefined pixel values. The following sub-sections will describe these solutions in detail.

[0032] 2.2 IBC in HEVC-SCC HEVC's Screen Content Coding extensions should ensure that when a block uses the current picture as a reference, the entire reference block is within the available reconstructed area, as indicated in the following spec text: [Table 1]

[0033] Thus, if the reference block overlaps with the current block or if the reference block is outside the picture, this does not occur: there is no need to pad the reference or prediction block.

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

[0035] 2.3.1 IBC Merge Mode In IBC merge mode, indices that point to entries in an IBC merge candidates list are parsed from the bitstream. The construction of the IBC merge list can be briefly described as following sequence of steps: Step 1: Derive spatial candidates Step 2: Inserting HMVP candidates Step 3: Insert pairwise average candidates

[0036] In the derivation of spatial merge candidates, up to four merge candidates are selected from the candidates at the positions shown in FIG. 19. The order of derivation is A1, B1, B0, A0, and B2. Position B2 is considered only if any PU at positions A1, B1, B0, A0 is not available (because it belongs to other slices or tiles) or is not coded in IBC mode. After the candidate at position A1 is added, the insertion of the remaining candidates is subjected to a redundancy check. This ensures that candidates with the same motion information are removed from the list, thereby improving the coding efficiency. In order to reduce the computational complexity, not all possible candidate pairs are considered in the above redundancy check. Instead, the pairs connected by arrows in FIG. 20 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.

[0037] If after the insertion of the spatial candidate, the IBC merge list size is still smaller than the maximum IBC merge list size, then an IBC candidate from the HMVP table may be inserted. When inserting an HMVP candidate, a redundancy check is performed.

[0038] Finally, the pairwise average candidates are inserted into the IBC merge list.

[0039] If the reference block identified by the merge candidate is outside the picture, or overlaps with the current block, or is outside the reconstructed area, or is outside the valid area limited by some constraint, the merge candidate is called an invalid merge candidate.

[0040] It is noted that invalid merge candidates may be inserted into the IBC merge list.

[0041] 2.3.2 IBC AMVP mode In IBC AMVP mode, an index pointing to an entry in the IBC AMVP list is parsed from the bitstream. The construction of the IBC AMVP list can be briefly described as following sequence of steps: Step 1: Derive spatial candidates Check A0, A1 until a usable candidate is found Check B0, B1, B2 until an available candidate is found Step 2: Inserting HMVP candidates Step 3: Inserting zero candidates

[0042] If after the insertion of the spatial candidate, the IBC AMVP list size is still less than the maximum IBC AMVP list size, then an IBC candidate from the HMVP table may be inserted.

[0043] Finally, the zero candidate is inserted into the IBC AMVP list.

[0044] 2.4 Palette Mode The basic idea behind the palette mode is that samples in a CU are represented by a small set of representative color values. This set is called the palette. It is also possible to indicate samples that are outside the palette by signaling an escape symbol followed by a (possibly quantized) component value. Such samples are called escape samples. The palette mode is represented in Figure 2.

[0045] FIG. 2 shows an example of a block coded in palette mode.

[0046] 2.5 Palette Modes in HEVC Screen Content Coding Extension (HEVC-SCC) In the palette mode in HEVC-SCC, a predictive method is used to code the palette and index map.

[0047] 2.5.1 Coding Palette Entries A palette predictor is maintained for coding of palette entries. The maximum size of the palette is signaled in the SPS along with the palette predictor. In HEVC-SCC, palette_predictor_initializer_present_flag is introduced in the PPS. When this flag is 1, an entry to initialize the palette predictor is signaled in the bitstream. The palette predictor is initialized at the beginning of each CTU row, each slice, and each tile. Depending on the value of palette_predictor_initializer_present_flag, the palette predictor is either reset to 0 or initialized with the palette predictor initializer entry signaled in the PPC. In HEVC-SCC, a palette predictor initializer of size 0 is enabled to allow explicit disabling of palette predictor initialization at the PPS level.

[0048] For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette or not. This is shown in Figure 3. The reuse flag is transmitted using run-length coding of zeros. After this, the number of the new palette entry is signaled using an exponential-Golomb code of degree 0. Finally, the component values ​​of the new palette entry are signaled.

[0049] FIG. 3 shows an example of the use of a palette predictor to signal palette entries. 2.5.2 Palette Index Coding

[0050] The palette index is coded using the horizontal and vertical traverse scan shown in Figure 4. The scan order is explicitly signaled in the bitstream using palette_transpose_flag. For the remainder of the subsection, the scan is assumed to be horizontal.

[0051] FIG. 4 shows an example of horizontal and vertical traverse scans.

[0052] The palette index is coded using two main palette sample modes: "INDEX" and "COPY_ABOVE". As mentioned above, the escape symbol is also signalled as "INDEX" mode and is assigned an index equal to the maximum palette size. The mode is signalled using a flag, except in the case of the top row or if the previous mode was "COPY_ABOVE". In "COPY_ABOVE" mode, the palette index of the sample in the row above is copied. In "INDEX" mode, the palette index is signalled explicitly. For both "INDEX" and "COPY_ABOVE" modes, a run value is signalled, which specifies the number of subsequent samples that are also coded with the same mode. An escape component value is signalled for each escape symbol if it is part of a run in "INDEX" or "COPY_ABOVE" modes. The coding of the palette index is depicted in Figure 5.

[0053] This syntax order is achieved as follows: first, the number of index values ​​for the CU is signaled. This is followed by the signaling of the actual index values ​​for the entire CU using truncated binary coding. This groups together the bypass bins associated with the index. Then, the palette sample mode (if required) and run are signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape sample values ​​for the entire CU are grouped together and coded in bypass mode.

[0054] A further syntax element, last_run_type_flag, is signalled after signalling the index value, which, in combination with the index number, eliminates the need to signal a run value corresponding to the last run in the block.

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

[0056] In VVC, a dual-tree coding structure is used in intra-slice coding, so that the luma component and the two chroma components may have different palettes and palette indices, and furthermore, the two chroma components share the same palette and palette indices.

[0057] FIG. 5 shows an example of coding of the palette index.

[0058] 2.6 Intra-mode coding in VVC To capture arbitrary edge directions presented in natural video, the number of directional intra modes in VTM5 is expanded from the 33 used in HEVC to 65. The new directional modes not found in HEVC are represented by the dashed red arrows in Figure 6, while the planar and DC modes remain the same. These denser intra prediction modes are applied for both luma and chroma intra prediction for all block sizes.

[0059] In VTM5, some conventional angular intra-prediction modes are adaptively replaced with wide-angle intra-prediction modes for non-square blocks.

[0060] In HEVC, every intra-coded block has a square shape, with the length of each side being a power of 2. Hence, no splitting operation is required to generate an intra predictor using DC mode. In VTM5, blocks may have rectangular shapes, which requires the use of a splitting operation for each block in the general case. To avoid the splitting operation for DC prediction, only the longer side is used to calculate the average of non-square blocks.

[0061] FIG. 6 shows examples of 67 intra prediction modes.

[0062] In order to keep the complexity of the most probable mode (MPM) list generation low, an intra-mode coding method with six MPMs is used by considering two available adjacent intra-modes. The following three aspects are considered for constructing the MPM list: - Default intra mode Adjacent intra mode -Derived intra mode

[0063] A unified 6-MPM list is used for intra blocks, whether MRL and ISP coding tools are applied or not. The MPM list is constructed based on the intra modes of the left and top neighboring blocks. Assuming that the mode of the left block is denoted as Left and the mode of the top block is denoted as Above, the unified MPM list is constructed as follows (the left block and top block are shown in FIG. 7):

[0064] FIG. 7 shows an example of the left and upper neighbors of the current block. If no adjacent blocks are available, the Intra mode is set to Planar by default. · If both modes Left and Above are non-angle modes: ·MPM List → {Planar, DC, V, H, V-4, V+4} If one of the modes Left and Above is an angular mode and the other is a non-angular mode: Set mode Max as the larger of Left and Above modes · MPM List → {Planar, Max, DC, Max-1, Max+1, Max-2} · If Left and Above are both in angle mode and they are different: Set mode Max as the larger of Left and Above modes If the difference between the modes Left and Above is between 2 and 62: ·MPM List → {Planar, Left, Above, DC, Max-1, Max+1} If not: ·MPM List → {Planar, Left, Above, DC, Max-2, Max+2} ·If Left and Above are both in angle mode and they are the same: ·MPM List → {Planar, Left, Left-1, Left+1, DC, Left-2}

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

[0066] During the generation process of the 6-MPM list, pruning is used to remove duplicate modes so that only unique modes can be included in the MPM list. For entropy coding of the 61 non-MPM modes, truncated binary coding (TBC) is used.

[0067] A total of eight intra modes are allowed for chroma intra mode coding, including five traditional intra modes and three cross-component linear model modes (CCLM, LM_A, and LM_L). The process of chroma mode signaling and derivation is shown in Table 2-4. Chroma mode coding directly depends on the intra prediction mode of the corresponding luma block. Since separate block partition structures for luma and chroma components are enabled in I slice, one chroma block may correspond to multiple luma blocks. Therefore, for chroma DM mode, the intra prediction mode of the corresponding luma block that covers the center position of the current chroma block is directly inherited. [Table 2]

[0068] 2.7 QR-BDPCM(Quantized residual Block Differential Pulse-Code Modulation) In JVET-M0413, Quantized Residual Block Differential Pulse-Code Modulation (QR-BDPCM) is proposed for efficient coding of screen content.

[0069] The prediction direction used in QR-BDPCM can be vertical and horizontal prediction modes. Intra prediction is performed for the whole block by sample copying in the prediction direction (horizontal and vertical) as in intra prediction. The residual is quantized and the difference (delta) between the quantized residual and its predictor (horizontal or vertical) quantized value is coded. This can be explained by the following: For a block of size M (rows) × N (columns), r i,jLet 0≦i≦M-1, 0≦j≦N-1 be the prediction residual after performing intra prediction horizontally (copying the left adjacent pixel value line by line across the predicted block) or vertically (copying the upper adjacent line onto each line in the predicted block) using unfiltered samples from the upper or left block boundary samples. i,j ), 0≦i≦M-1,0≦j≦N-1 is the residual r i,j where the residual is the difference between the original block values ​​and the predicted block values. Block DPCM is then applied to the quantized residual samples, resulting in the element (outside 1) Modified M x N array with TIFF0007597893000003.tif9127 (outside 2) You get TIFF0007597893000004.tif9127. When vertical BDPCM is notified:

number

[0070] For horizontal prediction, a similar rule applies, and the residual quantized samples are

number

[0071] Residual Quantization Samples (Outside 3) TIFF0007597893000007.tif9127 is sent to the decoder.

[0072] On the decoder side, the above calculation is i,j ), 0≦i≦M-1,0≦j≦N-1 are inverted to extract

number

number

[0073] The dequantized residual Q -1 (Q(r i,j ) is added to the intrablock prediction to generate a reconstructed sample value.

[0074] The main advantage of this scheme is that the inverse DPCM can be performed on-the-fly during coefficient analysis by simply adding a predictor as the coefficients are parsed, or it can be performed after the analysis.

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

[0076] 2.8.1.1 Filter Shape In VTM5, two diamond filter shapes (illustrated in Figure 8) are used: a 7x7 diamond shape is applied to the luma component and a 5x5 diamond shape is applied to the chroma components.

[0077] FIG. 8 shows examples of ALF filter shapes (chroma: 5×5 diamond, luma: 7×7 diamond).

[0078] 2.8.1.2 Block Classification For the luma component, each 4x4 block can be classified into one of 25 classes. The classification index C is derived based on its directionality D and quantized activity value A (with a hat) as follows:

number

[0079] To compute D and A with a hat, the horizontal, vertical, and two diagonal gradients are first computed using the 1-D Laplacian:

number

[0080] To reduce the complexity of block classification, a subsampled 1-D Laplacian computation is applied. The same subsampled positions are used for gradient computation in all directions, as shown in Figure 9.

[0081] FIG. 9 shows examples of subsampled Laplacian computation: (a) subsampled positions for vertical gradients, (b) subsampled positions for horizontal gradients, (c) subsampled positions for diagonal gradients, and (d) subsampled positions for diagonal gradients.

[0082] Then the maximum and minimum values ​​of the horizontal and vertical gradients D are:

number

[0083] The maximum and minimum of the two diagonal gradients are:

number

[0084] To derive the value of the directionality D, these values ​​are compared with each other and with two thresholds t1 and t2: [Table 3]

[0085] The activity value A is

number

[0086] A is further quantized to the range 0 to 4, inclusive, and the quantized value is represented as A with a hat.

[0087] For the chroma components in a picture, no classification method is applied, i.e., one set of ALF coefficients is applied per chroma component.

[0088] 2.8.1.3 Geometric Transformation of Filter Coefficients and Clipping Values Before filtering each 4x4 luma block, a geometric transformation such as a rotation or a diagonal and vertical flip is applied to the filter coefficients f(k,l) and the corresponding filter clipping values ​​c(k,l) according to the gradient values ​​calculated for that block. This is equivalent to applying these transformations to samples within the filter support region. The idea is to make the various blocks to which ALF is applied more similar by adjusting their orientation.

[0089] Three geometric transformations are introduced, including diagonal, vertical flip, and rotation:

number

[0090] 2.8.1.4 Filter Parameter Notification In VTM5, the ALF filter parameters are signaled in an Adaptation Parameter Set (APS). Up to 25 pairs of luma filter coefficients and clipping values ​​can be signaled in one APS. To reduce bit overhead, filter coefficients of different classifications can be merged. The slice header signals the index of the APS used for the current slice.

[0091] The clipping value index decoded from the APS allows to determine the clipping values ​​using a luma table of clipping values ​​and a chroma table of clipping values, which depend on the underlying bit depth. More precisely, the luma table of clipping values ​​and the chroma table of clipping values ​​are obtained by the following formula:

number

[0092] 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 a filter set from 16 fixed filter sets and a filter set from the APS. A filter set index is signaled for the luma CTB to indicate which filter set is applied. The 16 fixed filter sets are predefined and hard-coded in both the encoder and the decoder.

[0093] The filter coefficients are quantized with a norm equal to 128. To limit the multiplication complexity, coefficient values ​​at non-central positions are quantized with a norm equal to 128. 7 2 more 7 Bitstream conformance is applied such that the center position coefficient should be in the range less than or equal to -1. The center position coefficient is not signaled in the bitstream and is assumed to be equal to 128.

[0094] 2.8.1.5 Filtering Process At the decoder side, when ALF is enabled for the CTB, each sample R(i,j) in the CU is filtered to obtain a sample value R'(i,j) as follows:

number

[0095] 2.8.1.6 Virtual Boundary Filtering Process for Line Buffer Reduction In VTM5, modified block classification and filtering is used for samples close to horizontal CTU boundaries to reduce line buffer requirements. For this purpose, a virtual boundary is defined as a line by shifting the horizontal CTU boundary to include “N” samples, as shown in FIG. 10. N is equal to 4 for the luma component and 2 for the chroma component.

[0096] FIG. 10 shows an example of modified block classification with virtual boundaries.

[0097] As shown in FIG. 11, a modified block classification is applied to the luma component and the activity value A is scaled accordingly by taking into account the reduction in the number of samples used in the 1D Laplacian gradient computation.

[0098] For the filtering process, a symmetric padding operation at the virtual boundary is used for both luma and chroma components. As shown in Figure 11, if the sample being filtered is located below the virtual boundary, the adjacent samples located above the virtual boundary are padded, while the corresponding samples on the other side are also padded symmetrically.

[0099] FIG. 11 shows an example of modified ALF filtering for the luma component at the virtual boundary.

[0100] 2.9 Sample Adaptive Offset (SAO) A sample adaptive offset (SAO) is applied to the reconstructed signal after the deblocking filter by using an offset specified for each CTB by the encoder. The HM encoder first determines whether the SAO process should be applied to the current slice. When SAO is applied to a slice, each CTB is classified as one of five SAO types, as 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. SAO operations include edge offset (EO), which uses edge characteristics for pixel classification in SAO types 1-4, and band offset (BO), which uses 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 reuses the SAO type and offset of the CTB to its left. When sao_merge_up_flag is equal to 1, the current CTB reuses the SAO type and offset of the CTB above. [Table 5]

[0101] 2.9.1 Operation of each SAO type Edge offset uses four one-dimensional three-pixel patterns for classification of the current pixel p, taking into account edge direction information, as shown in Figure 12. From left to right, there are 0 degrees, 90 degrees, 135 degrees, and 45 degrees.

[0102] FIG. 12 shows four example one-dimensional 3-pixel patterns for pixel classification in EO.

[0103] Each CTB is classified into one of five categories according to Table 2-7. [Table 6]

[0104] Band offset (BO) classifies all pixels in one CTB region into 32 uniform bands by using the 5 most significant bits of the pixel value as the band index. That is, 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 left-most position as shown in Figure 13. The encoder searches all positions to obtain the group that reduces the distortion the most by compensating for the offset of each band.

[0105] FIG. 13 shows an example where four bands are grouped together and represented by their starting band position.

[0106] 2.10 Combined Inter-Intra Prediction (CIIP) In VTM5, if a CU is coded in merge mode, if the CU contains at least 64 luma samples (i.e., CU width × CU height is 64 or more), and if both the CU width and CU height are less than 128 luma samples, an additional flag is signaled to indicate whether a combined inter / intra prediction (CIIP) mode is currently applied to the CU. As the name suggests, CIIP prediction combines an inter prediction signal with an intra prediction signal. The inter prediction signal P in CIIP mode inter is derived using the same inter prediction process as applied in the normal merge mode, resulting in an intra prediction signal P intra is derived according to the normal intra prediction process in planar mode. The intra prediction signal and the inter prediction signal are then combined using a weighted average, where the weight value is calculated according to the coding modes of the upper and left neighboring blocks (shown in FIG. 14 ) as follows: · If the upper neighboring block is available and is intra-coded, set isIntraTop to 1, otherwise set isIntraTop to 0. · If the left adjacent block is available and is intra-coded, set isIntraLeft to 1, otherwise set isIntraLeft to 0. If (isIntraLeft+isIntraTop) is equal to 2, then wt is set to 3. Otherwise, if (isIntraLeft+isIntraTop) is equal to 1, then wt is set to 2. In all other cases, set wt to 1.

[0107] The CIIP forecast is formed as follows:

number

[0108] FIG. 14 shows the above and left neighboring blocks used in the CIIP weight derivation.

[0109] 2.11 Luma Mapping with Chroma Scaling (LMCS) In VTM5, a coding rule called LMCS (luma mapping with chroma scaling) is added as a new processing block before the loop filter. LMCS has two main components: 1) in-loop mapping of luma components based on an adaptive piecewise linear model, and 2) application of luma-dependent chroma residual scaling for chroma components. Figure 15 shows the LMCS architecture from the decoder perspective. The dashed blocks in Figure 15 indicate that processing is applied in the mapped domain, including inverse quantization, inverse transform, luma intra prediction, and adding luma prediction with luma residual. The unshaded blocks in Figure 15 indicate where processing is applied in the original (i.e., non-mapped) domain, including loop filters such as deblocking, ALF, and SAO, motion compensated prediction, chroma intra prediction, adding chroma prediction with chroma residual, and storing the decoded picture as a reference picture as well. The checked blocks in Figure 15 are the new LMCS functional blocks that include forward and backward mapping of the luma signal and luma-dependent chroma scaling processes. Like most other tools in VVC, LMCS can be enabled / disabled at the sequence level using the SPS flag.

[0110] FIG. 15 shows an example of luma mapping according to the chroma scaling architecture.

[0111] 2.12 Dual-tree partitions In the current VVC design, for an I slice, each CTU may be divided into coding units with 64x64 luma samples using an implicit quadtree partitioning, which are the roots of two separate coding_tree syntax structures for luma and chroma.

[0112] Since the dual tree in intra picture allows different partitions to be applied in the chroma coding tree than in the luma coding tree, the dual tree introduces a longer coding pipeline, and the QTBT MinQTSizeC value range and MinBtSizeY and MinTTSizeY in the chroma tree allow small chroma blocks such as 2×2, 4×2, and 2×4, which brings difficulties in practical decoder design. Furthermore, some prediction modes such as CCLM, planar, and angular modes require multiplication. To alleviate the above problems, small chroma block sizes (2×2 / 2×4 / 4×2) are restricted in the dual tree as partition restrictions.

[0113] 2.13 Minimal Chroma Intra Prediction Unit (SCIPU) in JVET-O0050 Small chroma size is not friendly for hardware implementation. In dual tree case, too small size chroma block is not allowed. However, in single tree case, VVC draft 5 still allows 2x2, 2x4, 4x2 chroma blocks. To limit the size of chroma block, in single coding tree, SCIPU is defined in JVET-O0050 as a coding tree node whose chroma block size is larger than or equal to TH chroma sample and has at least one child luma block smaller than 4TH luma sample. Note that TH is set to 16 in this contribution. In each SCIPU, it is required that all CBs are inter or all CBs are non-inter, i.e., either intra or IBC. In case of non-inter SCIPU, it is further required that the chroma of non-inter SCIPU should not be further split, and the luma of SCIPU is allowed to be further split. Thus, the minimum chroma intra CB size is 16 chroma samples, and 2x2, 2x4, and 4x2 chroma CBs are removed. Furthermore, chroma scaling is not applied in the case of non-inter SCIPU.

[0114] Two examples of SCIPUs are shown in FIG. 16. In FIG. 16(a), one chroma CB of 8×4 chroma samples and three luma CBs (4×8, 8×8, 4×8 luma CB) form one SCIPU. This is because the ternary tree (TT) split from the 8×4 chroma samples results in a chroma CB that is smaller than 16 chroma samples. In FIG. 16(b), one chroma CB of 4×4 chroma samples (left side of the 8×4 chroma samples) and three luma CBs (8×4, 4×4, 4×4 luma CB) form one SCIPU, and one chroma CB of 4×4 samples (right side of the 8×4 chroma samples) and two luma CBs (8×4, 8×4 luma CB) form one SCIPU. This is because the ternary tree (TT) split from the 4×4 chroma samples results in a chroma CB that is smaller than 16 chroma samples.

[0115] FIG. 16 shows an example of SCIP.

[0116] If the current slice is an I slice or the current SCIPU has a 4x4 luma partition in it after one further division, the type of the SCIPU is inferred to be non-inter (because inter 4x4 is not allowed in VVC). Otherwise, the type of the SCIPU (inter or non-inter) is indicated by a single flag before parsing the CUs in the SCIPU.

[0117] 2.14 Small Chroma Block Restrictions in VVC Draft 6 In VVC draft 6 (JVET-O2001-vE.docx), the constraints on small chroma blocks are implemented as follows (relevant parts are marked in bold italics): [Table 7] TIFF0007597893000024.tif201170TIFF0007597893000025.tif238170TIFF0007597893000026.t if244170TIFF0007597893000027.tif243151TIFF0007597893000028.tif147151TIFF00075978930 00029.tif246151TIFF0007597893000030.tif242150TIFF0007597893000031.tif175149TIFF000 7597893000032.tif243151TIFF0007597893000033.tif233151TIFF0007597893000034.tif185151

[0118] 3. Examples of technical problems solved by the disclosed technical solution (1) Currently, IBC is assumed to be in MODE_TYPE_INTRA, so small chroma blocks are not allowed, resulting in unnecessary coding efficiency loss. (2) Currently, the palette is assumed to be in MODE_TYPE_INTRA, so small chroma blocks are not allowed, resulting in unnecessary coding efficiency loss. (3) Currently, the small chroma block constraint does not take into account color subsampling formats. (4) Currently, the same partition 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 for 4:2:0 and 4:2:2 chroma formats. (5) Currently, palette mode flag notification depends on modeType, which is undesirable because the palette may not enforce small block constraints. (6) Currently, the IBC mode flag is inferred to be 0 for P / B slices when cu_skip_frag is equal to 1 but MODE_TYPE is equal to MODE_TYPE_INTRA, which is invalid in the syntax parsing. (7) Currently, non-4×4 luma IBC modes are not allowed for SCIPU luma blocks, which may be undesirable and may cause coding efficiency loss. (8) 2xH chroma blocks are still allowed, but this is not friendly to hardware implementations. (9) CIIP, while considered as MODE_INTER, uses intra prediction, which violates constraints in some cases. (10) When SCIPU is applied, the chroma delta QP may not be signaled depending on the luma split. For example, if the current block dimension is 16x8 in luma samples and split by vertical TT, a local dual tree may be applied. This is specified as follows: qgOnC=qgOnC&&(cbSubdiv+2<=cu_chroma_qp_offset_subdiv) Therefore, qgOnC is set to zero if cbSubdiv+2<=cu_chroma_qp_offset_subdiv. This conditional setting assumes that chroma components are also split by TT. In a local dual tree, chroma components may not be split, so cbSubdiv can be greater than cu_chroma_qp_offset_subdiv. IsCuChromaQpOffsetCoded should be set to 0 to enable reporting of delta QP for chroma. However, since qgOnC is set to 0, IsCuChromaQpOffsetCoded is not set to 0.

[0119] 4. Examples of Technical Solutions and Embodiments The following should be regarded as examples. These techniques should not be construed in a narrow sense. Moreover, these techniques can be combined in any way.

[0120] In this document, an "M×N coding tree node" refers to an M×N block, where M and N are the width and height of luma samples, respectively, which may be further partitioned, e.g., by QT / BT / TT, etc. For example, a block may be a QT node, or a BT node, or a TT node. A coding tree node may be a coding unit (e.g., having three color components for single tree, two chroma color components for dual tree chroma coding, and only one luma component for dual tree luma coding), or a luma coding block, or a chroma coding block. A "small coding tree node unit" may refer to a coding tree node with block size M×N equal to 32 / 64 / 128 in luma samples.

[0121] Unless otherwise stated, the width W and height of a coding block are measured in luma samples. For example, an M×N coding block means an M×N luma block and / or two (M / subWidthC)×(N / SubHeightC) chroma blocks, where SubWidthC and SubHeightC are derived according to the chroma format as follows: [Table 8]

[0122] 1. Whether and / or how to partition into smaller blocks may depend on the color format. In one example, for a 4:4:4 color format, constraints on the size of chroma blocks may follow such constraints on luma blocks. b. In one example, for a 4:2:2 color format, constraints on the size of chroma blocks may follow such constraints for the 4:2:0 color format. c. In one example, for 4:0:0 and / or 4:4:4 chroma formats, constraints on small block partitions and / or prediction modes may not apply. d. In one example, constraints on partitions of small blocks and / or prediction modes may be applied differently for different chroma formats. i. In one example, for an MxN (e.g., 8x8) coding tree node using horizontal BT partitioning, in a 4:2:2 chroma format, horizontal BT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, horizontal BT partitioning may be allowed for luma blocks but not for chroma blocks. ii. In one example, for an M×N (e.g., 16×4) coding tree node using vertical BT partitioning, in a 4:2:2 chroma format, vertical BT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, vertical BT may be allowed for luma blocks but not for chroma blocks. iii. In one example, for an M×N (e.g., 8×16) coding tree node using horizontal TT partitioning, in a 4:2:2 chroma format, horizontal TT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, horizontal TT partitioning may be allowed for luma blocks but not for chroma blocks. iv. In one example, for an M×N (e.g., 32×4) coding tree node using vertical TT partitioning, in a 4:2:2 chroma format, vertical TT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, vertical TT may be allowed for luma blocks but not for chroma blocks. v. In one example, for 4:0:0 and / or 4:4:4 color formats, the small block constraint may not apply. e. In one example, whether SCIPU should be enabled depends on the color format. i. In one example, SCIPU is enabled for 4:2:0 and 4:2:2 color formats. ii. In one example, SCIPU is disabled for 4:0:0 and / or 4:4:4 color formats. 1. In one example, modeType may always be equal to MODE_TYPE_ALL for 4:0:0 and / or 4:4:4 color formats. 2. In one example, modeTypeCondition may always be equal to 0 for 4:0:0 and / or 4:4:4 color formats.

[0123] 2. How to determine the prediction mode (and / or modeType) for a (sub)mode of a coding tree node may depend on the color format. a. In one example, if one of the following conditions is true, then the modeType of the (sub)block partitioned by this coding tree node is equal to MODE_TYPE_ALL for 4:2:2 chroma format, while for 4:2:0 chroma format, the modeType is equal to either MODE_TYPE_INTRA or MODE_TYPE_INTER: i. M×N (e.g., 8×8) coding tree nodes using horizontal BT partitioning ii. M×N (e.g., 16×4) coding tree nodes using vertical BT partitioning iii. M×N (e.g., 8×16) coding tree nodes using horizontal TT partitioning iv. M×N (e.g., 32×4) coding tree nodes with vertical TT partitioning

[0124] 3. It is proposed to rename MODE_TYPE_INTRA to MODE_TYPE_NO_INTER and to restrict the use of MODE_INTER. In one example, if a coding unit's modeType is equal to MODE_TYPE_NO_INTER, then MODE_INTER may not be allowed.

[0125] 4. It is proposed to rename MODE_TYPE_INTER to MODE_TYPE_NO_INTRA and to restrict the use of MODE_INTRA. In one example, if a coding unit's modeType is equal to MODE_TYPE_NO_INTRA, then MODE_INTRA may not be allowed.

[0126] 5. The mode constraint flag may never be signaled in 4:2:2 and / or 4:0:0 and / or 4:4:4 chroma formats. In one example, if the mode constraint flag is not present, it may be inferred to be equal to 1. i. Alternatively, if the mode constraint flag is not present, it may be inferred to be equal to 0.

[0127] 6. Whether and / or how to apply SCIPU to an M×N coding block, having M as block width and N as block height, may depend on whether the color format is 4:2:0 or 4:2:2. a. In one example, in a 4:2:2 color format, for an M×N coding block having M as block width and N as block height, SCIPU may be enabled only if M×N (denoted as M*N) is equal to 64 or 32. b. In one example, a coding tree node with M*N=128 may never be treated as a SCIPU block in 4:2:2 color format. c. In one example, a coding tree node with BT partitioning and M*N=64 may never be treated as a SCIPU block in 4:2:2 color format. d. In one example, a coding tree node with split_qt_flag equal to 1 and M*N=64 may be a SCIPU block in 4:2:2 color format. e. In one example, a coding tree node with TT partition and M*N=64 may be treated as a SCIPU block in 4:2:2 color format. f. In one example, a coding tree node with BT partitioning and M*N=32 may be treated as a SCIPU block in 4:2:2 color format. g. In the above description, for a SCIPU block in 4:2:2 color format, modeTypeCondition may always be equal to 1. h. In the above description, for SCIPU blocks in 4:2:2 color format, only MODE_TYPE_INTRA may be allowed for both the current block at the parent node and all sub-blocks under the child leaf nodes.

[0128] In 7.4:2:2 color format, the modeTypeCondition of the SCIPU block may always be equal to 1. In one example, modeTypeCondition may be equal to 0 or 1 for a 4:2:2 color format. b. In one example, for a SCIPU block in 4:2:2 color format, modeTypeCondition may never be equal to 2.

[0129] In 8.4:2:2 color format, the modeType of the SCIPU block may always be equal to MODE_TYPE_INTRA. In one example, modeType may be equal to MODE_TYPE_ALL or MODE_TYPE_INTRA in 4:2:2 color format. b. In one example, for a SCIPU block in 4:2:2 color format, MODE_TYPE_INTER may be disabled.

[0130] 9. Whether block partitions are allowed may depend on the modeType and / or block size. In one example, whether BT and / or TT splitting is allowed for a block may depend on the modeType. i. In one example, if modeType is equal to MODE_TYPE_INTER, then BT splitting may not be allowed for the current coding block (eg, allowBtSplit is set equal to false). ii. In one example, if modeType is equal to MODE_TYPE_INTER, then TT splitting may not be allowed for the current coding block (eg, allowTtSplit is set equal to false). b. In one example, whether BT and / or TT splitting is allowed for a block may depend on the modeType and the block size. i. In one example, for an M×N coding block having block width M and block height N, if M*N is less than or equal to 32 and modeType is equal to MODE_TYPE_INTER, BT splitting may not be allowed (e.g., allowBtSplit is set equal to false). ii. In one example, for an M×N coding block having a block width of M and a block height of N, if M*N is less than or equal to 64 and modeType is equal to MODE_TYPE_INTER, TT splitting may not be allowed (e.g., allowTtSplit is set equal to false).

[0131] 10. If the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER, the splitting of the coding tree may be restricted. In one example, if the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER, then BT splitting may not be allowed. b. In one example, if the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER, TT splitting may not be allowed. c. In one example, if the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER, then QT splitting may not be allowed. d. In one example, if the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER and the luma block size is less than or equal to 32, then BT partitioning may not be allowed. e. In one example, if the coding tree's modeTypeCurr is equal to MODE_TYPE_INTER and the luma block size is less than or equal to 64, TT partitioning may not be allowed.

[0132] 11. A coding unit with TreeType equal to DUAL_TREE_LUMA may be coded in inter mode. In one example, a coding unit coded in an inter-coding mode, ie, MODE_INTER, may include only a luma component even in the case of a color format having multiple color components. b. In one example, pred_mode_flag may need to be parsed for DUAL_TREE_LUMA blocks. c. In one example, the same inter mode constraints as for SINGLE_TREE may also be applied to DUAL_TREE_LUMA blocks coded in inter mode. i. In one example, 4x4 DUAL_TREE_LUMA inter blocks may not be allowed.

[0133] 12. Chroma Intra (and / or IBC) blocks with block width equal to M (eg, M=2) chroma samples may not be allowed. In one example, chroma intra blocks of 2×N (eg, N<=64) may not be allowed in the dual tree. i. In one example, if treeType is equal to DUAL_TREE_CHROMA and block width is equal to 4 chroma samples, then vertical BT splitting may not be allowed. ii. In one example, if treeType is equal to DUAL_TREE_CHROMA and block width is equal to 8 chroma samples, then vertical TT splitting may not be allowed. b. In one example, 2×N (eg, N<=64) chroma intra (and / or IBC) blocks may not be allowed in a single tree. i. In one example, for an M×N (eg, M=8 and N<=64) coding tree node using vertical BT partitioning, one of the following processes may be applied. 1. Vertical BT splitting is not allowed for 4×N or 4×(N / 2) chroma blocks, but may be allowed for 8×N luma blocks. The 2.4×N or 4×(N / 2) chroma block may not be vertical BT split, and it may be coded by MODE_INTRA or MODE_IBC. 3. Vertical BT splitting may be allowed for both 8xN luma blocks and 4xN or 4x(N / 2) chroma blocks, but both luma and chroma blocks may not be coded by MODE_INTRA (e.g., they may be coded by MODE_INTER or MODE_IBC). ii. In one example, for an M×N (eg, M=16 and N<=64) coding tree node using vertical TT partitioning, one of the following processes may be applied. 1. Vertical BT splitting is not allowed for 8×N or 8×(N / 2) chroma blocks, but may be allowed for 16×N luma blocks. 2. The 8×N or 8×(N / 2) chroma block may not be vertical TT split, it may be coded by MODE_INTRA or MODE_IBC. 3. Vertical TT splitting may be allowed for both 16xN luma blocks and 8xN or 8x(N / 2) chroma blocks, but both luma and chroma blocks may not be coded by MODE_INTRA (e.g., they may be coded by MODE_INTER or MODE_IBC).

[0134] 13. IBC mode may be allowed for luma and / or chroma blocks, regardless of whether it is a small block size or not. In one example, IBC mode may be allowed for luma blocks including 8x4 / 8x8 / 16x4 and 4xN (eg, N<=64) luma blocks, even if modeType is equal to MODE_TYPE_INTRA. b. In one example, IBC mode may be allowed for a chroma block even if modeType is equal to MODE_TYPE_INTRA.

[0135] 14. Signaling of IBC prediction mode flags may depend on the prediction mode type (eg, MODE_TYPE_INTRA). a. In one example, the IBC prediction mode flag for a non-SKIP block (e.g., a coding block that is not coded by skip mode) may be explicitly signaled in the bitstream if treeType is not equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA.

[0136] 15. The IBC prediction mode flag may be inferred depending on the CU SKIP flag and the mode type (eg, modeType). In one example, if the current block is coded in SKIP mode (eg, cu_skip_flag is equal to 1) and modeType is equal to MODE_TYPE_INTRA, then the IBC prediction mode flag (eg, pred_mode_ibc_flag) may be inferred to be equal to 1.

[0137] 16. Explicit reporting of palette mode flags may be independent of modeType. In one example, the signaling of palette mode flags (eg, pred_mode_plt_flag) may depend on slice type, block size, prediction mode, etc., whatever the modeType. b. In one example, the palette mode flag (eg, pred_mode_plt_flag) is inferred to be 0 if modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTRA.

[0138] 17. IBC mode may be allowed to be used if modeType is equal to MODE_TYPE_INTER. In one example, chroma IBC may not be allowed when modeType is equal to MODE_TYPE_INTRA. b. In one example, the IBC mode may be allowed to be used if modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER. c. In one example, IBC mode may be allowed to be used no matter what the modeType is. d. In one example, within one SCIPU, both IBC and inter modes may be allowed. e. In one example, the size of an IBC chroma block may always correspond to the size of the corresponding luma block. f. In one example, if modeType is equal to MODE_TYPE_INTER and the coding unit size is 4x4 in luma, then signaling of pred_mode_ibc_flag may be skipped and pred_mode_ibc_flag may be inferred to be equal to 1.

[0139] 18. Palette mode may be allowed to be used if modeType is MODE_TYPE_INTER. In one example, chroma palettes may not be allowed when modeType is MODE_TYPE_INTRA. b. In one example, the IBC mode may be allowed to be used if modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER. c. In one example, the IBC mode may be allowed to be used regardless of what the modeType is. d. In one example, palette mode may be allowed to be used if modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER. e. In one example, palette mode may be allowed to be used no matter what the modeType is. f. In one example, within one SCIPU, palette and inter modes may both be allowed. g. In one example, within one SCIPU, palette, IBC and inter modes may all be allowed. h. In one example, the size of a palette chroma block always corresponds to the size of the corresponding luma block. i. In one example, if modeType is equal to MODE_TYPE_INTER and the coding unit size is 4x4 in luma, then signaling of pred_mode_plt_flag may be skipped and pred_mode_plt_flag may be inferred to be equal to 1. j. In one example, if modeType is equal to MODE_TYPE_INTRA and the coding unit size is 4x4 in luma, one message may be sent to indicate whether the current prediction mode is IBC or palette. k. In one example, whether to enable / disable palette mode may depend on the slice type and modeType. i. In one example, for I-slices with MODE_TYPE_INTRA, palette mode may be enabled. ii. In one example, for P / B slices with MODE_TYPE_INTER, palette mode may be enabled.

[0140] 19. When palette mode is enabled, local dual trees may not be allowed. In one example, if palette mode is enabled, modeTypeCondition may always be set equal to 0.

[0141] 20. For small chroma blocks whose width is equal to M (e.g., M=2) or whose height is equal to N (e.g., N=2), the allowed intra prediction modes may be restricted to be different from those allowed for large chroma blocks. In one example, only a subset of the intra prediction modes among the available chrominance intra prediction modes may be used. b. In one example, only the INTRA_DC mode may be used. c. In one example, only the INTRA_PLANAR mode may be used. d. In one example, only the INTRA_ANGULAR18 mode may be used. e. In one example, only the INTRA_ANGULAR50 mode may be used. f. In one example, CCLM mode may not be allowed.

[0142] 21. For small chroma blocks whose width is equal to M (e.g., M=2) or whose height is equal to N (e.g., N=2), the transformation types may be restricted to be different from those allowed for large chroma blocks. In one example, only conversion skip may be used. b. In one example, only a one-dimensional transform may be used. c. In one example, a coding tool that supports multiple types of transformations is not permitted. i. Alternatively, notification of coding tools that support multiple types of transformations is omitted.

[0143] 22. CIIP may be considered as MODE_TYPE_INTRA. In one example, CIIP mode may be allowed when dual tree partitions are used. i. In one example, CIIP mode may be allowed if the CU type is DUAL_TREE_CHROMA. b. Alternatively, CIIP may be considered as MODE_TYPE_INTER. i. In one example, if the chroma block width is equal to M (eg, M=2), then CIIP mode may not be allowed. ii. In one example, when the chroma block width is equal to M (eg, M=2), the subset of intra prediction modes for chroma in CIIP may be restricted to simple intra prediction modes. 1. In one example, INTRA_DC may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). 2. In one example, INTRA_ANGULAR18 may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). 3. In one example, INTRA_ANGULAR50 may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). iii. In one example, intra prediction modes for chroma in CIIP may be restricted to simple intra prediction modes. 1. In one example, INTRA_DC may be used for chrominance intra prediction. 2. In one example, the INTRA_ANGULAR18 mode may be used for chroma intra prediction. 3. In one example, the INTRA_ANGULAR50 mode may be used for chroma intra prediction.

[0144] 23. For the above bullets, the variables M and / or N may be predefined or signaled. In one example, M and / or N may further depend on the color format (eg, 4:2:0, 4:2:2, 4:4:4).

[0145] 24.modeType may be extended to cover more types. In one example, modeType may be MODE_TYPE_IBC. When modeType is equal to MODE_TYPE_IBC, the prediction mode is inferred to be IBC. i. In one example, pred_mode_flag is not signaled in this case. ii. In one example, pred_mode_ibc_flag is not signaled in this case. iii. In one example, pred_mode_plt_flag is not signaled in this case. b. In one example, modeType may be MODE_TYPE_PALETTE. When modeType is equal to MODE_TYPE_PALETTE, the prediction mode is inferred to be palette mode. i. In one example, pred_mode_flag is not signaled in this case. ii. In one example, pred_mode_ibc_flag is not signaled in this case. iii. In one example, pred_mode_plt_flag is not signaled in this case. c. In one example, mode_constraint_flag may be replaced with an index to indicate which of the allowed modeTypes is to be used.

[0146] 25. In one example, whether a QT division is allowed for a block with dimensions W×H may depend on the modeType combined with the dimensions. For example, if modeType is equal to MODE_TYPE_INTER, and W is equal to 8, and H is equal to 8, then QT division is not allowed.

[0147] 26. In one example, whether a vertical TT partition is allowed for a block with dimensions W×H may depend on the modeType combined with the dimensions. For example, if modeType is equal to MODE_TYPE_INTER, and W is equal to 16, and H is equal to 4, then vertical TT split is not allowed.

[0148] 27. In one example, whether horizontal TT partitioning is allowed for a block with dimensions W×H may depend on the modeType combined with the dimensions. For example, if modeType is equal to MODE_TYPE_INTER, and W is equal to 4, and H is equal to 16, then horizontal TT split is not allowed.

[0149] 28. In one example, whether vertical BT partitioning is allowed for a block with dimensions W×H may depend on the modeType combined with the dimensions. For example, if modeType is equal to MODE_TYPE_INTER, and W is equal to 8, and H is equal to 4, then vertical BT split is not allowed.

[0150] 29. In one example, whether horizontal BT splitting is allowed for a block with dimensions W×H may depend on the modeType combined with the dimensions. For example, if modeType is equal to MODE_TYPE_INTER, and W is equal to 4, and H is equal to 8, then horizontal BT split is not allowed.

[0151] 30. In one example, whether the prediction mode of a CU is inferred by modeType may depend on the color components and / or block dimensions W×H. For example, the prediction mode of a chroma CU is inferred by modeType, but the prediction mode of a luma CU is signaled rather than inferred by modeType. i. For example, if W>4 or H>4, the prediction mode of the luma CU is signaled rather than inferred by modeType.

[0152] 31. When SCIPU is applied, whether and / or how information related to the delta QP of the first component is signaled may depend on the method of splitting the first component. a. In one example, when SCIPU is applied, whether and / or how information related to the delta QP of the first component is signaled depends on the partitioning method of the first component and may be decoupled from the partitioning method of the second component. b. In one example, the first component is luma and the second component is chroma. c. In one example, the first component is chroma and the second component is luma.

[0153] 32. When the dual tree and / or local dual tree coding structure is applied, any variable related to the delta QP of the first component cannot be changed during the decoding or parsing process of the second component. In one example, a local dual tree coding structure may be used according to SCIPU. b. In one example, the first component is luma and the second component is chroma. i. The variable may be IsCuQpDeltaCoded. c. In one example, the first component is chroma and the second component is luma. i. The variable may be IsCuChromaQpOffsetCoded.

[0154] 33. When SCIPU is applied, information related to the delta QP of a component (e.g., luma or chroma) may be signaled at most once in a particular region, and the luma and chroma components are required to share the same mode type (e.g., MODE_TYPE_INTER or MODE_TYPE_INTRA). In one example, a particular region is considered a quantization group.

[0155] 5. Embodiment New additions are highlighted in bold italics, and deletions from the VVC Working Draft are marked with double brackets (e.g., [[a]] represents the deletion of the letter “a”). Changes are based on the latest VVC Working Draft (JVET=O2001-v11).

[0156] 5.1 Example Embodiment #1 The following embodiment relates to constraints on partitions of small blocks and prediction modes only applying to 4:2:0 and 4:4:4 chroma formats (not to 4:0:0 and 4;4;4 chroma formats). [Table 9]

[0157] 5.2 Example Embodiment #2 The following embodiment relates to the fact that notification of the palette mode flag is independent of modeType. [Table 10]

[0158] 5.3 Example Embodiment #3 The following embodiment relates to the IBC prediction mode flag being inferred depending on the CU SKIP flag and modeType. [Table 11]

[0159] 5.4 Example Embodiment #4 The following embodiments relate to the signaling of the IBC prediction mode flag depending on MODE_TYPE_INTRA and / or the IBC mode being allowed for luma blocks regardless of whether it is a small block size or not. [Table 12]

[0160] 5.5 Example Embodiment #5 The following embodiments relate to applying different intrablock constraints for 4:2:0 and 4:2:2 color formats. [Table 13]

[0161] 5.6 Example Embodiment #6 The following embodiment relates to not allowing 2xN chroma intra blocks in a single tree. [Table 14]

[0162] 5.7 Example Embodiment #7 The following embodiment relates to not allowing 2xN chroma intra blocks in the dual tree. [Table 15]

[0163] 5.8 Example embodiment #8 The following embodiment relates to enabling MODE_IBC for SCIPU chroma blocks. [Table 16]

[0164] 5.9 Exemplary embodiment #9 (Solution 1) regarding not allowing block partitions when modeType is MODE_TYPE_INTER [Table 17]

[0165] 5.10 Exemplary embodiment #10 (Solution 2) regarding not allowing block partitions when modeType is MODE_TYPE_INTER [Table 18]

[0166] 5.11 Example Embodiment #11 The following embodiment relates to restricting further division of the coding tree when MODE_TYPE_INTER is derived. [Table 19]

[0167] 5.12 Example embodiment #12 The following embodiment concerns constraints on small block partitions, and prediction modes do not apply when palette mode is enabled. [Table 20]

[0168] 5.13 Example embodiment #13 The following embodiment concerns small chroma intra block constraints for 4:2:2 color format. [Table 21]

[0169] 5.14 SCIPU Delta QP Notification Example #1 [Table 22] TIFF0007597893000050.tif179170TIFF0007597893000051.tif243170TIFF0007597893000052.tif125170

[0170] 5.15 SCIPU Delta QP Notification Example #2 [Table 23] TIFF0007597893000054.tif179170TIFF0007597893000055.tif243170TIFF0007597893000056.tif125170

[0171] 5.16 SCIPU Delta QP Notification Example #3 [Table 24] TIFF0007597893000058.tif187170TIFF0007597893000059.tif243170TIFF0007597893000060.tif125170

[0172] 5.17 SCIPU Delta QP Notification Example #4 [Table 25] TIFF0007597893000062.tif195170TIFF0007597893000063.tif243170TIFF0007597893000064.tif125170

[0173] FIG. 17 is a block diagram of a video processing device 1700. The device 1700 may be used to implement one or more of the methods described herein. The device 1700 may be embodied in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 1700 may include one or more processors 1702, one or more memories 1704, and video processing hardware 1706. The processor 1702 may be configured to implement one or more of the methods described herein. The memory(s) 1704 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 1706 may be used to implement some of the techniques described herein in a hardware circuit. In some embodiments, the video processing hardware 1706 may be at least partially included within the processor 1702 (e.g., a graphics coprocessor).

[0174] 18 is a flow chart of a method 1800 for processing video. The method 1800 includes a step of parsing (1802) the coding representation according to syntax rules that define a relationship between a color format and a chroma block size of the video domain for conversion between a video domain of a video and a coding representation of the video domain, and a step of performing the conversion by performing the parsing according to the syntax rules (1804).

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

[0176] Some embodiments of the disclosed techniques include making a decision or determination to disable a video processing tool or mode. In an example, when the video processing tool or mode is disabled, the encoder does not use the tool or mode in converting blocks of video to a bitstream representation of the video. In another example, when the video processing tool or mode is disabled, the decoder processes the bitstream using the video processing tool or mode that was enabled based on the decision or determination, knowing that the bitstream is not altered.

[0177] As used herein, 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 conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits that are either in the same position or spread across different locations in the bitstream, e.g., as defined by a syntax. For example, a macroblock may be encoded with respect to a transformed and coded error residual value, as well as using bits in the header and other fields in the bitstream.

[0178] In some embodiments, the first set of bullets below may be implemented.

[0179] The following bullets can be implemented in conjunction with the additional techniques described in item 1 of the previous section.

[0180] 1. A method of video processing, comprising: - parsing the coding representation according to syntax rules that define a relationship between a color format and a chroma block size of the video domain for conversion between the video domain of the video and the coding representation of the video domain; performing a transformation by parsing according to syntax rules; The method includes:

[0181] 2. The method according to clause 1, The color format is 4:4:4. The syntax rules stipulate that chroma blocks follow the same size constraints as luma blocks: method.

[0182] 3. The method according to clause 1, The color format is 4:2:2. The syntax rules stipulate that chroma blocks follow the same size constraints as for the 4:2:0 color format, method.

[0183] 4. A method according to any one of clauses 1 to 3, comprising: The syntax rules stipulate that the prediction mode and small block partitions used depend on the chroma format. method.

[0184] 5. The method according to clause 1, The syntax rules define that a minimum allowable size is enabled for conversion of a video region based on a color format of the video region. method.

[0185] The following bullets can be implemented in conjunction with the additional techniques described in item 2 of the previous section.

[0186] 6. A method of video processing comprising: determining a coding mode for a coding tree node of the video based on characteristics of the video and a chroma format of the video; performing a conversion between a coding representation of the video and a video block of the coding tree node using the determined coding mode; The method includes:

[0187] 7. The method according to claim 6, Characteristics: i. the coding tree node is an M×N coding tree node using horizontal binary tree partitioning; ii. the coding tree node is an M×N coding tree node using vertical binary tree partitioning; iii. the coding tree node is an M×N coding tree node using a horizontal ternary tree partition; or iv. The coding tree node is an M×N coding tree node using vertical ternary tree division. If the chroma format is 4:2:0, the coding mode is determined to be MODE_TYPE_INTRA or MODE_TYPE_INTER. method.

[0188] 8. The method according to claim 7, M=8, or 16, or 32; N=4, or 8, or 16; method.

[0189] The following bullets can be implemented in conjunction with the additional techniques described in item 12 of the previous section.

[0190] 9. A method of video processing comprising: determining, based on the rules, whether a certain size of a chroma block is allowed in a video area of ​​the video; performing a conversion between the video domain and a coding representation of the video domain based on the determination; The method includes:

[0191] 10. The method according to claim 9, The rule states that 2×N chroma blocks are not allowed due to the video region containing a dual tree partition. method.

[0192] 11. The method according to claim 9, The rule states that 2×N chroma blocks are not allowed due to the video region containing a single tree partition. method.

[0193] 12. The method according to claim 10 or 11, N<=64, method.

[0194] The following bullets can be implemented in conjunction with the additional techniques described in items 13, 14, and 15 of the previous section.

[0195] 13. A method of video processing comprising: determining that the coding mode is allowed for a video region based on rules that allow use of the coding mode with respect to video conditions; performing a conversion between a coding representation of the pixels in the video domain and the pixels in the video domain based on the determination; The method includes:

[0196] 14. The method according to claim 13, The video condition is the block size, The rule allows the use of intra block copy mode for luma blocks of small block size. method.

[0197] 15. The method according to claim 14, Small block sizes include luma block sizes of 8x8, 8x8, 16x4 or 4xN. method.

[0198] 16. The method according to claim 13, The rule allows the use of intra block copy mode for the conversion of video regions that use the MODE_TYPE_INTER mode of coding, method.

[0199] 17. The method according to claim 13, The rule allows the use of palette coding modes for the conversion of video regions that use the MODE_TYPE_INTER mode of coding, method.

[0200] The following bullets can be implemented in conjunction with the additional techniques described in items 16, 17, and 18 of the previous section.

[0201] 18. A method of video processing comprising the steps of: performing a conversion between video blocks of a video and a coded representation of the video blocks using a video coding mode; Syntax elements that signal coding modes are selectively included in coding expressions based on rules, method.

[0202] 19. The method according to claim 18, the video coding mode is an intra-block coding mode; The rules provide for using a type of video coding mode to control the inclusion of a syntax element in a coding representation; method.

[0203] 20. The method according to claim 19, The rule states that non-SKIP blocks are explicitly notified. method.

[0204] 21. The method according to claim 18, The rule provides for implicit signaling of intra block copy flags based on the mode type and skip flags of a video block. method.

[0205] 22. The method according to claim 18, the video coding mode is a palette coding mode, The rules provide for selectively including a palette coding indicator based on a mode type of the video block. method.

[0206] The following bullets can be implemented in conjunction with the additional techniques described in item 21 of the previous section.

[0207] 23. A method of video processing comprising the steps of: determining that a chroma block has a size less than a threshold size such that a transform type used during conversion between the chroma block and a coding representation of the chroma block is different from a transform type used for a corresponding luma block conversion; performing the conversion based on the determination; The method includes:

[0208] 24. The method according to claim 23, The threshold size is M×N, M is 2, method.

[0209] The following bullets can be implemented in conjunction with the additional techniques described in item 22 of the previous section.

[0210] 25. A method according to any one of clauses 1 to 24, comprising: The conversion uses the inter-intra composite prediction mode as the MODE_TYPE_INTRA mode. method.

[0211] 26. A method according to any one of clauses 18 to 22, comprising: The conversion uses the inter-intra composite prediction mode as MODE_TYPE_INTER. method.

[0212] For example, if CIIP is considered to be MODE_TYPE_INTER, the method described in items 14-17 in the previous section may be applied, or if the method described in items 14-16 is applied, CIIP may be considered to be MODE_TYPE_INTER.

[0213] The following bullets can be implemented in conjunction with the additional techniques described in items 3-6 of the previous section.

[0214] 27. A method of video processing comprising the steps of: determining, based on a coding condition of the video domain, whether a minimum chroma block rule is enforced during conversion between the coding representation of the video domain and pixel values ​​of the video domain; performing the conversion based on the determination; The method includes:

[0215] 28. The method according to claim 27, The coding conditions include the color format of the video area; method.

[0216] 29. The method according to claim 28, the video region has a width of M pixels and a height of N pixels, the coding conditions further depending on the values ​​of M and / or N; method.

[0217] 30. The method according to claim 29, For video regions with 4:2:2 color format and M*N=32 or M*N=64, the minimum chroma block rule is enabled. method.

[0218] The following bullets can be implemented in conjunction with the additional techniques described in items 7-11 of the previous section.

[0219] 31. A method of video processing comprising the steps of: determining a mode type to be used for conversion between a coding representation of the video region in 4:2:2 format and pixel values ​​of the video region based on whether a minimum chroma block rule is valid for the video region; performing the conversion based on the determination; The method includes:

[0220] 32. The method according to claim 31, The mode type of the video region is set to 1 because the video region has a 4:2:2 format and the minimum chroma block rule is valid; method.

[0221] 33. The method according to claim 31, determining the mode type includes determining that the mode type is an INTRA type because a minimum chroma block rule is valid for the video region; method.

[0222] 34. The method according to claim 31, determining the mode type includes determining that the mode type INTER is invalid because a minimum chroma block rule is in effect for the video region; method.

[0223] The following bullets can be implemented in conjunction with the additional techniques described in items 7-11 of the previous section.

[0224] 35. A method of video processing comprising the steps of: for converting between the coding representation of the video block and a video block of the video, determining whether block partitions are allowed during the conversion based on a mode type or a dimension of the video block used during the conversion; performing a transformation using the decision; The method includes:

[0225] 36. The method according to claim 35, The block partition includes a binary tree partition or a ternary tree partition. method.

[0226] 37. The method according to claim 35 or 36, If the mode type is INTER mode, the block partition is based on the restriction rules that allow or disallow the partition type. method.

[0227] 38. A method according to any one of clauses 1 to 37, comprising: The conversion includes encoding the video into a coding representation. method.

[0228] 39. A method according to any one of clauses 1 to 37, comprising: The transforming includes decoding the coding representation to generate pixel values ​​of the video. method.

[0229] 40. A video decoding device comprising a processor configured to implement the methods described in one or more of clauses 1 to 39.

[0230] 41. A video encoding device comprising a processor configured to implement the methods described in one or more of clauses 1 to 39.

[0231] 42. A computer program product storing computer code, The code, when executed by a processor, causes the processor to implement a method according to any of clauses 1 to 39. Computer program products.

[0232] 43. Any method, apparatus, or system described herein.

[0233] The second set of bullets describes particular features and aspects of the technology disclosed in the previous section (eg, items 1, 3-11, 18, 19, and 24).

[0234] 1. A method of video processing (e.g., method 2110 shown in FIG. 21A), comprising: determining (2112) intra-coding characteristics of the video domain based on a color format of the video according to rules for conversion between the video domain and a coding representation of the video; performing a conversion according to an intra-coding characteristic (2114); The method includes:

[0235] 2. The method according to clause 1, The rule specifies that if the color format of the video region is 4:0:0 or 4:4:4, the intra-coding property specifies that all coding modes are valid for the video region, and the coding expression includes a MODE_TYPE_ALL value for a syntax element indicating a mode type used for the video region. method.

[0236] 3. The method according to claim 1 or 2, The rule specifies that if the color format is 4:0:0 or 4:4:4, the coding expression includes a syntax element indicating a condition for determining that the mode type is set to 0. method.

[0237] 4. The method according to any one of clauses 1 to 3, The rules specify that whether restrictions on the minimum allowed size for intra-coded chroma blocks in the video domain are valid depends on the color format. method.

[0238] 5. The method according to claim 4, The rule specifies that the restriction is valid for 4:2:0 and 4:2:2 formats, method.

[0239] 6. The method according to claim 4, The rule specifies that the restriction is disabled for the 4:0:0 and 4:4:4 formats. method.

[0240] 7. A method of video processing (e.g., the method 2120 shown in FIG. 21B), comprising: performing (2122) a conversion between a current video block of the video and a coded representation of the video; The coding representation conforms to a format rule, and the format rule specifies a syntax element modeType indicating a coding mode of the current video block equal to either MODE_TYPE_NO_INTER, which restricts the use of inter coding modes for the transform, or MODE_TYPE_NO_INTRA, which restricts the use of intra modes for the transform. method.

[0241] 8. A method of video processing (e.g., the method 2120 shown in FIG. 21B), comprising: performing (2122) a conversion between the video and a coding representation of the video; the coding representation conforms to a format rule that specifies that if the chroma format of the video is 4:2:2, 4:0:0, or 4:4:4, then the coding representation does not include a flag indicating a prediction mode constraint; method.

[0242] 9. The method according to claim 8, If a flag is not present, the corresponding value is inferred to be 0 or 1. method.

[0243] 10. A method of video processing (e.g., the method 2130 shown in FIG. 21C), comprising: determining (2132) whether and / or how a restriction on the size of the smallest chromintra prediction block to the video domain according to the rules is enabled for conversion between the video domain and a coding representation of the video; performing a transformation based on the determination (2134); Including, The rules depend on whether the video's color format is 4:2:0 or 4:2:2. method.

[0244] 11. A method of video processing comprising: determining whether a restriction on a size of a smallest chrominance intra prediction block to a video domain according to a rule is valid for conversion between a video domain and a coding representation of the video; performing the conversion based on the determination; Including, The rules depend on the color format of the video and / or the width (M) and height (N) of the video region, and the rules further specify that for a video region that is a coding tree node having a BT (binary tree) partition, the restriction on the minimum chrominance intra-predicted block is invalid if 1) the color format of the video is 4:2:2, and 2) the multiplication of M and N is a value from a set of values, the set of values ​​including 64. method.

[0245] 12. The method according to claim 11, The rule further specifies that the restriction on the minimum chrominance intra-predicted block is valid if 1) the color format of the video is 4:2:2, and 2) the set of values ​​further includes 32. method.

[0246] 13. The method according to claim 11, The rule further specifies that the restriction on the minimum chrominance intra-predicted block is invalid if 1) the color format of the video is 4:2:2; and 2) the set of values ​​further includes 128. method.

[0247] 14. The method according to claim 11, The rule further specifies that for a video region that is a coding tree node with split_qt_flag equal to 1, the restriction on the minimum chroma intra-predicted block is valid if the color format of the video is 4:2:2. method.

[0248] 15. The method according to claim 11, The rule further specifies that for a video region that is a coding tree node having a TT (ternary tree) partition, the restriction on the minimum chrominance intra-prediction block is valid if the color format of the video is 4:2:2. method.

[0249] 16. The method according to claim 11, The rule further specifies that for a video region that is a coding tree node having a BT (binary tree) partition, the restriction on the minimum chrominance intra-predicted block is valid if 1) the color format of the video is 4:2:2, and 2) the set of values ​​further includes 32. method.

[0250] 17. The method according to any one of clauses 11 to 16, The rule further specifies that for a smallest chromintra-predicted block in a video having a 4:2:2 color format, modeTypeCondition is always equal to 1. method.

[0251] 18. The method according to any one of clauses 11 to 17, The rules further specify that for the smallest chrominance intra-predicted block in a video having a 4:2:2 color format, only MODE_TYPE_INTRA is allowed, which enables the use of intra mode, palette mode and intra block copy mode for conversion. method.

[0252] 19. A method of video processing comprising the steps of: performing a conversion between a video domain of the video and a coding representation of the video, subject to a constraint on a minimum chrominance intra prediction block size; the coding representation conforms to format rules that specify values ​​of syntax fields in the coding representation for the 4:2:2 color format of the video; method.

[0253] 20. The method according to claim 19, The syntax field corresponds to the modeTypeCondition of the SCIPU block, and the format rule further specifies that for the 4:2:2 color format, modeTypeCondition is always 1. method.

[0254] 21. The method according to claim 19, The syntax field corresponds to the modeTypeCondition of the SCIPU block, and the format rule further specifies that for the 4:2:2 color format, the modeTypeCondition is 0 or 1. method.

[0255] 22. The method according to claim 19, The syntax field corresponds to the modeTypeCondition of the SCIPU block, and the format rule further specifies that for a 4:2:2 color format, the modeTypeCondition is not 2. method.

[0256] 23. The method according to claim 19, The syntax field corresponds to the modeType of the SCIPU block, and the format rule further specifies that for 4:2:2 color format, the modeType is always equal to MODE_TYPE_INTRA, which enables the use of intra mode, palette mode and intra block copy mode. method.

[0257] 24. The method according to claim 19, The syntax field corresponds to the modeType of the SCIPU block, and the format rule further specifies that for 4:2:2 color format, the modeType is equal to 1) MODE_TYPE_ALL, which enables the use of inter-coding mode, intra mode, palette mode, and intra block copy mode for the conversion, or 2) MODE_TYPE_INTRA, which enables the use of intra mode, palette mode, and intra block copy mode. method.

[0258] 25. The method according to claim 19, The syntax field corresponds to a modeType of the SCIPU block, and the format rule further specifies that for a 4:2:2 color format, the modeType does not correspond to MODE_TYPE_INTER, which enables the use of only the inter mode for the conversion. method.

[0259] 26. A method of video processing (e.g., the method 2140 shown in FIG. 21D), comprising: determining (2142) an applicability of a partition scheme to a current video block according to the rules for conversion between a current video block of the video and a coding representation of the video; performing a transformation based on the determination (2144); The method includes:

[0260] 27. The method according to claim 26, The rule specifies that the determination is based on at least one of a mode type used during the transformation or a dimension of the current video block, and the partitioning scheme includes a binary tree (BT) partition and / or a ternary tree (TT) partition; method.

[0261] 28. The method according to claim 27, If the mode type is equal to MODE_TYPE_INTER, which enables the use of only inter mode for the transform, then BT splitting is not allowed for the current video block; method.

[0262] 29. The method according to claim 27, If the mode type is equal to MODE_TYPE_INTER, which enables the use of only inter mode for the transform, then TT splitting is not allowed for the current video block; method.

[0263] 30. The method according to claim 27, If M*N is less than or equal to 32 and the mode type is equal to MODE_TYPE_INTER, which allows the use of only inter mode for the transformation, then BT splitting is not allowed, and M and N correspond to the height and width of the current video block. method.

[0264] 31. The method according to claim 27, If M*N is less than or equal to 64 and the mode type is equal to MODE_TYPE_INTER, which allows the use of only inter mode for the transformation, then TT splitting is not allowed, and M and N correspond to the height and width of the current video block. method.

[0265] 32. The method according to claim 26, The rule specifies restricting a particular partitioning scheme based on a syntax element modeTypeCurr that is included in the coding expression and describes a mode type to be used during the transformation, the particular partitioning scheme including BT (binary tree) partitioning, TT (ternary tree) partitioning, and / or QT (quad tree) partitioning; method.

[0266] 33. The method according to claim 32, For modeTypeCurr equal to MODE_TYPE_INTER, which allows the use of only the inter mode for the conversion, BT splitting is not allowed. method.

[0267] 34. The method according to claim 32, For modeTypeCurr equal to MODE_TYPE_INTER, which allows the use of only the inter mode for the conversion, TT splitting is not allowed. method.

[0268] 35. The method according to claim 32, For modeTypeCurr equal to MODE_TYPE_INTER, which allows the use of only the inter mode for conversion, QT splitting is not allowed. method.

[0269] 36. The method according to claim 32, BT splitting is not allowed if modeTypeCurr is equal to MODE_TYPE_INTER, which allows the use of only inter mode for the transform, and the luma block size is less than or equal to 32. method.

[0270] 37. The method according to claim 32, TT splitting is not allowed if modeTypeCurr is equal to MODE_TYPE_INTER, which allows the use of only inter mode for the transform, and the luma block size is less than or equal to 64. method.

[0271] 38. A method of video processing (e.g., the method 2150 shown in FIG. 21E), comprising: determining (2152) whether an inter mode is valid according to the rules for converting between video blocks of the video and a coding representation of the video; performing a transformation based on the determination (2154); Including, The rule specifies that inter mode is valid if dual tree partitioning of luma samples is valid for a video block. method.

[0272] 39. The method according to claim 38, The coding representation includes a syntax field equal to DUAL_TREE_LUMA, method.

[0273] 40. The method according to claim 38, A coding unit coded in inter mode contains only luma samples for color formats having multiple color components; method.

[0274] 41. The method according to claim 38, the coding representation includes a flag indicating a prediction mode to be applied to the video block, the flag being parsed for the video block corresponding to the luma block having the dual tree type; method.

[0275] 42. The method according to claim 38, The rules further specify that the same constraints for inter modes apply regardless of whether dual-tree partitioning or single-tree partitioning of luma samples is in effect for a video block. method.

[0276] 43. A method of video processing (e.g., method 2160 shown in FIG. 21F), comprising: determining (2162) whether the use of palette mode is permitted for the video domain based on the rules for conversion between the video domain of the video and a coding representation of the video; performing a transformation based on the determination (2164); Including, Palette mode involves encoding a video region using a palette of representative sample values; method.

[0277] 44. The method according to claim 43, The rule specifies that paletted mode is allowed if the video region mode type is equal to MODE_TYPE_INTRA, which allows the use of intra mode, paletted mode, and intra block copy mode for the transformation, or MODE_TYPE_INTER, which allows the use of only inter mode for the transformation. method.

[0278] 45. The method according to claim 43, The rule specifies that palette modes are allowed independently of the video region mode type. method.

[0279] 46. ​​The method according to claim 43, The rules are based on the slice type and mode type of the video region: method.

[0280] 47. The method according to claim 46, The rule specifies that paletted mode is allowed for I-slices where the mode type is equal to MODE_TYPE_INTRA, which allows the use of intra mode, paletted mode, and intra block copy mode for the conversion. method.

[0281] 48. The method according to claim 46, The rule specifies that palette mode is allowed for P / B slices where the mode type is equal to MODE_TYPE_INTRA, which allows the use of intra mode, palette mode, and intra block copy mode for the conversion. method.

[0282] 49. The method according to claim 43, The rule further specifies that if palette mode is permitted, then local dual trees are not permitted. method.

[0283] 50. The method according to claim 43, If palette mode is enabled, modeTypeCondition is always set to 0. method.

[0284] 51. A method of video processing comprising the steps of: performing a conversion between a current video block of the video and a coded representation of the video; the coding representation conforms to a format rule, the format rule specifying a syntax element modeType including MODE_TYPE_IBC to enable use of an intra block copy mode for the transformation, or MODE_TYPE_PALETTE to enable use of a palette mode for the transformation, the intra block copy mode including encoding the current video block using at least a block vector that points to a video frame that includes the current video block, and the palette mode including encoding the current video block using a palette of representative sample values. method.

[0285] 52. The method according to claim 51, The format rule further specifies that if modeType is MODE_TYPE_IBC or MODE_TYPE_PALETTE, the coding expression does not include pred_mode_flag, pred_mode_ibc_flag, and / or pre_mode_plt_flag. method.

[0286] 53. The method according to claim 51, The coding representation includes, instead of mode_constraint_flag, an index indicating the mode type used for the transformation. method.

[0287] 54. The method according to any one of clauses 1 to 53, The conversion includes encoding the video into a coding representation. method.

[0288] 55. A method according to any one of clauses 1 to 53, comprising: The converting includes decoding the coding representation to generate the video. method.

[0289] 56. A video processing device including a processor configured to implement the methods described in one or more of clauses 1 to 55.

[0290] 57. A computer-readable medium having program code stored thereon, which, when executed, causes a processor to implement a method according to any one or more of clauses 1 to 55; Computer-readable medium.

[0291] 58. A computer readable medium storing a coding or bitstream representation generated according to any of the above methods.

[0292] The third set of bullets describes particular features and aspects of the technology disclosed in the previous section (eg, items 25-33).

[0293] 1. A method of video processing, comprising: for conversion between a current video block of a video and a coding representation of the video, determining whether a particular partitioning scheme is allowed for the current video block according to rules that depend on a coding mode type used to represent the current video block in the coding representation and dimensions of the current video block; performing the conversion based on the determination; The method includes:

[0294] 2. The method according to clause 1, Specific partitioning schemes include a QT (quadtree) partitioning, where the current video block is divided into four parts both horizontally and vertically; a vertical TT (ternary tree) partitioning, where the current video block is divided into three parts vertically; a horizontal TT partitioning, where the current video block is divided into three parts horizontally; a vertical BT (binary tree) partitioning, where the current video block is divided into two parts vertically; and / or a horizontal BT partitioning, where the current video block is divided into two parts horizontally. method.

[0295] 3. The method according to clause 1, The rule specifies that if 1) the coding representation includes a MODE_TYPE_INTER value corresponding to a coding mode type in which only inter mode is allowed for the current video block, and 2) both the width and height of the current video block are 8, then QT (quadtree) decomposition is not allowed for the current video block. method.

[0296] 4. The method according to clause 1, The rule specifies that if 1) the coding representation includes a MODE_TYPE_INTER value corresponding to a coding mode type in which only inter mode is allowed for the current video block, and 2) the multiplication of the width and height of the current video block is 64, then TT (ternary tree) partitioning is not allowed for the current video block. method.

[0297] 5. The method according to claim 4, The rule further specifies that if the coding expression includes the MODE_TYPE_INTER value and the width and height of the current video block are 16 and 4, respectively, then vertical TT (ternary tree) partitioning is not allowed. method.

[0298] 6. The method according to claim 4, The rule further specifies that if the coding representation includes the MODE_TYPE_INTER value and the width and height of the current video block are 4 and 16, respectively, then horizontal TT (ternary tree) partitioning is not allowed. method.

[0299] 7. The method according to clause 1, The rule specifies that if 1) the coding representation includes a MODE_TYPE_INTER value corresponding to a coding mode type in which only inter mode is allowed for the current video block, and 2) the multiplication of the width and height of the current video block is 32, then BT (binary tree) partitioning is not allowed for the current video block. method.

[0300] 8. The method according to claim 7, The rule further specifies that if the coding expression includes the MODE_TYPE_INTER value and the width and height of the current video block are 8 and 4, respectively, then vertical BT (binary tree) partitioning is not allowed. method.

[0301] 9. The method according to claim 7, The rule further specifies that if the coding representation includes the MODE_TYPE_INTER value and the width and height of the current video block are 4 and 8, respectively, then horizontal BT (binary tree) splitting is not allowed. method.

[0302] 10. A method of video processing comprising: performing a conversion between video blocks of the video and a coded representation of the video; the coding representation conforms to a format rule, the format rule specifying that a characteristic of the video block controls whether a syntax element in the coding representation indicates a prediction mode of the video block. method.

[0303] 11. The method according to claim 10, The characteristics of the video block include at least one of a color component or a dimension of the video block. method.

[0304] 12. The method according to claim 10 or 11, The format rule further specifies that the syntax element indicates a prediction mode of a video block corresponding to the chroma block. method.

[0305] 13. The method according to any one of clauses 10 to 12, The format rule further specifies that the syntax element does not indicate a prediction mode of a video block corresponding to the luma block, and a prediction mode of the video block corresponding to the luma block is included in the coding representation. method.

[0306] 14. The method according to claim 13, A video block has a width and height greater than 4, method.

[0307] 15. A method of video processing comprising: performing a conversion between a video domain of a first component of the video and a coding representation of the video; the coding representation conforms to a format rule, the format rule specifying whether and / or how a syntax field is configured in the coding representation to indicate a differential quantization parameter for a video domain depends on a partitioning scheme used to partition the samples of the first component. method.

[0308] 16. The method according to claim 15, The formatting rules further specify that whether and / or how syntax fields are structured in the coding representation is independent of the partitioning scheme used to partition samples of the second component of the video. method.

[0309] 17. The method according to claim 15 or 16, The first component is the luma component and the second component is the chroma component. method.

[0310] 18. The method according to claim 15 or 16, The first component is the chroma component and the second component is the luma component. method.

[0311] 19. The method according to claim 15, The format rules further specify that in a particular region where the luma and chroma components share the same mode type, information related to the differential quantization parameter is included at most once. method.

[0312] 20. The method according to claim 15, A particular region corresponds to a quantization group. method.

[0313] 21. A method of video processing comprising the steps of: performing a conversion between a video domain of a first component of the video and a coding representation of the video according to rules; The rules specify that when a dual tree and / or a local dual tree coding structure is applied to a video domain, a variable associated with a differential quantization parameter of a first component is not changed during a process of decoding or parsing a second component of the video. method.

[0314] 22. The method according to claim 21, the local dual tree structure is applied to the video domain, where a restriction on the minimum allowed size for a chroma block is applied to the video domain; method.

[0315] 23. The method according to claim 21 or 22, The first component is the luma component and the second component is the chroma component. method.

[0316] 24. The method according to claim 21 or 22, The first component is the chroma component and the second component is the luma component. method.

[0317] 25. The method according to any one of clauses 21 to 24, The differential quantization parameter indicates the difference between a quantization value applied to a video block and a previous quantization value applied to an adjacent video block. method.

[0318] 26. The method according to any one of clauses 1 to 25, Performing the transformation includes generating a coding representation from the video; method.

[0319] 27. The method according to any one of clauses 1 to 25, Performing the conversion includes generating a video from the coding representation. method.

[0320] 28. A video processing device comprising a processor configured to implement the methods described in any one or more of clauses 1 to 27.

[0321] 29. A computer-readable medium having program code stored thereon, which, when executed, causes a processor to implement a method according to any one or more of clauses 1 to 27; Computer-readable medium.

[0322] 30. A computer readable medium storing a coding or bitstream representation generated according to any of the above methods.

[0323] The disclosed and other solutions, examples, embodiments, modules and functional operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein 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 controlling 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 one or more combinations thereof. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. An apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, such as code constituting a processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof. A propagated signal is an artificially generated signal, for example a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to an appropriate receiver device.

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

[0325] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC).

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

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

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

[0329] Only a few implementations and examples have been described; other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1. 1. A method for processing video data, comprising the steps of: for a first conversion between a current video block of a video and a bitstream of the video, determining whether a partition scheme is allowed for the current video block according to rules that depend on a mode type of the current video block and dimensions of the current video block; performing the first transformation based on the determination; Including, The method, wherein the rule specifies that 1) the mode type of the current video block is MODE_TYPE_INTER, in which only inter-coding mode is allowed for the current video block, and 2) if the multiplication of the width and height of the current video block is 64, then TT (ternary tree) partitioning is not allowed for the current video block.

2. The partitioning method is: QT (quadtree) partitioning, in which the current video block is partitioned into four parts both horizontally and vertically; a vertical ternary tree (TT) partition in which the current video block is divided vertically into three parts; a horizontal TT partition in which the current video block is divided into three parts in a horizontal direction; a vertical binary tree (BT) partition in which the current video block is divided vertically into two parts; or Horizontal BT division in which the current video block is divided into two parts horizontally. The method of claim 1 , comprising:

3. The method of claim 1 or 2, wherein the dimensions of the current video block include a height or a width of the current video block.

4. the rule specifies that if the width of the current video block is equal to 16 and the height of the current video block is equal to 4, then a vertical TT split is not allowed for the current video block; 4. The method of claim 1, wherein the rule specifies that if the width of the current video block is equal to 4 and the height of the current video block is equal to 16, then horizontal TT splitting is not allowed for the current video block.

5. The rule specifies that if 1) the mode type of the current video block is MODE_TYPE_INTER, where only inter-coding modes are allowed for the current video block, and 2) a multiplication of a width and height of the current video block is 32, then BT (binary tree) partitioning is not allowed for the current video block; the rule specifies that if the width of the current video block is equal to 8 and the height of the current video block is equal to 4, then a vertical BT split is not allowed for the current video block; 5. The method of claim 1, wherein the rule specifies that if the width of the current video block is equal to 4 and the height of the current video block is equal to 8, then horizontal BT splitting is not allowed for the current video block.

6. determining whether to split the luma parent blocks and the chroma parent blocks into one or more luma blocks and one or more chroma blocks, respectively, for a second conversion between a video slice including the luma parent blocks and a bitstream of the video, where a mode type of the luma blocks or a mode type of the chroma blocks is determined based on a value of a variable, the value of the variable being derived based on a color format of the video slice; performing the second transformation based on the determination; and Further comprising: the luma parent block is generated from a luma coding tree block (CTB) based on a luma partitioning scheme that includes a recursive partitioning operation; The method of claim 1 , wherein the chroma parent blocks are generated from a chroma coding tree block (CTB) based on a chroma partitioning scheme having the same recursive partitioning operation as the luma partitioning scheme.

7. if the color format of the video slice is 4:0:0 or 4:4:4, the value of the variable is set to 0; if the value of the variable is 0, the mode type of the luma block and the mode type of the chroma block are MODE_TYPE_ALL, the mode type having a value of MODE_TYPE_ALL specifying that all coding modes are available for the luma block and the chroma block; The method of claim 6 , wherein if the value of the variable is 0, then a mode constraint flag is not included in the bitstream, and the value of the mode constraint flag specifies whether an inter-predictive coding mode is available.

8. The method of claim 6 or 7, wherein the value of the variable is derived further based on a size of the luma parent block and a first predetermined partition mode of the luma parent block.

9. In response to the luma parent block having a size of 64, the color format of the video slice being not equal to 4:0:0 and 4:4:4, and the first predetermined partition mode being a QT (quadtree) partition, the variable is equal to 1; or In response to the luma parent block having a size of 32, the color format of the video slice being not equal to 4:0:0 and 4:4:4, and the first predetermined partition mode being a binary tree (BT) partitioning, the variable is equal to 1; or the variable is set to 1 in response to a slice type of the video slice being equal to an I slice, the color format of the video slice being 4:2:0, the luma parent block having a size of 64, and the first predefined partition mode being a binary tree (BT) partitioning, the variable is set to 0 in response to a color format of the video slice being 4:2:2, the luma parent block having a size of 64, and the first predefined partition mode being a binary tree (BT) partitioning, or 9. The method of claim 8, wherein the variable is set to 1 in response to a slice type of the video slice being equal to an I slice, the color format of the video slice being 4:2:0, the luma parent block having a size of 128, and the first predefined partition mode being a TT (ternary tree) partitioning, and wherein the variable is set to 0 in response to a color format of the video slice being 4:2:2, the luma parent block having a size of 128, and the first predefined partition mode being a TT (ternary tree) partitioning.

10. 10. The method of claim 8 or 9, wherein in response to the value of the variable being 1, the chroma parent block is not allowed to be partitioned and the first predefined partition mode is allowed for the luma parent block.

11. the variable is set to 2 in response to a slice type not equal to I slice, the color format of the video slice is 4:2:0, the luma parent block has a size of 64, and the first predefined partition mode is a binary tree (BT) partitioning, the variable is set to 0 in response to a slice type not equal to I slice, the color format of the video slice is 4:2:2, the luma parent block has a size of 64, and the first predefined partition mode is a binary tree (BT) partitioning, or 11. The method of claim 8, wherein the variable is set to 2 in response to the slice type being not equal to an I slice, the color format of the video slice being 4:2:0, the luma parent block having a size of 128, and the first predefined partition mode being a TT (ternary tree) partitioning, and the variable is set to 0 in response to the color format of the video slice being 4:2:2, the luma parent block having a size of 128, and the first predefined partition mode being a TT (ternary tree) partitioning.

12. In response to the value of the variable being two, a mode constraint flag is included in the bitstream, the mode constraint flag specifying whether an inter-predictive coding mode is available; 12. The method of claim 8, wherein in response to the value of the variable being 2 and the mode constraint flag specifying that an inter-predictive coding mode is not available, the chroma parent block is not allowed to be partitioned and the first predetermined partition mode is allowed for the luma parent block.

13. The method of claim 1 , wherein the first conversion comprises encoding the video into the bitstream.

14. The method of claim 1 , wherein the first conversion comprises decoding the video from the bitstream.

15. 1. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions, the apparatus comprising: The instructions, when executed by the processor, cause the processor to: for a first conversion between a current video block of a video and a bitstream of the video, determining whether a partition scheme is allowed for the current video block according to rules that depend on a mode type of the current video block and dimensions of the current video block; performing the first transformation based on the determination; Run the command, The rule specifies that 1) the mode type of the current video block is MODE_TYPE_INTER, in which only inter-coding mode is allowed for the current video block, and 2) if the multiplication of the width and height of the current video block is 64, then TT (ternary tree) partitioning is not allowed for the current video block.

16. 1. A non-transitory computer-readable storage medium, comprising: The processor: for a first conversion between a current video block of a video and a bitstream of the video, determining whether a partition scheme is allowed for the current video block according to rules that depend on a mode type of the current video block and dimensions of the current video block; performing the first transformation based on the determination; The instruction to execute the The rule specifies that 1) the mode type of the current video block is MODE_TYPE_INTER, where only inter-coding mode is allowed for the current video block, and 2) if the multiplication of the width and height of the current video block is 64, then TT (ternary tree) partitioning is not allowed for the current video block.

17. 1. A method for storing a video bitstream, comprising: determining, for a current video block of a video, whether a partition scheme is allowed for the current video block according to rules that depend on a mode type of the current video block and a dimension of the current video block; generating the bitstream based on the determination; storing the bitstream in a non-transitory computer readable storage medium; Including, The method, wherein the rule specifies that 1) the mode type of the current video block is MODE_TYPE_INTER, in which only inter-coding mode is allowed for the current video block, and 2) if the multiplication of the width and height of the current video block is 64, then TT (ternary tree) partitioning is not allowed for the current video block.

Images