Size restrictions based on color format

Abstract

A method of video processing is provided, the method including performing a conversion between a video having one or more video regions having one or more luma blocks and one or more chroma blocks and a coded representation of the video according to a rule. The rule specifies that a chroma block among one or more chroma blocks having a size M×N is not allowed to be represented in the coded representation using an intra mode or an intra block copy mode, where M and N are integers indicating the width and height of the chroma block, respectively. The intra mode includes encoding the chroma block based on a previously encoded or reconstructed video block, and the intra block copy mode includes encoding the chroma block using at least one block vector that points to a video frame including the video region.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] Book This application claims priority to and claims the benefit of International Patent Application No. PCT / CN2019 / 099447, filed August 6, 2019. National phase entry of International Patent Application No. PCT / CN2020 / 107400 filed on August 6, 2020, claiming the benefit thereof is . above The All Out Wish , The full text of them By reference To the original vow To be incorporated.

[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 communication networks, and as the number of connected user devices capable of receiving and displaying video increases, the bandwidth demands for digital video usage are expected to continue to increase. Summary of the Invention

[0004] The disclosed techniques may be used by video or image decoder or encoder embodiments 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, according to a rule, a partitioning scheme based on a color format of a video to partition a chroma video region of the video into one or more chroma blocks; and performing a conversion between the video and a coded representation of the video according to the partitioning scheme.

[0006] In another example aspect, another method of video processing is disclosed, the method including: determining, based on a color format of a video, a prediction mode or a prediction type for sub-blocks of a coding tree node of the video; and, based on the determination, performing a conversion between the video and a coded representation of the video, the coding tree node being partitioned into sub-blocks for coding in the coded representation.

[0007] In another exemplary aspect, another method of video processing is disclosed. The method includes performing a conversion between a video having one or more video regions, the video regions having one or more luma blocks and one or more chroma blocks, and a coded representation of the video according to a rule, the rule specifying that a chroma block among the one or more chroma blocks having a size M×N is not allowed to be represented in the coded representation using an intra mode or an intra block copy mode, where M and N are integers indicating a width and a height of the chroma block, respectively, the intra mode including encoding the chroma block based on a previously encoded or reconstructed video block, and the intra block copy mode including encoding the chroma block using at least one block vector that points to a video frame including the video region.

[0008] In another example aspect, another method of video processing is disclosed, the method including: determining, according to a rule, to use a combined inter and intra prediction (CIIP) mode as an intra mode or an inter mode for conversion between a video domain of a video and a coded representation of the video; and performing the conversion based on the determination, the CIIP mode including combining an intra prediction signal and an inter prediction signal using weighting factors.

[0009] In another example aspect, another method of video processing is disclosed, the method including: performing a conversion between chroma blocks of a video and an encoded representation of the video, the chroma blocks being represented in the encoded representation using intra-coding modes according to a size rule, the size rule specifying that if a width of the chroma blocks is equal to M or a height of the chroma blocks is equal to N, the intra-coding mode is from a first set of intra-coding mode types; otherwise, the intra-coding mode is from a second set of intra-coding mode types, where M and N are integers.

[0010] In another exemplary aspect, another method of video processing is disclosed, the method including performing a transformation between chroma blocks of a video and a coded representation of the video, the chroma blocks being represented in the coded representation using a transformation type according to a rule, the rule defining that if a width of the chroma block is equal to M or a height of the chroma block is equal to N, the transformation type is from a first set of transformation types, and otherwise the transformation type is from a second set of transformation types, where M and N are integers.

[0011] In another example aspect, another method of video processing is disclosed. The method includes performing a conversion between a video having a video region having one or more luma blocks and one or more chroma blocks and a coded representation of the video according to a rule, wherein the rule specifies that for all values ​​of M and N, use of an intra block copy (IBC) mode is available for the one or more luma blocks and the one or more chroma blocks having a block size M×N, where M and N are integers, and wherein using the IBC mode, a video block is coded using at least one block vector that points to a video frame that includes the video block.

[0012] In another example aspect, another method of video processing is disclosed, the method including performing a conversion between a video block of a video and a coded representation of the video block, the coded representation conforming to a format rule, the format rule defining selective inclusion in the coded representation of a video block based on a mode type of the video block of the video block of the video, the IBC mode including encoding the video block using at least one block vector that points to a video frame that includes the video block of the video block.

[0013] In another example aspect, another method of video processing is disclosed, the method including performing a conversion between a video block of a video and a coded representation of the video block, the coded representation following a format rule, the format rule specifying that a syntax element indicating use of a palette mode is included in the coded representation regardless of a mode type of the video block, the palette mode including encoding the video block using a palette of representative sample values.

[0014] In another example aspect, another method of video processing is disclosed, the method including: determining, based on a rule, that an Inter Block Copy (IBC) mode is allowed for use for a conversion between a video region of a video and a coded representation of the video; and performing the conversion based on the determination, the IBC mode including encoding the video region using at least one block vector that points to a video frame that includes the video region.

[0015] In another exemplary aspect, another method of video processing is disclosed, the method including: for a conversion between a video region of a video and a coded representation of the video, determining based on rules whether use of a palette mode is allowed for the video region; and performing the conversion based on the determination, the rules being based on a coding mode type of the video region or a color type of the video region, and the palette mode including encoding the video region using a palette of representative sample values.

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

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

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

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

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

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

[0022] 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 may be combined with embodiments in other sections.

[0023] 1. Overview This document relates to video coding techniques. Specifically, 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.

[0024] 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, while ISO / IEC produced MPEG-1 and MPEG-4 Visual. The two organizations jointly produced the 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 architecture that utilizes temporal prediction plus transform coding. 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 techniques have been adopted by the JVET and incorporated 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.

[0025] The latest version of the VVC draft, i.e. Versatile Video Coding (Draft 4), can be found at http: / / phenix.it-sudparis.eu / jvet / doc_end_user / current_document.php?id=5755.

[0026] The latest reference software for VVC, named VTM, can be found at https: / / vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM / tags / VTM-5.0.

[0027] 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 Figure 1, when IBC is applied, the current block is predicted by a reference block in the same picture. Samples in the reference block are already reconstructed before the current block is encoded or decoded. Although IBC is not very efficient for most camera-captured sequences, it represents a significant coding improvement for screen content. This is because screen content pictures contain many repetitive patterns, such as icons and text characters. IBC can effectively remove redundancy among these repetitive 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 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.

[0028] Following 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. Transformation and quantization can then be applied as seen in other coding modes.

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

[0030] 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 ​​will be undefined. Basically, there are two solutions to handle such problems. One is to disallow such situations, for example, in bitstream conformance. The other is to apply padding to those undefined pixel values. The following subsections describe these solutions in detail.

[0031] 2.2 IBC in HEVC-SCC HEVC 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 specification text: [Table 1]

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

[0033] 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 predicted block. The IBC flag is coded as the prediction mode of the current CU. Therefore, there are a total of three prediction modes for each CU: MODE_INTRA, MODE_INTER, and MODE_IBC.

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

[0035] 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 derivation order is A1, B1, B0, A0, and B2. Position B2 is considered only if any PU at positions A1, B1, B0, A0 is unavailable (because it belongs to another slice or tile) or is not coded in IBC mode. After the candidate at position A1 is added, the insertion of the remaining candidates undergoes a redundancy check. This ensures that candidates with the same motion information are removed from the list, thereby improving coding efficiency. To reduce computational complexity, not all possible candidate pairs are considered in the above redundancy check. Instead, 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.

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

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

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

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

[0040] 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 the following sequence of steps: Step 1: Derive spatial candidates Check A0, A1 until an available candidate is found Check B0, B1, B2 until an available candidate is found Step 2: Inserting HMVP candidates Step 3: Inserting zero candidates

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

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

[0043] 2.4 Palette Mode The basic idea behind 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. Palette mode is illustrated in Figure 2.

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

[0045] In the palette mode in HEVC-SCC, a predictive method is used to code the palette and index map.

[0046] 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 for initializing 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 using the palette predictor initializer entry signaled in the PPS. In HEVC-SCC, a palette predictor initializer of size 0 is enabled to allow explicit disabling of palette predictor initialization at the PPS level.

[0047] For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette. 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 exponential-Golomb coding of degree 0. Finally, the component values ​​of the new palette entry are signaled.

[0048] FIG. 3 shows an example of the use of a palette predictor to signal palette entries.

[0049] 2.5.2 Palette Index Coding 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.

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

[0051] Palette indices are coded using two main palette sample modes: "INDEX" and "COPY_ABOVE". As mentioned above, escape symbols are also signaled as "INDEX" mode and are assigned an index equal to the maximum palette size. The mode is signaled using a flag, except for 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 signaled explicitly. For both "INDEX" and "COPY_ABOVE" modes, a run value is signaled, which specifies the number of subsequent samples that are also coded using the same mode. An escape component value is signaled for each escape symbol if the escape symbol is part of a run in "INDEX" or "COPY_ABOVE" mode. The coding of palette indices is shown in Figure 5.

[0052] 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 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 and coded in bypass mode.

[0053] An additional syntax element, last_run_type_flag, is signaled after signaling the index value, which, in combination with the index number, eliminates the need to signal the run value corresponding to the last run in the block.

[0054] 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 indices 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 signaling relates to 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.

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

[0056] FIG. 5 shows an example of encoding a palette index.

[0057] 2.6 Intramode Coding in VVC To capture any edge direction present in natural video, the number of directional intra modes in VTM5 is expanded from 33 used in HEVC to 65. The new directional modes not found in HEVC are represented by the red dashed 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.

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

[0059] In HEVC, every intra-coded block has a square shape, and the length of each side is a power of 2. Therefore, 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.

[0060] FIG. 6 shows an example of 67 intra-prediction modes.

[0061] To keep the complexity of generating the most probable mode (MPM) list 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

[0062] 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 upper neighboring blocks. Assuming that the mode of the left block is denoted as Left and the mode of the upper block is denoted as Above, the unified MPM list is constructed as follows (the left block and the upper block are shown in Figure 7):

[0063] 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. · When both modes Left and Above are non-angle modes: ·MPM List → {Planer, 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 the mode Max as the larger of Left and Above. ·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 the mode Max as the larger of Left and Above. When the difference between the Left and Above modes 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}

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

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

[0066] A total of eight intra modes are allowed for chroma intra mode coding. These modes include five conventional 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 Tables 2-4. Chroma mode coding directly depends on the intra prediction mode of the corresponding luma block. Since separate block partitioning structures for luma and chroma components are enabled in an 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]

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

