Video Region Partition Based on Color Format

Abstract

A method for video processing is provided, the method including the steps of determining a partitioning scheme for partitioning a chroma video region of the video into one or more chroma blocks according to a rule and based on a color format of the video, and performing a conversion between the video and an encoded representation of the video according to the partitioning scheme.

Description

[Technical field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] Books This application claims priority to and claims the benefit of International Patent Application No. PCT / CN2019 / 099447, filed on August 6, 2019. National phase entry of International Patent Application No. PCT / CN2020 / 107381 filed on August 6, 2020, claiming the benefit thereof is . above The All Out Wish , The full text of these By reference In the original 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 communications networks, and the bandwidth demands for digital video usage are expected to continue to increase as the number of connected user devices capable of receiving and displaying video increases. Summary of the Invention

[0004] The disclosed techniques may be used by 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 that includes determining a partitioning scheme for partitioning chroma video regions of a video into one or more chroma blocks according to a rule based on a color format of the video, 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 type for sub-blocks of coding tree nodes of the video, and performing, based on the determination, a conversion between the video and an encoded representation of the video, the coding tree nodes being partitioned into sub-blocks for coding in the encoded representation.

[0007] In another exemplary aspect, another method of video processing is disclosed, 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 an encoded 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 encoded 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, the intra block copy mode including encoding the chroma block using at least one block vector that points to a video frame including a video region.

[0008] In another exemplary 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 a weighting factor.

[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 an intra-coding mode according to a size rule, the size rule defining 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, and otherwise the intra-coding mode is from a second set of intra-coding mode types, where M and N are integers.

[0010] In another example 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 with 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 including: 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 that 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 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 that includes performing a conversion between a video block of a video and an encoded representation of the video block, the encoded representation conforming to a format rule that defines selective inclusion in the encoded representation of a syntax element indicating use of an Inter Block Copy (IBC) mode in accordance with a mode type of the video block, the IBC mode including encoding the video block with at least one block vector that points to a video frame that includes the video block.

[0013] In another example aspect, another method of video processing is disclosed that includes performing a conversion between a video block of a video and a coded representation of the video block, the coded representation following a format rule that specifies 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 a video region of a video to be used for conversion between the 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 example aspect, another method of video processing is disclosed, the method including: for converting between a video region of a video and a coded representation of the video, determining whether use of a palette mode is allowed for the video region based on rules, 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 other example aspects, 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 description of the drawings]

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

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