[0068] 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 residuals after performing intra prediction horizontally (copying the left neighboring pixel value line by line across the predicted block) or vertically (copying the upper neighboring line onto each line within 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 and predicted block values. Block DPCM is then applied to the quantized residual samples, resulting in the element (outside 1) Modified MxN array with TIFF0007779830000003.tif9127 (outside 2) TIFF0007779830000004.tif9127 is obtained. When vertical BDPCM is notified:

number

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

number

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

[0071] On the decoder side, the above calculation is i,j ), 0≦i≦M-1, 0≦j≦N-1, for the vertical prediction case,

number

number

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

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

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

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

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

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

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

number

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

[0080] Figure 9 shows an example 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.

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

number

[0082] The maximum and minimum values ​​of the two diagonal gradients are:

number

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

[0084] The activity value A is

number

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

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

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

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

number

[0089] 2.8.1.4 Filter Parameter Notification In VTM5, 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.

[0090] The clipping value index decoded from the APS allows determining the clipping values ​​using a luma table of clipping values ​​and a chroma table of clipping values. These clipping values ​​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

[0091] 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 decoder.

[0092] 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 -2. 7 2 more 7 Bitstream conformance applies such that the value 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.

[0093] 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 the sample value R'(i,j) given by:

number

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

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

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

[0097] 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, when 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.

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

[0099] 2.9 Sample Adaptive Offset (SAO) 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 Tables 2-6. The concept of SAO is to classify pixels into categories and reduce distortion by adding an offset to pixels in each category. SAO operations include edge offset (EO), which uses edge characteristics for pixel classification in SAO types 1 to 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. If sao_merge_up_flag is equal to 1, the current CTB reuses the SAO type and offset of the CTB above. [Table 5]

[0100] 2.9.1 Operation of each SAO type The 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.

[0101] Figure 12 shows four example one-dimensional three-pixel patterns for pixel classification in EO.

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

[0103] Band offset (BO) classifies all pixels within one CTB region into 32 uniform bands by using the five 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, and each group is indicated by its leftmost position as shown in Figure 13. The encoder searches all positions to obtain the group that reduces distortion the most by compensating for the offset of each band.

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

[0105] 2.10 Combined Inter-Intra Prediction (CIIP) In VTM5, when 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 combined inter / intra prediction (CIIP) mode is currently applied to the CU. As the name suggests, CIIP prediction combines the inter prediction signal with the 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, and the 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 Figure 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.

[0106] The CIIP forecast is formed as follows:

number

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

[0108] 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 the luma component based on an adaptive piecewise linear model, and 2) application of luma-dependent chroma residual scaling for the chroma component. Figure 15 shows the LMCS architecture from the decoder start. The blocks in Figure 15 include inverse quantization, inverse transform, luma intra prediction, and adding luma prediction with the luma residual, where processing is applied in the mapped domain. 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 the chroma residual, and storing the decoded picture as a reference picture. Figure 15 shows the new LMCS functional blocks, including forward and backward mapping of the luma signal and the luma-dependent chroma scaling process. Like most other tools in VVC, LMCS can be enabled / disabled at the sequence level using the SPS flag.

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

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

[0111] Because the binary tree in intra-picture allows a different partitioning to be applied in the chroma coding tree than in the luma coding tree, the binary 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 2x2, 4x2, and 2x4, which poses 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 (2x2 / 2x4 / 4x2) are restricted in the binary tree as partitioning restrictions.

[0112] 2.13 Minimal Chroma Intra Prediction Unit (SCIPU) in JVET-O0050 Small chroma sizes are not friendly to hardware implementation. In the case of a binary tree, chroma blocks of too small size are not allowed. However, in the case of a single tree, VVC Draft 5 still allows 2x2, 2x4, and 4x2 chroma blocks. To limit the size of chroma blocks, in a single coding tree, JVET-O0050 defines a SCIPU as a coding tree node whose chroma block size is greater than or equal to the TH chroma sample and has at least one child luma block smaller than the 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 the case of a non-inter SCIPU, it is further required that the chroma of the non-inter SCIPU should not be further divided, and the luma of the SCIPU is allowed to be further divided. 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 SCIPUs.

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

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

[0115] If the current slice is an I slice or the current SCIPU has a 4x4 luma partition in it after being further divided once, 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 signal flag before parsing the CUs in the SCIPU.

[0116] 2.14 Small Chroma Block Restrictions in VVC Draft 6 In VVC draft 6 (JVET-O2001-vE.docx), the constraint on small chroma blocks is implemented as follows (relevant parts are marked in bold italics): [Table 7] TIFF0007779830000024.tif204166TIFF0007779830000025.tif217166TIFF00077798300 00026.tif227166TIFF0007779830000027.tif230166TIFF0007779830000028.tif214161 TIFF0007779830000029.tif231154TIFF0007779830000030.tif211158TIFF00077798300 00031.tif230158TIFF0007779830000032.tif230155TIFF0007779830000033.tif185159

[0117] 3. Challenges (1) Currently, IBC is considered as 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 as the palette may not apply 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 incorrect in syntax parsing. (7) Currently, non-4x4 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.

[0118] 4. Examples of technical solutions and embodiments The following should be considered as examples. These techniques should not be construed in a narrow sense. Furthermore, these techniques can be combined in any way.

[0119] 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. 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 uni-tree coding, two chroma color components for binary tree chroma coding, and only one luma component for binary 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 a block size M×N equal to 32 / 64 / 128 in luma samples.

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

[0121] 1. Whether and / or how to partition into small blocks may depend on the color format. a. 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 those constraints for a 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 be applied. 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 blocks 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 blocks 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 MxN (e.g., 8x16) coding tree node using horizontal TT partitioning, in a 4:2:2 chroma format, horizontal TT partitioning may be allowed for both chroma blocks 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 MxN (e.g., 32x4) coding tree node using vertical TT partitioning, in a 4:2:2 chroma format, vertical TT partitioning may be allowed for both chroma blocks 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.

[0122] 2. How the prediction mode (and / or modeType) for a (sub)mode of a coding tree node should be determined may depend on the color format. a. In one example, if one of the following conditions is true, 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. MxN (e.g., 8x8) coding tree nodes using horizontal BT partitioning ii. MxN (e.g., 16x4) coding tree nodes using vertical BT partitioning iii. MxN (e.g., 8x16) coding tree nodes using horizontal TT partitioning iv. MxN (e.g., 32x4) coding tree nodes using vertical TT partitioning

[0123] For example, if one of the following conditions is true: i) luma 8x8 blocks with horizontal BT, ii) luma 16x4 blocks with vertical BT, iii) luma 8x16 blocks with horizontal TT, iv) luma 32x4 blocks with vertical TT, then modeType may be set as MODE_TYPE_ALL for 4:2:2, while modeType must be either MODE_TYPE_INTRA or MODE_TYPE_INTER for 4:2:0.

[0124] Thus, for a block with three color components in a coding tree node, if one of the above conditions is true, the 4:2:0 block is not classified as MODE_TYPE_ALL (all coding modes can be selected), but as either MODE_TYPE_INTRA (block can select palette, intra or intra block copy) or MODE_TYPE_INTER (only inter mode can be selected).