[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. In particular, it relates to palette coding, which uses representations based on primary colors in video coding. It may be applied to existing video coding standards such as HEVC, or standards to be finalized (Versatile Video Coding). It may also be applicable to future video coding standards or video codecs.

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

[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 FIG. 1, the current block is predicted by a reference block in the same picture when IBC is applied. The samples in the reference block have already been reconstructed before the current block is encoded or decoded. Although IBC is not very efficient for most of the sequences captured by a camera, it shows a significant coding improvement for screen content. The reason is that there are many repeating patterns, such as icons and text characters, in screen content pictures. IBC can effectively remove the redundancy among those repeating patterns. In HEVC-SCC, an inter-coded coding unit (CU) can apply IBC if it selects the current picture as its reference picture. MV is renamed as block vector (BV) in this case, and BV always has integer pixel precision. To be compatible with Main Profile HEVC, the current picture is marked as a "long-term" reference picture in the Decoded Picture Buffer (DPB). It should be noted that in the Multiview / 3D Video Coding standard, inter-view reference pictures are also marked as "long-term" reference pictures.

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

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

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

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

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

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

[0035] In the derivation of spatial merge candidates, up to four merge candidates are selected from the candidates located at the positions shown in FIG. 19. The order of derivation is A 1 , B 1 , B 0 , A 0 , and B 2 Position B 2 is position A 1 , B 1 , B 0 , A 0 Position A is considered only if any of the PUs in position A is not available (because it belongs to another slice or tile) or is not coded in IBC mode. 1After the candidate in 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. In order to reduce computational complexity, not all possible candidate pairs are considered in the above redundancy check. Instead, the pairs connected by arrows in Fig. 20 are considered, and a candidate is added to the list only if the corresponding candidate used for 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, then 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 following sequence of steps: Step 1: Derive spatial candidates A until an available candidate is found 0 , A 1 Check out B until an available candidate is found 0 , B1 , B 2 Check out 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 the palette mode is that samples in a CU are represented by a small set of representative color values. This set is called the palette. It is also possible to indicate samples that are outside the palette by signaling an escape symbol followed by a (possibly quantized) component value. Such samples are called escape samples. The palette mode is represented in Figure 2.

[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 to initialize the palette predictor is signaled in the bitstream. The palette predictor is initialized at the beginning of each CTU row, each slice, and each tile. Depending on the value of palette_predictor_initializer_present_flag, the palette predictor is either reset to 0 or initialized with the palette predictor initializer entry signaled in the PPC. In HEVC-SCC, a palette predictor initializer of size 0 is enabled to allow explicit disabling of palette predictor initialization at the PPS level.

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

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

[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 together the bypass bins associated with the index. Then, the palette sample mode (if required) and run are signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape sample values ​​for the entire CU are grouped together and coded in bypass mode.

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

[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 indexes is almost the same for all chroma formats. For non-monochrome formats, each palette entry consists of three components. For monochrome formats, each palette entry consists of a single component. For subsampled chroma directions, chroma samples are associated with luma sample indices that are divisible by two. After reconstructing the palette index of a CU, if a sample has only a single component associated with it, only the first component of the palette entry is used. The only difference in the signaling concerns the escape component values. For each escape sample, the number of escape component values ​​signaled may vary depending on the number of components associated with that sample.

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

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

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

[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, with the length of each side being a power of 2. Hence, no splitting operation is required to generate an intra predictor using DC mode. In VTM5, blocks may have rectangular shapes, which requires the use of a splitting operation for each block in the general case. To avoid the splitting operation for DC prediction, only the longer side is used to calculate the average of non-square blocks.

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

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

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

[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. · If both modes Left and Above are non-angle modes: ·MPM List → {Planar, DC, V, H, V-4, V+4} If one of the modes Left and Above is an angular mode and the other is a non-angular mode: Set mode Max as the larger of Left and Above modes · MPM List → {Planar, Max, DC, Max-1, Max+1, Max-2} · If Left and Above are both in angle mode and they are different: Set mode Max as the larger of Left and Above modes If the difference between the modes Left and Above is between 2 and 62: ·MPM List → {Planar, Left, Above, DC, Max-1, Max+1} If not: ·MPM List → {Planar, Left, Above, DC, Max-2, Max+2} ·If Left and Above are both in angle mode and they are the same: ·MPM List → {Planar, Left, Left-1, Left+1, DC, Left-2}

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

[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 residual after performing intra prediction horizontally (copying the left adjacent pixel value line by line across the predicted block) or vertically (copying the upper adjacent line onto each line in the predicted block) using unfiltered samples from the upper or left block boundary samples. i,j ), 0≦i≦M-1,0≦j≦N-1 is the residual r i,j where the residual is the difference between the original block values ​​and the predicted block values. Block DPCM is then applied to the quantized residual samples, resulting in the element (outside 1) Modified M x N array with TIFF0007670681000003.tif9127 (outside 2) You get TIFF0007670681000004.tif9127. 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) TIFF0007670681000007.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 are inverted to extract

number

number

[0072] The dequantized residual Q -1 (Q(r i,j ) is added to the intrablock 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 by simply adding a predictor as the coefficients are parsed, or it can be performed after the analysis.

[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 is applied to the luma component and a 5x5 diamond shape is applied to the chroma components.

[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 computation is applied. The same subsampled positions are used for gradient computation in all directions, as shown in Figure 9.

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

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

number

[0082] The maximum and minimum 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 t 1 and t 2 Compared to: [Table 3]

[0084] The activity value A is

number

[0085] A is further quantized to the range 0 to 4, inclusive, 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, the ALF filter parameters are signaled in an Adaptation Parameter Set (APS). Up to 25 pairs of luma filter coefficients and clipping values ​​can be signaled in one APS. To reduce bit overhead, filter coefficients of different classifications can be merged. The slice header signals the index of the APS used for the current slice.

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

number

[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 the 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 128. 7 2 more 7 Bitstream conformance is applied such that the center position coefficient should be in the range less than or equal to -1. The center position coefficient is not signaled in the bitstream and is assumed to be equal to 128.

[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 a sample value R'(i,j) as follows:

number

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

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

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

[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, if the sample being filtered is located below the virtual boundary, the adjacent samples located above the virtual boundary are padded, while the corresponding samples on the other side are also padded symmetrically.

[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) A sample adaptive offset (SAO) is applied to the reconstructed signal after the deblocking filter by using an offset specified for each CTB by the encoder. The HM encoder first determines whether the SAO process should be applied to the current slice. When SAO is applied to a slice, each CTB is classified as one of five SAO types, as shown in Table 2-6. The concept of SAO is to classify pixels into categories and reduce distortion by adding an offset to the pixels in each category. SAO operations include edge offset (EO), which uses edge characteristics for pixel classification in SAO types 1-4, and band offset (BO), which uses pixel intensity for pixel classification in SAO type 5. Each applicable CTB has SAO parameters, including sao_merge_left_flag, sao_merge_up_flag, SAO type, and four offsets. If sao_merge_left_flag is equal to 1, the current CTB reuses the SAO type and offset of the CTB to its left. When sao_merge_up_flag is equal to 1, the current CTB reuses the SAO type and offset of the CTB above. [Table 5]

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

[0101] FIG. 12 shows four example one-dimensional 3-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 in one CTB region into 32 uniform bands by using the 5 most significant bits of the pixel value as the band index. That is, the pixel intensity range is divided into 32 equal segments from zero to the maximum intensity value (e.g., 255 for 8-bit pixels). Four adjacent bands are grouped together, and each group is indicated by its left-most position as shown in Figure 13. The encoder searches all positions to obtain the group that reduces the distortion the most by compensating for the offset of each band.

[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 a combined inter / intra prediction (CIIP) mode is currently applied to the CU. As the name suggests, CIIP prediction combines an inter prediction signal with an intra prediction signal. The inter prediction signal P in CIIP mode inter is derived using the same inter prediction process as applied in the normal merge mode, resulting in an intra prediction signal P intra is derived according to the normal intra prediction process in planar mode. The intra prediction signal and the inter prediction signal are then combined using a weighted average, where the weight value is calculated according to the coding modes of the upper and left neighboring blocks (shown in FIG. 14 ) as follows: · If the upper neighboring block is available and is intra-coded, set isIntraTop to 1, otherwise set isIntraTop to 0. · If the left adjacent block is available and is intra-coded, set isIntraLeft to 1, otherwise set isIntraLeft to 0. If (isIntraLeft+isIntraTop) is equal to 2, then wt is set to 3. Otherwise, if (isIntraLeft+isIntraTop) is equal to 1, then wt is set to 2. In all other cases, set wt to 1.

[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 luma components based on an adaptive piecewise linear model, and 2) application of luma-dependent chroma residual scaling for chroma components. Figure 15 shows the LMCS architecture from the decoder start. The blocks in Figure 15 include inverse quantization, inverse transform, luma intra prediction, and adding luma prediction with 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, where these include loop filters such as deblocking, ALF, and SAO, motion compensated prediction, chroma intra prediction, adding chroma prediction with chroma residual, and storing the decoded picture as a reference picture as well. Figure 15 shows the new LMCS functional blocks, which include forward and backward mapping of the luma signal and 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 an implicit quadtree partitioning, which are the roots of two separate coding_tree syntax structures for luma and chroma.

[0111] Since the binary tree in intra picture allows 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 2×2, 4×2, and 2×4, which brings difficulties in practical decoder design. Furthermore, some prediction modes such as CCLM, planar, and angular modes require multiplication. To alleviate the above problems, small chroma block sizes (2×2 / 2×4 / 4×2) are restricted in the binary tree as partitioning restrictions.

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

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

[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 one further division, the type of the SCIPU is inferred to be non-inter (because inter 4x4 is not allowed in VVC). Otherwise, the type of the SCIPU (inter or non-inter) is indicated by a single flag before parsing the CUs in the SCIPU.

[0116] 2.14 Small Chroma Block Restrictions in VVC Draft 6 In VVC draft 6 (JVET-O2001-vE.docx), the constraints on small chroma blocks are implemented as follows (relevant parts are marked in bold italics): [Table 7] TIFF0007670681000024.tif204166TIFF0007670681000025.tif217166TIFF00076706810 00026.tif227166TIFF0007670681000027.tif230166TIFF0007670681000028.tif214161 TIFF0007670681000029.tif231154TIFF0007670681000030.tif211158TIFF00076706810 00031.tif230158TIFF0007670681000032.tif230155TIFF0007670681000033.tif185159

[0117] 3. Challenges (1) Currently, IBC is assumed to be in MODE_TYPE_INTRA, so small chroma blocks are not allowed, resulting in unnecessary coding efficiency loss. (2) Currently, the palette is assumed to be in MODE_TYPE_INTRA, so small chroma blocks are not allowed, resulting in unnecessary coding efficiency loss. (3) Currently, the small chroma block constraint does not take into account color subsampling formats. (4) Currently, the same partition and prediction mode constraints for small blocks are applied to all chroma formats. However, it may be desirable to design different constraint mechanisms for small blocks for 4:2:0 and 4:2:2 chroma formats. (5) Currently, palette mode flag notification depends on modeType, which is undesirable because the palette may not enforce small block constraints. (6) Currently, the IBC mode flag is inferred to be 0 for P / B slices when cu_skip_frag is equal to 1 but MODE_TYPE is equal to MODE_TYPE_INTRA, which is incorrect in syntax parsing. (7) Currently, non-4×4 luma IBC modes are not allowed for SCIPU luma blocks, which may be undesirable and may cause coding efficiency loss. (8) 2xH chroma blocks are still allowed, but this is not friendly to hardware implementations. (9) CIIP, while considered as MODE_INTER, uses intra prediction, which violates constraints in some cases.

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

[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, etc. For example, a block may be a QT node, or a BT node, or a TT node, etc. A coding tree node may be a coding unit (e.g., having three color components for one-tree, 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 smaller blocks may depend on the color format. In one example, for a 4:4:4 color format, constraints on the size of chroma blocks may follow such constraints on luma blocks. b. In one example, for a 4:2:2 color format, constraints on the size of chroma blocks may follow such constraints for the 4:2:0 color format. c. In one example, for 4:0:0 and / or 4:4:4 chroma formats, constraints on small block partitions and / or prediction modes may not apply. d. In one example, constraints on partitions of small blocks and / or prediction modes may be applied differently for different chroma formats. i. In one example, for an M×N (e.g., 8×8) coding tree node using horizontal BT partitioning, in a 4:2:2 chroma format, horizontal BT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, horizontal BT partitioning may be allowed for luma blocks but not for chroma blocks. ii. In one example, for an M×N (e.g., 16×4) coding tree node using vertical BT partitioning, in a 4:2:2 chroma format, vertical BT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, vertical BT may be allowed for luma blocks but not for chroma blocks. iii. In one example, for an M×N (e.g., 8×16) coding tree node using horizontal TT partitioning, in a 4:2:2 chroma format, horizontal TT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, horizontal TT partitioning may be allowed for luma blocks but not for chroma blocks. iv. In one example, for an M×N (e.g., 32×4) coding tree node using vertical TT partitioning, in a 4:2:2 chroma format, vertical TT partitioning may be allowed for both chroma and luma blocks, while in a 4:2:0 chroma format, vertical TT may be allowed for luma blocks but not for chroma blocks. v. In one example, for 4:0:0 and / or 4:4:4 color formats, the small block constraint may not apply. e. In one example, whether SCIPU should be enabled depends on the color format. i. In one example, SCIPU is enabled for 4:2:0 and 4:2:2 color formats. ii. In one example, SCIPU is disabled for 4:0:0 and / or 4:4:4 color formats.

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

[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 MODE_TYPE_INTRA (block can select palette, intra or intra block copy) or as 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, chroma 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, chroma intra (and / or IBC) blocks of 2×N (eg, N<=64) may not be allowed in a unitree. i. In one example, for an M×N (eg, M=8 and N<=64) coding tree node using vertical BT partitioning, one of the following processes may be applied. 1. Vertical BT splitting is not allowed for 4×N or 4×(N / 2) chroma blocks, but may be allowed for 8×N luma blocks. The 2.4×N or 4×(N / 2) chroma block may not be vertical BT split, and it may be coded by MODE_INTRA or MODE_IBC. 3. Vertical BT splitting may be allowed for both 8xN luma blocks and 4xN or 4x(N / 2) chroma blocks, but both luma and chroma blocks may not be coded by MODE_INTRA (e.g., they may be coded by MODE_INTER or MODE_IBC). ii. In one example, for an M×N (eg, M=16 and N<=64) coding tree node using vertical TT partitioning, one of the following processes may be applied. 1. Vertical BT splitting is not allowed for 8×N or 8×(N / 2) chroma blocks, but may be allowed for 16×N luma blocks. 2. The 8×N or 8×(N / 2) chroma block may not be vertical TT split, it may be coded by MODE_INTRA or MODE_IBC. 3. Vertical TT splitting may be allowed for both 16xN luma blocks and 8xN or 8x(N / 2) chroma blocks, but both luma and chroma blocks may not be coded by MODE_INTRA (e.g., they may be coded by MODE_INTER or MODE_IBC).

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

[0127] 5. Signaling of IBC prediction mode flags may depend on the prediction mode type (eg, MODE_TYPE_INTRA). a. In one example, the IBC prediction mode 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). In one example, if the current block is coded in SKIP mode (eg, cu_skip_flag is equal to 1) and modeType is equal to MODE_TYPE_INTRA, then the IBC prediction mode flag (eg, pred_mode_ibc_flag) may be inferred to be equal to 1.

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

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

[0131] 9. Palette mode may be allowed to be used if modeType is MODE_TYPE_INTER. In one example, chroma palettes may not be allowed when modeType is MODE_TYPE_INTRA. b. In one example, 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, palette and inter modes may both be allowed. e. In one example, within one SCIPU, Palette, IBC and Inter modes 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, then 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. In one example, only a subset of the intra prediction modes among the available chrominance intra prediction modes may be used. b. In one example, only the INTRA_DC mode may be used. c. In one example, only the INTRA_PLANAR mode may be used. d. In one example, only the INTRA_ANGULAR18 mode may be used. e. In one example, only the INTRA_ANGULAR50 mode may be used. f. In one example, CCLM mode may not be allowed.

[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 a one-dimensional transform may be used. c. In one example, a coding tool that supports multiple types of transformations is not permitted. i. Alternatively, notification of coding tools that support multiple types of transformations is omitted.

[0134] 12.CIIP may be considered as MODE_TYPE_INTRA. In one example, CIIP mode may be allowed 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), then CIIP mode may not be allowed. ii. In one example, when the chroma block width is equal to M (eg, M=2), the subset of intra prediction modes for chroma in CIIP may be restricted to simple intra prediction modes. 1. In one example, INTRA_DC may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). 2. In one example, INTRA_ANGULAR18 may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). 3. In one example, INTRA_ANGULAR50 may be used for chroma intra prediction when the chroma block width is equal to M (eg, M=2). iii. In one example, intra prediction modes for chroma in CIIP may be restricted to simple intra prediction modes. 1. In one example, INTRA_DC may be used for chroma intra prediction. 2. In one example, the INTRA_ANGULAR18 mode may be used for chroma intra prediction. 3. In one example, the INTRA_ANGULAR50 mode may be used for chroma intra prediction.

[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 of small blocks and prediction modes only applying to 4:2:0 and 4:4:4 chroma formats (not to 4:0:0 and 4;4;4 chroma formats). [Table 9]

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

[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 the 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 it is a small block size 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 a 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 may be used to implement some of the techniques described herein in a hardware circuit. In some embodiments, the video processing hardware 1706 may be included at least partially or completely within the processor 1702 (e.g., a graphics coprocessor).

[0146] FIG. 17B is another example of a 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 for receiving video content. The video content may be received in a raw or uncompressed format, e.g., 8 or 10-bit multi-component pixel values, or may be 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 (PON), and the like, and wireless interfaces such as Wi-Fi or cellular networks.

[0147] The system 1710 may include a coding component 1714 that may implement various coding or encoding methods described herein. The coding component 1714 may reduce the average bit rate of the video from the input 1712 to an output of the coding component 1714 to generate a coded representation of the video. The coding techniques are therefore sometimes referred to as video compression or video transcoding techniques. The output of the 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 the input 1712 may be used by component 1718 to generate pixel values ​​or displayable video that is sent to a display interface 1720. The process of generating a video that a user can view from the bitstream representation is sometimes referred to as video decompression. Furthermore, it will be understood that while certain video processing operations are referred to as "coding" operations or tools, such coding tools or operations are used in an encoder and corresponding decoding tools or operations that transpose the results of the coding will 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 flow chart of a method 1800 for processing video. The method 1800 includes a step of parsing (1802) the encoded representation according to syntax rules that define a relationship between a color format and a chroma block size of the video region for conversion between a video region of a video and an encoded representation of the video region, and a step of performing the conversion by performing the parsing according to the syntax rules (1804).

[0150] 21A is a flow chart of a method 2110 for processing video. The method 2110 includes 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 a rule, at step 2112. The method 2110 further includes performing a conversion between the video and a coded representation of the video according to the partitioning scheme, at step 2114.

[0151] 21B is a flow chart of a method 2120 for processing video. The method 2120 includes, at step 2122, determining a prediction mode or 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 an encoded representation of the video based on the determination. In some implementations, the coding tree node is partitioned into sub-blocks for coding in the encoded representation.

[0152] 22A is a flow chart of a method 2210 for processing a 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 an 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 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 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 block is equal to M or the height of the chroma block 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 with a transformation type according to a rule, the rule defining 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 having one or more luma blocks and one or more chroma blocks and a coded representation of the video according to rules that dictate that for all values ​​of M and N, use of an 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 using the IBC mode, a video block is coded using at least one block vector that points to a video frame that contains 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, where the encoded representation follows a format rule, and the format rule defines the selective inclusion of a syntax element indicating use of an Inter Block Copy (IBC) mode in the encoded representation based on a mode type of the video block, and the IBC mode includes 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, where the encoded representation follows a format rule, where the format rule specifies that a syntax element indicating use of a palette mode is included in the encoded representation regardless of the mode type of the video block, where the palette mode includes encoding the video block using a palette of representative sample values.

[0158] 22B is a flow chart of a method 2220 for processing video. The method 2220 includes, at step 2222, determining to use a composite 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 2310 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 flow chart 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 based on the rules for converting between a video region of the video and a coded representation of the video. 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 flow chart of a method 2320 of processing video. The method 2320 includes, at step 2322, determining whether use of a palette mode is allowed for the video region for conversion between the video region and a coded representation of the video based on the rules. The method 2320 further includes performing the conversion based on the determination, at step 2324. 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 of blocks of video to a bitstream representation of video is performed using the video processing tool or mode when it is enabled based on the decision or determination. In another example, when a video processing tool or mode is enabled, a decoder processes the bitstream with the knowledge that the bitstream has been modified based on the video processing tool or mode. That is, conversion of the bitstream representation of video to blocks of video is performed using the video processing tool or mode that was enabled based on the decision or determination.

[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 not altered.

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

[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 that define 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 performing parsing according to said syntax rules; The method according to claim 1,

[0166] 2. The method according to clause 1, the color format is 4:4:4, The syntax rules stipulate that chroma blocks are subject to 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. A method according to any one of clauses 1 to 3, comprising: The syntax rules stipulate 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 bullets 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 for a coding tree node of the video based on characteristics of the video and a chroma format of the video; performing a conversion between the encoded representation of the video and the video blocks of the coding tree nodes using the determined coding mode; The method according to claim 1,

[0172] 7. The method according to claim 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 M×N coding tree node using a horizontal ternary tree partition; or iv. The coding tree node is an M×N coding tree node using vertical ternary tree division. If the chroma format is 4:2:2, the coding mode is determined to be MODE_TYPE_ALL, and 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 claim 7, M=8, or 16, or 32; N=4, or 8, or 16; method.

[0174] The following bullets 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 a chroma block is allowed in a video area of ​​the video; performing a conversion between the video domain and a coded representation of the video domain based on the determination; The method according to claim 1,

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

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

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

[0179] The following bullets 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 determining; The method according to claim 1,

[0181] 14. The method according to claim 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 claim 14, The small block sizes include luma block sizes of 8×8, 8×8, 16×4, or 4×N. method.

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

[0184] 17. The method according to claim 13, the rules permit the use of a palette coding mode for the transformation of the video region using a 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 the steps of: converting between a video block of a video and a coded representation of the video block using a video coding mode; a syntax element indicating the coding mode is selectively included in the encoded representation based on the rule; method.

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

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

[0189] 21. The method according to claim 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 claim 18, the video coding mode is a palette coding mode, The rules provide for selectively including a palette coding indicator based on a mode type of the video block. method.

[0191] The following bullets 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 the steps of: determining that a chroma block has a size less than a threshold size such that a transform type used during conversion between the chroma block and a coded representation of the chroma block is different from a transform type used for a corresponding luma block conversion; performing said conversion based on said determination; The method according to claim 1,

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

[0194] The following bullets 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 conversion uses an inter-intra composite 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 an inter-intra composite prediction mode, MODE_TYPE_INTER. method.

[0197] For example, when CIIP is considered as MODE_TYPE_INTER, the method described in item 5+6+7 in the previous section may be applied, or when the method described in item 5+6+7 is applied, CIIP may be considered as MODE_TYPE_INTER.

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

[0199] 28. A method according to any one of clauses 1 to 26, comprising: the converting comprises decoding the encoded 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, comprising: 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 section, 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 according to a rule and based on a color format of the video; performing a conversion between said video and a coded representation of said video in accordance with said partitioning scheme; The method according to claim 1,

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

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

[0208] 4. The method according to claim 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 claim 1 or 2, the rules provide 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 claim 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 claim 6, For an M×N coding tree node with a horizontal BT (binary tree) partition or an estimated TT (ternary tree) partition, in a 4:2:2 color format, the horizontal BT partition or the horizontal TT partition is allowed for both chroma and luma blocks; method.

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

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

[0214] 10. The method according to claim 6, For an M×N coding tree node with a vertical BT (binary tree) or TT (ternary tree) partition, in a 4:2:0 color format, the vertical BT or 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 claim 11, M and / or N depend on the color format of the video region. method.

[0217] 13. The method according to claim 6, the rules provide that the partitioning scheme does not apply to 4:0:0 color format and / or 4:4:4 color format; method.

[0218] 14. The method according to claim 1, The rule specifies that a smallest chroma intra prediction unit (SCIPU) defined to limit a 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 claim 14, the smallest chroma intra prediction unit is allowed for 4:2:0 color format and / or 4:2:2 color format; method.

[0220] 16. The method according to claim 14, the minimum chroma 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 an encoded representation of the video based on the determination; having the coding tree nodes are partitioned into sub-blocks for coding in the encoded representation. method.

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

[0223] 19. The method according to claim 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 claim 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 8×8 luma blocks with horizontal binary tree partitioning; ii) the coding tree nodes correspond to 16×4 luma blocks with vertical binary tree partitioning; iii) the coding tree nodes correspond to 8×16 luma blocks with a horizontal ternary tree partition; or iv) the coding tree nodes correspond to 32×4 luma blocks with vertical ternary tree partitioning; satisfy one of the following: method.

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

[0227] 23. The method according to claim 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 encoded 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 encoded representation; method.

[0230] 26. A video processing device having a processor configured to implement a 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 rules define 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 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 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 a vertical BT (binary tree) split 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 4 chroma samples. method.

[0236] 4. The method according to clause 2, The rule specifies that a vertical ternary tree (TT) split 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 a unitree partition. method.

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

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

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

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

[0242] 10. The method according to claim 5, For an M×N coding tree node with a vertical TT (ternary tree) partition, the vertical TT partition is not allowed for chroma blocks having a size of 8×N or 8×(N / 2); method.

[0243] 11. The method according to claim 5, For an M×N coding tree node with a vertical TT (ternary tree) partition, the vertical TT partition is allowed for chroma blocks having a size of 8×N or 8×(N / 2) and luma blocks having a size of 16×N, 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 said conversion based on said determination; having The CIIP mode includes combining the intra prediction signal and the inter prediction signal using a weighting factor; method.

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

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

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

[0248] 16. The method according to claim 12, The rule specifies that an intra prediction mode for a chroma block coded in the CIIP mode is restricted to the intra mode. method.

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

[0250] 18. The method according to claim 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 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 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. method.

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

[0253] 21. The method according to claim 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 claim 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 of chroma components from other components are disabled. method.

[0259] 27. A method of video processing comprising the steps of: 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 claim 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, comprising: M and / or N are predefined or signaled; method.

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

[0263] 31. The method according to any one of clauses 1 to 30, said converting including encoding said video into said encoded representation; method.

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

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

[0266] 34. 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 32.

[0267] The fourth set of bullets describes certain features and aspects of the techniques disclosed in the previous section, eg, 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 said video according to rules; The rule specifies that use of an 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 dictate that luma blocks have a size of 8×4, 8×8, 16×4, or 4×N. method.

[0270] 3. The method according to clause 2, the luma block has a mode type equal to MODE_TYPE_INTRA, indicating 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 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 with at least one block vector that points to a video frame that includes the video block. method.

[0273] 6. The method according to claim 5, the format rule specifies that the syntax element is explicitly signaled 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 claim 5, the format rule specifies inferring the syntax element based on a mode type and a skip flag of the video block. method.

[0275] 8. The method according to claim 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 that specifies that a syntax element indicating use of a palette mode is 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 claim 9, the format rules define an 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 claim 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 Inter Block 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 said conversion based on said determination; having the IBC mode includes encoding the video region using at least one block vector that points to a video frame that contains the video region; method.

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

[0281] 14. The method according to claim 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, then the IBC mode is not allowed for a chroma block. method.

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

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

[0284] 17. The method according to claim 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 claim 12, a chroma block coded using the IBC mode has a size corresponding to a size of its corresponding luma block; method.

[0286] 19. The method according to claim 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 applicability of inter-coding modes only, and the video region corresponds to 4x4 luma blocks. method.

[0287] 20. A method of video processing comprising the steps of: for converting between a video domain 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 domain; performing said conversion based on said determination; having the rules are based on a coding mode type of the video region or a color type of the region of video; the palette mode includes encoding the video region using a palette of representative sample values; method.

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

[0289] 22. The method according to claim 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 contains the video region; method.

[0290] 23. The method according to claim 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 an inter-coding mode, or MODE_TYPE_INTRA, which indicates applicability of an intra mode, an IBC mode, and a palette mode; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that contains the video region; method.

[0291] 24. The method according to claim 20, the rules stipulate that the palette mode is permitted regardless of the mode type of the video region; method.

[0292] 25. The method according to claim 20, The palette and inter modes 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 claim 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 contains the video region; method.

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

[0295] 28. The method according to claim 20, Notification of a syntax element indicating the use of said 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 applicability of inter-coding modes only, and the video region corresponds to 4x4 luma blocks. method.

[0296] 29. The method according to claim 20, a syntax element indicating 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 applicability of only inter-coding mode, and 2) the video region corresponds to a 4x4 luma block; the IBC mode includes encoding the video region using at least one block vector that points to a video frame that contains 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 claim 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 encoded 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 encoded representation; method.

[0301] 34. A video processing device having a processor configured to implement the methods 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 a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by or controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or one or more combinations thereof. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. An apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, such as code constituting a processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof. A propagated signal is an artificially generated signal, for example a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to an appropriate receiver device.

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

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

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

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

[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 the steps of: determining a 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; having a first scheme is applied to the coding tree node for a first color format; a second scheme different from the first scheme is applied to the coding tree node for a second color format different from the first color format if the coding tree node satisfies a predetermined condition regarding a size of the luma parent block; In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:0 color format, and has a luma parent block of a predetermined size M×N, the luma parent block is allowed to be divided into two or more luma blocks by a horizontal BT (binary tree) partition or a vertical BT partition, and a chroma parent block of the coding tree node is not allowed to be split by the horizontal BT partition or the vertical BT partition; the mode type of the two or more luma blocks is set to MODE_TYPE_INTRA or MODE_TYPE_INTER; A method wherein M and N are positive integers.

2. the first color format is a 4:0:0 color format or a 4:4:4 color format; the second color format is a 4:2:0 color format or a 4:2:2 color format; The method of claim 1.

3. the first scheme and the second scheme have different constraints on mode types of the one or more luma blocks and the one or more chroma blocks. The method of claim 1.

4. In the first scheme, a mode type of the one or more luma blocks and the one or more chroma blocks is MODE_TYPE_ALL; In the second scheme, the mode type of the one or more luma blocks and the one or more chroma blocks is MODE_TYPE_INTRA or MODE_TYPE_INTER. The method of claim 1.

5. In the first scheme, the same partitioning scheme is used to partition the chroma parent block and the luma parent block; In the second scheme, if the mode type of the chroma parent block is MODE_TYPE_INTRA, a different partitioning scheme is used to partition the chroma parent block and the luma parent block. The method of claim 1.

6. In the second scheme, the chroma parent block is not allowed to be partitioned and the tree type of the chroma parent block is set to DUAL_TREE_CHROMA. The method according to claim 5.

7. In the second scheme, when the mode type of the chroma parent block is MODE_TYPE_INTRA, the constraint on the size of the chroma parent block is the same for 4:2:0 color format and 4:2:2 color format; The constraints include that the width and height of the chroma parent block are both greater than or equal to 4. The method of claim 1.

8. the predetermined condition further relates to a partition type of the luma parent block. The method of claim 1.

9. In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:2 color format, and has a luma parent block of a predetermined size M×N, both the luma parent block and the chroma parent block of the coding tree node are allowed to be divided into two or more luma blocks and two or more chroma blocks by a horizontal BT partition or a vertical BT partition; the mode type of the two or more luma blocks and the two or more chroma blocks is set to MODE_TYPE_ALL; The method of claim 1.

10. M×N=64. The method according to claim 1 or claim 9.

11. In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:0 color format, and whose luma parent block is of a predetermined size P×Q, the luma parent block is allowed to be divided into two or more luma blocks by a horizontal TT (ternary tree) partition or a vertical TT partition, and a chroma parent block of the coding tree node is not allowed to be split by the horizontal TT partition or the vertical TT partition; the mode type of the two or more luma blocks and the chroma parent block is set to MODE_TYPE_INTRA or MODE_TYPE_INTER; P and Q are positive integers; The method of claim 1.

12. In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:2 color format, and whose luma parent block is of a predetermined size P×Q, both the luma parent block and the chroma parent block of the coding tree node are allowed to be divided into two or more luma blocks and two or more chroma blocks by a horizontal TT partition or a vertical TT partition; the mode type of the two or more luma blocks and the two or more chroma blocks is set to MODE_TYPE_ALL; P and Q are positive integers; The method of claim 1.

13. P×Q=128.

13. The method according to claim 11 or claim 12.

14. said converting including encoding said video into said bitstream; 14. The method according to any one of claims 1 to 13.

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

14. The method according to any one of claims 1 to 13.

16. 1. An apparatus for processing video data, comprising: a processor and a non-transient memory having instructions; The instructions, when executed by the processor, cause the processor to: determining a scheme for converting between a coding tree node of a video and a bitstream of the video, dividing a luma parent block of the coding tree node into one or more luma blocks by one or more partitions and dividing a chroma parent block of the coding tree node into one or more chroma blocks by one or more partitions, and predicting the one or more luma blocks and the one or more chroma blocks; performing said transformation according to said scheme; Run the command, a first scheme is applied to the coding tree node for a first color format; a second scheme different from the first scheme is applied to the coding tree node for a second color format different from the first color format if the coding tree node satisfies a predetermined condition regarding a size of the luma parent block; In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:0 color format, and has a luma parent block of a predetermined size M×N, the luma parent block is allowed to be divided into two or more luma blocks by a horizontal BT (binary tree) partition or a vertical BT partition, and a chroma parent block of the coding tree node is not allowed to be split by the horizontal BT partition or the vertical BT partition; the mode type of the two or more luma blocks is set to MODE_TYPE_INTRA or MODE_TYPE_INTER; An apparatus, wherein M and N are positive integers.

17. The processor: determining a scheme for converting between a coding tree node of a video and a bitstream of the video, dividing a luma parent block of the coding tree node into one or more luma blocks by one or more partitions and dividing a chroma parent block of the coding tree node into one or more chroma blocks by one or more partitions, and predicting the one or more luma blocks and the one or more chroma blocks; performing said transformation according to said scheme; storing an instruction to execute the a first scheme is applied to the coding tree node for a first color format; a second scheme different from the first scheme is applied to the coding tree node for a second color format different from the first color format if the coding tree node satisfies a predetermined condition regarding a size of the luma parent block; In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:0 color format, and has a luma parent block of a predetermined size M×N, the luma parent block is allowed to be divided into two or more luma blocks by a horizontal BT (binary tree) partition or a vertical BT partition, and a chroma parent block of the coding tree node is not allowed to be split by the horizontal BT partition or the vertical BT partition; the mode type of the two or more luma blocks is set to MODE_TYPE_INTRA or MODE_TYPE_INTER; A non-transitory computer-readable storage medium, wherein M and N are positive integers.

18. 1. A method for storing a video bitstream, comprising: determining, for a coding tree node of a video, partitioning a luma parent block of the coding tree node into one or more luma blocks by one or more partitions and partitioning a chroma parent block of the coding tree node into one or more chroma blocks by one or more partitions, and a scheme for predicting the one or more luma blocks and the one or more chroma blocks; generating said bitstream according to said scheme; storing the bitstream on a non-transitory computer-readable recording medium; having a first scheme is applied to the coding tree node for a first color format; a second scheme different from the first scheme is applied to the coding tree node for a second color format different from the first color format if the coding tree node satisfies a predetermined condition regarding a size of the luma parent block; In the second scheme, for a coding tree node whose slice type is an I slice, has a 4:2:0 color format, and has a luma parent block of a predetermined size M×N, the luma parent block is allowed to be divided into two or more luma blocks by a horizontal BT (binary tree) partition or a vertical BT partition, and a chroma parent block of the coding tree node is not allowed to be split by the horizontal BT partition or the vertical BT partition; the mode type of the two or more luma blocks is set to MODE_TYPE_INTRA or MODE_TYPE_INTER; A method wherein M and N are positive integers.

Images