[0125] 3. Chroma Intra (and / or IBC) blocks with block width equal to M (eg, M=2) chroma samples may not be allowed. In one example, chrominance intra blocks of 2×N (eg, N<=64) may not be allowed in the binary 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 the uni-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 4xN or 4x(N / 2) chroma blocks, but may be allowed for 8xN luma blocks. 2. The 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 is allowed for both 8xN luma blocks and 4xN or 4x(N / 2) chroma blocks, but both luma and chroma blocks are not coded by MODE_INTRA (e.g., they can 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 8xN or 8x(N / 2) chroma blocks, but may be allowed for 16xN luma blocks. 2. The 8×N or 8×(N / 2) chroma block may not be vertical TT split, it can be coded by MODE_INTRA or MODE_IBC. 3. Vertical TT splitting is allowed for both 16xN luma blocks and 8xN or 8x(N / 2) chroma blocks, but both luma and chroma blocks are not coded by MODE_INTRA (e.g., they can be coded by MODE_INTER or MODE_IBC).

[0126] 4. IBC mode may be allowed for luma and / or chroma blocks, regardless of whether it is a small block size or not. a. 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 chroma blocks even if modeType is equal to MODE_TYPE_INTRA.

[0127] 5. The signaling of the IBC prediction mode flag may depend on the prediction mode type (eg, MODE_TYPE_INTRA). a. In one example, the IBC prediction mode flags of non-SKIP blocks (e.g., coding modes 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.

[0128] 6. The IBC prediction mode flag may be inferred depending on the CU SKIP flag and the mode type (eg, modeType). a. 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, the IBC prediction mode flag (eg, pred_mode_ibc_flag) may be inferred to be equal to 1.

[0129] 7. Explicit notification 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.

[0130] 8. IBC mode may be allowed to be used if modeType equals MODE_TYPE_INTER. a. In one example, chroma IBC may not be allowed if modeType is equal to MODE_TYPE_INTRA. b. In one example, 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, both IBC and inter modes may be allowed within one SCIPU. 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, signaling of pred_mode_ibc_flag may be skipped and pred_mode_ibc_flag may be inferred to be equal to 1.

[0131] 9. Palette mode may be allowed to be used when modeType is MODE_TYPE_INTER. In one example, chroma palettes may not be allowed when modeType is MODE_TYPE_INTRA. b. In one example, palette mode may be allowed to be used if modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER. c. In one example, palette mode may be allowed to be used no matter what the modeType is. d. In one example, within one SCIPU, both palette and inter modes may be allowed. e. In one example, within one SCIPU, pallets, IBCs and intermodes may all be allowed. f. In one example, the size of a palette chroma block always corresponds to the size of the corresponding luma block. g. In one example, if modeType is equal to MODE_TYPE_INTER and the coding unit size is 4x4 in luma, signaling of pred_mode_plt_flag may be skipped and pred_mode_plt_flag may be inferred to be equal to 1. h. 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.

[0132] 10. For small chroma blocks with width equal to M (e.g., M=2) and height 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. a. 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 INTRA_DC mode may be used. c. In one example, only 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.

[0133] 11. For small chroma blocks with width equal to M (e.g., M=2) and height 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 transform skip may be used. b. In one example, only one-dimensional transforms may be used. c. In one example, coding tools that support multiple types of transformations are not permitted. i. Alternatively, notification of coding tools that support multiple types of transformations is omitted.

[0134] 12. CIIP may be considered as MODE_TYPE_INTRA. a. In one example, CIIP mode may be enabled when binary tree partitioning is 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), 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 limited 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 limited 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 chrominance intra prediction. 3. In one example, the INTRA_ANGULAR50 mode may be used for chrominance intra prediction.

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

[0136] 5. Embodiments, 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).

[0137] 5.1 Example Embodiment #1 The following embodiment relates to constraints on partitions and prediction modes of small blocks 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]

[0138] 5.2 Example Embodiment #2 The following embodiment relates to the fact that notification of the palette mode flag does not depend on the modeType. [Table 10]

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

[0140] 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 they are small block sizes or not. [Table 12]

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

[0142] 5.6 Example Embodiment #6 The following embodiment relates to not allowing 2xN chroma intra blocks in the unitree. [Table 14]

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

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

[0145] FIG. 17A 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 is a hardware circuit and may be used to implement some of the techniques described herein. In some embodiments, the video processing hardware 1706 may be at least partially or completely contained within the processor 1702 (e.g., a graphics coprocessor).

[0146] FIG. 17B is another example block diagram of a video processing system in which the disclosed techniques may be implemented. FIG. 17B is a block diagram illustrating an example video processing system 1710 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1710. System 1710 may include an input 1712 that receives video content. The video content may be received in raw or uncompressed format, e.g., 8- or 10-bit multi-component pixel values, or in a compressed or encoded format. Input 1712 may correspond to a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, passive optical networks (PONs), etc., and wireless interfaces such as Wi-Fi or cellular networks.

[0147] System 1710 may include a coding component 1714 that may implement various coding or encoding methods described herein. Coding component 1714 may reduce the average bitrate of video from input 1712 to an output of coding component 1714 to generate a coded representation of the video. Coding techniques are therefore sometimes referred to as video compression or video transcoding techniques. The output of coding component 1714 may be stored or transmitted via a connected communication, as represented by component 1716. The stored or communicated bitstream (or coded) representation of the video received at input 1712 may be used by component 1718 to generate pixel values ​​or displayable video that is sent to display interface 1720. The process of generating user-viewable video from the bitstream representation is sometimes referred to as video decompression. Furthermore, while certain video processing operations are referred to as “coding” operations or tools, it will be understood that such coding tools or operations are used in an encoder, and that corresponding decoding tools or operations that transpose the results of the coding would be performed by a decoder.

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

[0149] 18 is a flowchart of a method 1800 for processing video. The method 1800 includes, for conversion between a video region of a video and a coded representation of the video region, parsing the coded representation according to syntax rules that define a relationship between a color format and a chroma block size of the video region (1802), and performing the conversion by performing the parsing according to the syntax rules (1804).

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

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

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

[0153] In some implementations, the conversion is performed between chroma blocks of the video and an encoded representation of the video, and the chroma blocks are represented in the encoded representation using intra-coding modes according to a size rule, where the size rule specifies that if the width of the chroma blocks is equal to M or the height of the chroma blocks is equal to N, then the intra-coding mode is from a first set of intra-coding mode types, and otherwise the intra-coding mode is from a second set of intra-coding mode types, where M and N are integers.

[0154] In some implementations, a transformation is performed between chroma blocks of a video and a coded representation of the video, and the chroma blocks are represented in the coded representation using a transformation type according to a rule, where the rule specifies that if the width of the chroma block is equal to M or the height of the chroma block is equal to N, then the transformation type is from a first set of transformation types, and otherwise the transformation type is from a second set of transformation types, where M and N are integers.

[0155] In some implementations, the conversion is performed between a video having a video region with one or more luma blocks and one or more chroma blocks and a coded representation of the video according to rules, where the rules specify that for all values ​​of M and N, use of intra block copy (IBC) mode is available for one or more luma blocks and one or more chroma blocks having block size M×N, where M and N are integers, and where using IBC mode, a video block is coded using at least one block vector that points to a video frame containing the video block.

[0156] In some implementations, the conversion is performed between a video block of a video and an encoded representation of that video block, the encoded representation following a format rule, the format rule defining the selective inclusion of a syntax element indicating the use of an inter-block copy (IBC) mode in the encoded representation based on a mode type of the video block, the IBC mode including encoding the video block using at least one block vector that points to a video frame that includes the video block.

[0157] In some implementations, a conversion is performed between a video block of a video and an encoded representation of that video block, the encoded representation following a format rule, the format rule specifying that a syntax element indicating the use of a palette mode is included in the encoded representation regardless of the mode type of the video block, the palette mode including encoding the video block using a palette of representative sample values.

[0158] 22B is a flowchart of a method 2220 for processing video. The method 2220 includes, at step 2222, determining to use a combined inter-intra prediction (CIIP) mode as an intra mode or an inter mode according to a rule for converting between a video domain of the video and a coded representation of the video. The method 2220 further includes, at step 2314, performing the conversion based on the determination. The CIIP mode includes combining the intra prediction signal and the inter prediction signal using weighting factors.

[0159] 23A is a flowchart of a method 2310 for processing video. The method 2310 includes, at step 2312, determining that the video region is allowed to use an inter-block copy (IBC) mode for converting between a video region of the video and a coded representation of the video based on the rules. The method 2310 further includes, at step 2314, performing the conversion based on the determination. The IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region.

[0160] 23B is a flowchart of a method 2320 for processing video. The method 2320 includes, at step 2322, determining whether the use of palette mode is allowed for the video region based on rules for converting between a video region of the video and a coded representation of the video. The method 2320 further includes, at step 2324, performing the conversion based on the determination. In some implementations, the rules are based on a coding mode type of the video region or a color type of the video region, and the palette mode includes encoding the video region using a palette of representative sample values.

[0161] 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 from blocks of video to a bitstream representation of video uses the video processing tool or mode if 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 knowing that the bitstream has been modified based on the video processing tool or mode. That is, conversion from a 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.

[0162] 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 unchanged.

[0163] 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 the conversion of 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 within the bitstream, e.g., as defined by 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 within the bitstream.

[0164] The following bullets describe some embodiments and techniques: The first set of bullets describes certain features and aspects of the techniques disclosed in the previous section.

[0165] 1. A method of video processing, comprising: parsing a video domain of a video and a coded representation of the video domain according to syntax rules defining a relationship between a color format and a chroma block size of the video domain for conversion between the video domain and the coded representation; performing said conversion by parsing according to said syntax rules; A method having the following.

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

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

[0168] 4. The method according to any one of clauses 1 to 3, The syntax rules specify that the prediction mode and small block partitions to be used depend on the chroma format. method.

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

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

[0171] 6. A method of video processing, comprising: determining a coding mode of a coding tree node of the video based on characteristics of the video and a chroma format of the video; performing a conversion between the coded representation of the video and the video blocks of the coding tree node using the determined coding mode; A method having the following.

[0172] 7. The method according to clause 6, The characteristics are: 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 MxN coding tree node using horizontal ternary tree partitioning; 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.

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

[0174] The following bullet points can be implemented in conjunction with the additional techniques described in item 3 of the previous section.

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

[0176] 10. The method according to clause 9, The rule specifies that 2xN chroma blocks are not allowed due to the video region containing a binary tree partition. method.

[0177] 11. The method according to clause 9, The rule specifies that 2xN chroma blocks are not allowed due to the video region containing a unitree partition. method.

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

[0179] The following bullet points can be implemented in conjunction with the additional techniques described in items 4, 8, and 9 of the previous section.

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

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

[0182] 15. The method according to clause 14, The small block size includes a luma block size of 8x8, 8x8, 16x4, or 4xN. method.

[0183] 16. The method according to clause 13, the rules allow the use of intra block copy mode for the transformation of the video region using MODE_TYPE_INTER mode of coding; method.

[0184] 17. The method according to clause 13, the rules allow the use of palette coding mode for the transformation of the video region using MODE_TYPE_INTER mode of coding; method.

[0185] The following bullets can be implemented in conjunction with the additional techniques described in items 5, 6, and 7 of the previous section.

[0186] 18. A method of video processing, comprising: converting between video blocks of a video and coded representations of the video blocks using a video coding mode; a syntax element indicating the coding mode is selectively included in the coded representation based on the rule; method.

[0187] 19. The method according to clause 18, the video coding mode is an intra-block coding mode; the rules define using the type of the video coding mode to control the inclusion of the syntax element in the coded representation. method.

[0188] 20. The method according to clause 19, The rule specifies that non-SKIP blocks are explicitly notified. method.

[0189] 21. The method according to clause 18, The rule provides for implicitly signaling an intra block copy flag based on a mode type and a skip flag of the video block. method.

[0190] 22. The method according to clause 18, the video coding mode is a palette coding mode; the rules provide for selective inclusion of a palette coding indicator based on a mode type of the video block. method.

[0191] The following bullet points can be implemented in conjunction with the additional techniques described in item 11 of the previous section.

[0192] 23. A method of video processing, comprising: 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 coded 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; A method having the following.

[0193] 24. The method according to clause 23, the threshold size is M×N; M is 2, or N is 2; method.

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

[0195] 25. A method according to any one of clauses 1 to 24, comprising: The transformation uses an inter-intra hybrid prediction mode as a MODE_TYPE_INTRA mode. method.

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

[0197] For example, if CIIP is considered to be MODE_TYPE_INTER, the method described in items 5+6+7 in the previous section may be applied, or alternatively, if the method described in items 5+6+7 is applied, CIIP may be considered to be MODE_TYPE_INTER.

[0198] 27. A method according to any one of clauses 1 to 26, comprising: the converting comprises encoding the video into the encoded representation. method.

[0199] 28. A method according to any one of clauses 1 to 26, comprising: the converting comprises decoding the coded representation to generate pixel values ​​of the video. method.

[0200] 29. A video decoding device having a processor configured to implement the methods described in one or more of clauses 1 to 28.

[0201] 30. A video encoding device having a processor configured to implement the methods described in one or more of clauses 1 to 28.

[0202] 31. A computer program product storing computer code, the code, when executed by a processor, causes the processor to implement a method according to any one of clauses 1 to 28; Computer program products.

[0203] 32. Any method, apparatus, or system described herein.

[0204] The second set of bullets describes certain features and aspects of the techniques disclosed in the previous sections, eg, Example Examples 1, 2, and 13.

[0205] 1. A method of video processing, comprising: determining a partitioning scheme for partitioning a chroma video region of the video into one or more chroma blocks based on a color format of the video according to a rule; performing a conversion between the video and a coded representation of the video in accordance with the partitioning scheme; A method having the following.

[0206] 2. The method according to clause 1, The rule specifies an inter-slice or an intra-slice having three color components represented by the same coding tree node. method.

[0207] 3. The method according to paragraph 1 or 2, The rules stipulate that for a 4:4:4 color format, the same partitioning scheme is used for chroma blocks and luma blocks. method.

[0208] 4. The method according to clause 1 or 2, The rules provide for using the same partitioning constraints for 4:2:0 color format and 4:2:2 color format. method.

[0209] 5. The method according to clause 1 or 2, the rules specify that the partitioning scheme and / or constraints do not apply to prediction modes for a 4:0:0 color format or a 4:4:4 color format. method.

[0210] 6. The method according to clause 1 or 2, the rules specify the partitioning scheme and / or prediction mode to be applied based on the color format of the video. method.

[0211] 7. The method according to clause 6, For an M×N coding tree node with horizontal BT (binary tree) partitioning or estimated TT (ternary tree) partitioning, in a 4:2:2 color format, the horizontal BT partitioning or the horizontal TT partitioning is allowed for both chroma blocks and luma blocks. method.

[0212] 8. The method according to clause 6, For an MxN coding tree node with a horizontal BT (binary tree) partition or a horizontal TT (ternary tree) partition, in a 4:2:0 color format, the horizontal BT partition or the horizontal TT partition is allowed for luma blocks but not for chroma blocks; method.

[0213] 9. The method according to clause 6, For an M×N coding tree node with vertical BT (binary tree) or TT (ternary tree) partitioning, in a 4:2:2 color format, the vertical BT or TT partitioning is allowed for both chroma and luma blocks. method.

[0214] 10. The method according to clause 6, For an MxN coding tree node with a vertical BT (binary tree) partition or a vertical TT (ternary tree) partition, in a 4:2:0 color format, the vertical BT partition or the vertical TT partition is allowed for luma blocks but not for chroma blocks; method.

[0215] 11. The method according to any one of clauses 7 to 10, M and / or N are predefined or signaled; method.

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

[0217] 13. The method according to clause 6, the rule specifies that the partitioning scheme does not apply to a 4:0:0 color format and / or a 4:4:4 color format; method.

[0218] 14. The method according to clause 1, The rule specifies that a minimum chroma intra prediction unit (SCIPU) defined to limit the size of a chroma block is enabled for the conversion based on the color format of the video. method.

[0219] 15. The method according to clause 14, the minimum chrominance intra-prediction unit is allowed for a 4:2:0 color format and / or a 4:2:2 color format; method.

[0220] 16. The method according to clause 14, the minimum chrominance intra-prediction unit is disabled for 4:0:0 color format and / or 4:4:4 color format; method.

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

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

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

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

[0225] 21. The method according to any one of clauses 18 to 20, The coding tree node satisfies the following conditions: i) the coding tree nodes correspond to 8x8 luma blocks with horizontal binary tree partitioning; ii) the coding tree nodes correspond to 16x4 luma blocks with vertical binary tree decomposition; iii) the coding tree nodes correspond to 8x16 luma blocks with horizontal ternary tree decomposition; or iv) the coding tree nodes correspond to 32x4 luma blocks with vertical ternary tree decomposition; satisfy one of the following: method.

[0226] 22. The method according to clause 17, the coding tree nodes are M×N coding tree nodes, where M and / or N are predefined or signaled; method.

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

[0228] 24. A method according to any one of clauses 1 to 23, comprising: performing the conversion includes generating the coded representation from the video; method.

[0229] 25. A method according to any one of clauses 1 to 23, comprising: performing the conversion includes generating the video from the coded representation; method.

[0230] 26. A video processing device having a processor configured to implement the method according to any one of clauses 1 to 25.

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

[0232] The third set of bullets describes certain features and aspects of the techniques disclosed in the previous sections, eg, Example Examples 3 and 10-13.

[0233] 1. A method of video processing, comprising: performing a conversion between a video having one or more video regions having one or more luma blocks and one or more chroma blocks and a coded representation of the video according to rules; the rule specifies that a chroma block of the one or more chroma blocks, the chroma block having a size of M×N, is not allowed to be represented in the coded representation using an intra mode or an intra block copy mode, where M and N are integers indicating a width and a height of the chroma block, respectively; the intra mode includes encoding the chroma block based on a previously encoded or reconstructed video block; and the intra block copy mode includes encoding the chroma block using at least one block vector that points to a video frame including a video region. method.

[0234] 2. The method according to clause 1, The rule specifies that chroma blocks having a size of 2×N are not allowed due to the video region being partitioned as a binary tree partition. method.

[0235] 3. The method according to clause 2, The rule specifies that vertical BT (binary tree) splitting is not allowed for a chroma block if i) the tree type of the chroma block is equal to binary tree type, and ii) M is equal to 4 chroma samples. method.

[0236] 4. The method according to clause 2, The rule specifies that vertical TT (ternary tree) splitting is not allowed for a chroma block if i) the tree type of the chroma block is equal to a binary tree type, and ii) M is equal to 8 chroma samples. method.

[0237] 5. The method according to clause 1, The rule specifies that chroma blocks having a size of 2×N are not allowed due to the video region being partitioned as unitree partitions. method.

[0238] 6. The method according to clause 5, For an MxN coding tree node with vertical BT (binary tree) partitioning, the vertical BT partitioning is not allowed for chroma blocks having a size of 4xN or 4x(N / 2), but is allowed for luma blocks having a size of 8xN. method.

[0239] 7. The method according to clause 5, For an MxN coding tree node with vertical BT (binary tree) partitioning, the vertical BT partitioning is not allowed for chroma blocks having a size of 4xN or 4x(N / 2). method.

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

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

[0242] 10. The method according to clause 5, For an MxN coding tree node with vertical TT (ternary tree) partitioning, the vertical TT partitioning is not allowed for chroma blocks having a size of 8xN or 8x(N / 2). method.

[0243] 11. The method according to clause 5, For an MxN coding tree node with vertical TT (ternary tree) partitioning, the vertical TT partitioning is allowed for chroma blocks having a size of 8xN or 8x(N / 2) and luma blocks having a size of 16xN, and the chroma blocks and luma blocks are not coded in the intra mode. method.

[0244] 12. A method of video processing, comprising: determining, according to a rule, to use a composite inter-intra prediction mode (CIIP) mode as an intra mode or an inter mode for conversion between a video domain of a video and a coded representation of said video; performing the conversion based on the determination; and The CIIP mode includes combining the intra prediction signal and the inter prediction signal using weighting factors; method.

[0245] 13. The method according to clause 12, The rule specifies that the CIIP mode is used as the intra mode according to the binary tree partitioning used in the video domain. method.

[0246] 14. The method according to clause 12, The rule specifies that the CIIP is used as the inter mode. method.

[0247] 15. The method according to clause 14, The rule provides that a chroma block having a width equal to M disables the CIIP mode. method.

[0248] 16. The method according to clause 12, The rule specifies that intra prediction modes for chroma blocks coded in the CIIP mode are restricted to the intra mode. method.

[0249] 17. The method according to clause 16, The intra prediction mode includes an intra_DC mode, an intra_angular18 mode, or an intra_angular50 mode. method.

[0250] 18. The method according to clause 16, the width of said chroma block is equal to 2; method.

[0251] 19. A method of video processing, comprising: performing a conversion between chroma blocks of a video and a coded representation of said video; the chroma blocks are represented in the coded representation using an intra-coding mode according to a size rule; The size rule specifies that if the width of the chroma block is equal to M or the height of the chroma block is equal to N, the intra-coding mode is from a first set of intra-coding mode types, and otherwise, the intra-coding mode is from a second set of intra-coding mode types, where M and N are integers. method.

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

[0253] 21. The method according to clause 19 or 20, the first set of intra-coding mode types is a subset of all allowed intra-coding mode types in the transform. method.

[0254] 22. The method according to clause 19 or 20, the first set of intra-coding mode types corresponds to an INTRA_DC mode; method.

[0255] 23. The method according to clause 19 or 20, the first set of intra-coding mode types corresponds to an INTRA_PLANAR mode; method.

[0256] 24. The method according to clause 19 or 20, the first set of intra-coding mode types corresponds to an INTRA_ANGULAR18 mode; method.

[0257] 25. The method according to clause 19 or 20, the first set of intra-coding mode types corresponds to an INTRA_ANGULAR50 mode; method.

[0258] 26. The method according to clause 19 or 20, The rule specifies that CCLM modes that use a linear mode to derive predictions for chroma components from other components are disabled. method.

[0259] 27. A method of video processing, comprising: performing a conversion between chroma blocks of a video and a coded representation of said video; the chroma blocks are represented in a coded representation using a transform type according to a rule; The rule defines that if the width of the chroma block is equal to M or the height of the chroma block is equal to N, then the transformation type is from a first set of transformation types, otherwise the transformation type is from a second set of transformation types, where M and N are integers. method.

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

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

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

[0263] 31. A method according to any one of clauses 1 to 30, comprising: the converting includes encoding the video into the coded representation. method.

[0264] 32. A method according to any one of clauses 1 to 30, comprising: the converting includes decoding the coded representation to generate the video. method.

[0265] 33. A video processing device having a processor configured to implement the method described in any one or more of clauses 1 to 32.

[0266] 34. A computer readable medium storing program code that, when executed, causes a processor to implement the method set forth in any one or more of clauses 1 to 32.

[0267] The fourth set of bullets describes certain features and aspects of the techniques disclosed in the previous section, eg, in Example Examples 4-9 and 13.

[0268] 1. A method of video processing, comprising: performing a conversion between a video having a video region having one or more luma blocks and one or more chroma blocks and a coded representation of the video according to rules; The rule specifies that use of intra block copy (IBC) mode is available for the one or more luma blocks and the one or more chroma blocks with a block size of M×N for all values ​​of M×N, where M and N are integers; Using the IBC mode, a video block is coded using at least one block vector that points to the video frame that contains the video block. method.

[0269] 2. The method according to clause 1, The rules stipulate that luma blocks have a size of 8x4, 8x8, 16x4, or 4xN. method.

[0270] 3. The method according to clause 2, the luma block has a mode type equal to MODE_TYPE_INTRA, which indicates the applicability of intra mode, the IBC mode, and palette mode; method.

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

[0272] 5. A method of video processing, comprising: performing a conversion between a video block of a video and a coded representation of the video block; the coded representation follows a format rule, the format rule defining the selective inclusion of a syntax element indicating use of an inter-block copy (IBC) mode in the coded representation based on a mode type of the video block, the IBC mode including encoding the video block using at least one block vector that points to a video frame that includes the video block. method.

[0273] 6. The method according to clause 5, the format rule specifies explicitly signaling the syntax element for the video block not coded in skip mode if the tree type of the video block is not equal to DUAL_TREE_CHROMA and the mode type of the video block is equal to MODE_TYPE_INTRA, which indicates applicability of intra mode, the IBC mode, and palette mode. method.

[0274] 7. The method according to clause 5, the formatting rules define inferring the syntax elements based on a mode type and a skip flag of the video block. method.

[0275] 8. The method according to clause 7, the format rule specifies that the syntax element is inferred to be equal to 1 for the video block being coded in skip mode if the mode type of the video block is equal to MODE_TYPE_INTRA, which indicates applicability of intra mode, the IBC mode, and palette mode. method.

[0276] 9. A method of video processing, comprising: performing a conversion between a video block of a video and a coded representation of the video block; the coded representation follows a format rule, the format rule specifying that a syntax element indicating use of a palette mode be included in the coded representation regardless of a mode type of a video block, the palette mode including encoding the video block using a palette of representative sample values. method.

[0277] 10. The method according to clause 9, the format rules define explicit signaling based on at least one of a prediction mode, a block size, or a slice type of the video block. method.

[0278] 11. The method according to clause 9, the format rule specifies that the syntax element is inferred to be equal to 0 if the mode type of the video block is equal to MODE_TYPE_INTER, indicating applicability of only an inter-coding mode, or MODE_TYPE_INTRA, indicating applicability of an intra mode, an IBC mode, and a palette mode. method.

[0279] 12. A method of video processing, comprising: determining, based on rules, that use of an interblock copy (IBC) mode is allowed for a video region of a video for conversion between the video and a coded representation of the video; performing the conversion based on the determination; and the IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region; method.

[0280] 13. The method according to clause 12, The rule specifies that the IBC mode is allowed if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates applicability of only inter-coding mode. method.

[0281] 14. The method according to clause 12, The rule specifies that if the mode type of the video region is equal to MODE_TYPE_INTRA, which indicates applicability of intra mode, the IBC mode, and palette mode, the IBC mode is not allowed for a chroma block. method.

[0282] 15. The method according to clause 12, The rule specifies that the IBC mode is allowed if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates applicability of only inter-coding mode, or MODE_TYPE_INTRA, which indicates applicability of intra mode, the IBC mode, and palette mode. method.

[0283] 16. The method according to clause 12, The rule specifies that the IBC mode is allowed regardless of the mode type of the video region. method.

[0284] 17. The method according to clause 12, The IBC and inter modes are allowed within a minimum chroma intra prediction unit (SCIPU) defined to limit the size of a chroma block. method.

[0285] 18. The method according to clause 12, chroma blocks coded using the IBC mode have a size corresponding to the size of the luma block to which they correspond; method.

[0286] 19. The method according to clause 12, The notification of the syntax element indicating the use of the IBC mode is skipped, The syntax element is inferred to be equal to 1 if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates the applicability of inter-coding modes only, and the video region corresponds to 4x4 luma blocks. method.

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

[0288] 21. The method according to clause 20, The rule specifies that the palette mode is allowed if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates applicability of only inter-coding mode. method.

[0289] 22. The method according to clause 20, The rule specifies that if the mode type of the video region is equal to MODE_TYPE_INTRA, which indicates applicability of intra mode, IBC mode, and palette mode, the palette mode is not allowed for a chroma block; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region; method.

[0290] 23. The method according to clause 20, The rule specifies that the palette mode is allowed if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates applicability of only inter-coding mode, or MODE_TYPE_INTRA, which indicates applicability of intra mode, IBC mode, and palette mode; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region; method.

[0291] 24. The method according to clause 20, the rule specifies that the palette mode is allowed regardless of the mode type of the video region; method.

[0292] 25. The method according to clause 20, The palette mode and inter mode are allowed within a minimum chroma intra prediction unit (SCIPU) defined to limit the size of a chroma block. method.

[0293] 26. The method according to clause 20, The palette mode, IBC mode, and inter mode are all allowed within a minimum chroma intra-prediction unit (SCIPU) defined to limit the size of a chroma block; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region; method.

[0294] 27. The method according to clause 20, a chroma block coded using the palette mode has a size corresponding to the size of its corresponding luma block; method.

[0295] 28. The method according to clause 20, The notification of the syntax element indicating the use of the palette mode is skipped, The syntax element is inferred to be equal to 1 if the mode type of the video region is equal to MODE_TYPE_INTER, which indicates the applicability of inter-coding modes only, and the video region corresponds to 4x4 luma blocks. method.

[0296] 29. The method according to clause 20, a syntax element indicating the use of the palette mode or IBC mode is included in the coded representation if 1) the mode type of the video region is equal to MODE_TYPE_INTER, indicating the applicability of only inter-coding mode, and 2) the video region corresponds to 4x4 luma blocks; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that includes the video region; method.

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

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

[0299] 32. A method according to any one of clauses 1 to 31, comprising: performing the conversion includes generating the coded representation from the video; method.

[0300] 33. A method according to any one of clauses 1 to 31, comprising: performing the conversion includes generating the video from the coded representation; method.

[0301] 34. A video processing device having a processor configured to implement the method described in any one or more of clauses 1 to 33.

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

[0303] 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 one or more combinations thereof. 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 apparatuses, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, an apparatus can include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof. A propagated signal is an artificially generated signal, for example, a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to an appropriate receiver device.

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

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

[0306] Processors suitable for executing a computer program 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. Typically, a processor will read instructions and data from read-only memory or random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices, e.g., magnetic, optical-magnetic, or optical disks, for storing data, or be operatively coupled to receive data from, 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, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; optical-magnetic disks; and all forms of non-volatile memory, media, and memory devices, including CD-ROM and DVD-ROM disks. The processor and memory may be enhanced by, or incorporated in, dedicated logic circuitry.

[0307] While this specification contains numerous details, these 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 in 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, while features may be described above as operating in a particular combination and even initially claimed as such, one or more features from a claimed combination may in some cases be deleted from that combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

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

[0309] 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: determining a rule-based scheme for partitioning a luma parent block of the coding tree node and a chroma parent block of the coding tree node and predicting one or more luma blocks from the luma parent block and one or more chroma blocks from the chroma parent block for conversion between a coding tree node of a video and a bitstream of the video; performing said transformation according to said scheme; and The rule specifies that a chroma block to which a third prediction mode is applied is constrained to have a width of 4 or greater; In the third prediction mode, the intra prediction signal and the inter prediction signal are combined by coefficients to generate a prediction signal. method.

2. The rule further provides that when a tree type of a chroma block is equal to a dual tree type, the chroma block is constrained to have a width greater than two chroma samples. The method of claim 1.

3. The rule further specifies that if the tree type of the chroma parent block is equal to a dual tree type and the width of the chroma parent block is equal to 4 chroma samples, vertical BT (binary tree) splitting is disabled for the chroma parent block. The method of claim 2.

4. The rule further specifies that if the tree type of the chroma parent block is equal to a dual tree type and the width of the chroma parent block is equal to 8 chroma samples, vertical TT (ternary tree) splitting is disabled for the chroma parent block. The method of claim 2.

5. the rule specifies that the intra prediction signal in the third prediction mode is derived based on a planar mode. The method of claim 1.

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

7. the converting includes decoding the video from the bitstream.

6. The method according to any one of claims 1 to 5.

8. 1. An apparatus for processing video data, comprising: a processor and a non-transitory memory having instructions; The instructions, when executed by the processor, cause the processor to: determining a rule-based scheme for partitioning a luma parent block of the coding tree node and a chroma parent block of the coding tree node and predicting one or more luma blocks from the luma parent block and one or more chroma blocks from the chroma parent block for conversion between a coding tree node of a video and a bitstream of the video; performing the transformation based on the scheme; Execute The rule specifies that a chroma block to which a third prediction mode is applied is constrained to have a width of 4 or greater; The apparatus, wherein in the third prediction mode, the intra prediction signal and the inter prediction signal are combined by coefficients to generate a prediction signal.

9. A non-transitory computer-readable storage medium storing instructions, comprising: The instructions, when executed by a processor, cause the processor to: determining a rule-based scheme for partitioning a luma parent block of the coding tree node and a chroma parent block of the coding tree node and predicting one or more luma blocks from the luma parent block and one or more chroma blocks from the chroma parent block for conversion between a coding tree node of a video and a bitstream of the video; performing the transformation based on the scheme; Execute The rule specifies that a chroma block to which a third prediction mode is applied is constrained to have a width of 4 or greater; The non-transitory computer-readable storage medium, wherein in the third prediction mode, an intra prediction signal and an inter prediction signal are combined by coefficients to generate a prediction signal.

10. 1. A method for generating and storing a video bitstream, comprising: determining, for a coding tree node of a video, a rule-based scheme for partitioning a luma parent block of the coding tree node and a chroma parent block of the coding tree node and predicting one or more luma blocks from the luma parent block and one or more chroma blocks from the chroma parent block; generating the bitstream based on the scheme; storing the bitstream on a non-transitory computer-readable recording medium; and The rule specifies that a chroma block to which a third prediction mode is applied is constrained to have a width of 4 or greater; A method wherein in the third prediction mode, an intra prediction signal and an inter prediction signal are combined by coefficients to generate a prediction signal.

Images