Block size dependent usage of video coding modes

Abstract

To provide a method, system, and apparatuses for encoding or decoding video in which a picture partition mode is based on a block size.SOLUTION: An example method for video processing uses dimensions of a virtual pipeline data unit (VPDU) used to convert between video having one or more video regions with one or more video blocks and a bitstream representation of the video to: perform determination of whether a Ternary Tree (TT) or Binary Tree (BT) partitioning of a video block of the one or more video blocks is enabled; and perform the conversion on the basis of the determination, in which the dimension is equal to VSize in luma samples and the dimension of the video block is CtbSizeY in luma samples, where VSize=min (M,CtbSizeY) and M is a positive integer.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] This application is a divisional application of International Patent Application No. PCT / CN2020 / 104786 filed on July 27, 2020, which claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 097926 filed on July 26, 2019, and International Patent Application No. PCT / CN2019 / 103892 filed on August 31, 2019. All of the above patent applications are incorporated herein by reference in their entirety.

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

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

[0004] The disclosed techniques may be used by embodiments of a video or image decoder or encoder to perform video encoding or decoding in which the picture partition mode is determined based on block size.

[0005] In one example embodiment, a method of video processing is disclosed, comprising: performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of one or more video blocks is enabled using dimensions of a virtual pipeline data unit (VPDU) used to convert between a video having one or more video regions with one or more video blocks and a bitstream representation of the video, the dimensions being equal to VSize in luma samples and the dimensions of the video blocks being CtbSizeY in luma samples, where VSize=min(M,CtbSizeY), where M is a positive integer; and performing the conversion based on the determination.

[0006] In another example embodiment, a method of video processing is disclosed that includes performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of one or more video regions having one or more video blocks is enabled for conversion between a bitstream representation of the video and the one or more video regions having the one or more video blocks, using a dimension of the one or more video blocks, and performing the conversion based on the determination.

[0007] In yet another example embodiment, a method of video processing is disclosed that includes using a height or width of a video block to perform a determination of whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks that include the video block and a bitstream representation of the video, and performing the conversion based on the determination, where the determination is based on a comparison between the height or width and a value N, where N is a positive integer.

[0008] In yet another example embodiment, a method of video processing is disclosed that includes using a comparison between a height or width of a video block and a size of a transform block to determine whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks with the video block and a bitstream representation of the video, and performing the conversion based on the determination.

[0009] In yet another example embodiment, a method of video processing is disclosed that includes using a height or width of a video block to determine whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks that include the video block and a bitstream representation of the video, and performing the conversion based on the determination.

[0010] In yet another example aspect, a method of video processing is disclosed that includes using a comparison between dimensions of sub-partitions of a video block and a maximum transform size to (a) determine whether an intra sub-partition prediction (ISP) mode is enabled for transforming between a video having one or more video regions with one or more video blocks with the video block, and (b) select one or more allowed partition types for the transform, and perform the transform based on the determination and the selection, where in the ISP mode, a video block of the one or more video blocks is divided into a plurality of sub-partitions before application of intra prediction and transform.

[0011] In yet another example embodiment, a method of video processing is disclosed that includes performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a disabled coding tool, wherein a syntax element related to the coding tool is excluded from the bitstream representation and is assumed to be a predefined value that specifies the coding tool is disabled.

[0012] In yet another example embodiment, a method of video processing is disclosed that includes performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a coding tool that is disabled, the bitstream representation having a syntax element related to the coding tool that is estimated to be a predetermined value based on the coding tool being disabled.

[0013] In yet another example aspect, a method of video processing is disclosed that includes performing a determination of whether implicit (QT) splitting of video blocks of one or more video blocks is enabled using dimensions of a virtual pipeline data unit (VPDU) and / or a maximum transform size used to convert between a video having one or more video regions with one or more video blocks and a bitstream representation of the video, and performing the conversion based on the determination.

[0014] In yet another example aspect, a method of video processing is disclosed that includes performing a transformation between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the transformation comprising a sub-block transform (SBT), a maximum height or width of the SBT based on a maximum transform size, the SBT comprising one or more transforms applied separately to one or more partitions of video blocks of the one or more video blocks.

[0015] In yet another example aspect, a method of video processing is disclosed that includes performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a transform skip mode and / or an intra block-based differential pulse code modulation (BDPCM) mode, a maximum block size used for the transform skip mode based on a maximum transform size, the transform skip mode including skipping transform and inverse transform processes for a corresponding coding tool, and in the BDPCM mode, a residual of an intra prediction of the current video block is predictively coded using a differential pulse code modulation process.

[0016] In yet another example embodiment, a method of video processing is disclosed that includes using a comparison between a height or width of a video block and a maximum transform size to determine whether a combined inter-intra prediction (CIIP) mode is enabled for transforming between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, and performing the transform based on the determination, where in the CIIP mode, a final prediction of the video block is based on a weighted sum of an inter prediction of the video block and an intra prediction of the video block.

[0017] In yet another example embodiment, a method of video processing is disclosed that includes making a decision regarding partitioning a video block of one or more video blocks coded with joint inter-intra prediction (CIIP) for conversion between a video having one or more video regions with one or more video blocks and a bitstream representation of the video, and performing the conversion based on the decision, where in the CIIP mode, a final prediction of the video block is based on a weighted sum of an inter prediction of the video block and an intra prediction of the video block.

[0018] In yet another example aspect, a method of video processing is disclosed that includes performing a conversion between a video having a video region having a plurality of video blocks and a bitstream representation of the video according to rules that specify that a maximum block size of the video blocks in the video region that are encoded into the bitstream representation using transform coding determines a maximum block size of the video blocks in the video region that are encoded into the bitstream representation without transform coding.

[0019] In yet another example aspect, a method of video processing is disclosed, comprising: performing a conversion between a video having a video region having a plurality of video blocks and a bitstream representation of the video according to rules, the rules specifying that a luma mapping with chroma scaling (LMCS) process is disabled for the video region when lossless coding is enabled for the video region, the video region being a sequence, a picture, a subpicture, a slice, a tile group, a tile, a brick, a coding tree unit (CTU) row, a CTU, a coding unit (CU), a prediction unit (PU), a transform unit (TU), or a subblock, the LMCS process comprising reshaping luma samples of the video region between a first domain and a second domain, and scaling chroma residual in a luma-dependent manner.

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

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

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

[0023] [Figure 1] 1 shows examples of binary tree (BT) and ternary tree (TT) splitting according to video block size. [Diagram 2] FIG. 1 is a block diagram of an example hardware platform that may be used to implement the techniques described herein. [Diagram 3] FIG. 1 is a block diagram of an example of a video processing system in which the disclosed technology may be implemented. [Figure 4] 1 is a flow chart of an example method of video processing. [Diagram 5] 11 is a flowchart of another example of a video processing method. [Figure 6] 13 is a flowchart of yet another example of a video processing method. [Figure 7] 13 is a flowchart of yet another example of a video processing method. [Figure 8] 13 is a flowchart of yet another example of a video processing method. [Figure 9] 13 is a flowchart of yet another example of a video processing method. [Figure 10] 13 is a flowchart of yet another example of a video processing method. [Figure 11] 13 is a flowchart of yet another example of a video processing method. [Figure 12] 13 is a flowchart of yet another example of a video processing method. [Figure 13] 13 is a flowchart of yet another example of a video processing method. [Figure 14] 13 is a flowchart of yet another example of a video processing method. [Figure 15] 11 is a flowchart of yet another example of a video processing method. [Figure 16] 13 is a flowchart of yet another example of a video processing method. [Figure 17] 11 is a flowchart of yet another example of a video processing method. [Figure 18] 11 is a flowchart of yet another example of a video processing method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0026] 1. Overview This document relates to video coding technologies. Specifically, it relates to rules for controlling the size of coding tree units or transform units in video encoding and decoding. It may apply to existing video coding standards such as HEVC, or to emerging standards (Versatile Video Coding). It may also be applicable to future video coding standards or video codecs.

[0027] 2. Opening remarks Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, ISO / IEC created MPEG-1 and MPEG-4 Visual, and these two organizations jointly created the H.262 / MPEG-2 Video, H.264 / MPEG-4 AVC (Advanced Video Coding), and H.265 / HEVC standards. Since H.262, video coding standards have been based on a hybrid video coding structure where transform coding is used in addition to temporal prediction. In order to explore future video coding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, many new methods have been adopted by JVET and put into reference software named the Joint Exploration Model (JEM). JVET meetings are held simultaneously quarterly, and the new coding standard aims for a 50% bitrate reduction compared to HEVC. The new video coding standard was officially named Versatile Video Coding (VVC) at the April 2018 JVET meeting, when the first version of the VVC Test Model (VTM) was released. As ongoing efforts are made to contribute to VVC standardization, new coding techniques are adopted into the VVC standard at each JVET meeting. And after each meeting, the VVC Working Draft and Test Model VTM are updated. The VVC project is currently aiming for technical finalization (FDIS) at the July 2020 meeting.

[0028] 2.1 CTU size in VVC The VTM-5.0 software allows four different CTU sizes: 16x16, 32x32, 64x64, and 128x128. However, at the July 2019 JVET meeting, with the adoption of JVET-O0526, the minimum CTU size was changed to 32x32. The CTU size in VVC Working Draft 6 is then encoded in the SPS header in a UE-encoded syntax element called log2_ctu_size_minus_5.

[0029] The following is the definition of Virtual Pipeline Data Units (VPDU) and the changes in the VVC draft 6 specification due to the adoption of JVET-O0526: (outside 1) TIFF0007640646000001.tif233170TIFF0007640646000002.tif237170TIFF0007640646000003.tif242170TIFF0007640646000004.tif77170

[0030] 2.2 Maximum conversion size in VVC In VVC draft 5, the maximum transform size is signaled in the SPS, but is fixed at a length of 64 and is not configurable. However, at the July 2019 JVET meeting, it was decided to allow the maximum luma transform size to be either 64 or 32, using only an SPS-level flag. The maximum chroma transform size is derived from the chroma sampling ratio relative to the maximum luma transform size.

[0031] The following are the corresponding specification changes in VVC draft 6 due to the adoption of JVET-O05xxx: (outside 2) TIFF0007640646000005.tif176170

[0032] 3. Examples of technical problems addressed by the disclosed technical solutions The latest VVC working draft JVET-O2001-v11 has some problems, which are explained below. 1) In the current VVC draft 6, the maximum transform size and CTU size are specified independently; for example, the CTU size can be 32, while the transform size can be 64. Preferably, the maximum transform size should be equal to or smaller than the CTU size. 2) In the current VVC draft 6, the block partition process depends on the maximum transform block size other than the VPDU size. Therefore, if the maximum transform block size is 32x32, it prohibits 128x128 TT split, 64x128 vertical BT split, and 128x64 horizontal BT split according to the VPDU rule, and further prohibits TT split for 64x64 block, prohibits vertical BT split for 32x64 / 16x64 / 8x64 coding block, and prohibits horizontal BT split for 64x8 / 64x16 / 64x32 coding block, which may not be efficient for coding efficiency. 3) The current VVC draft 6 allows CTU sizes equal to 32, 64, and 128. However, it is possible for CTU sizes to be greater than 128. Therefore, some syntax elements need to be modified: a) If larger CTU sizes are allowed, the block partition structure and the signaling of block split flags can be redesigned; b) If larger CTU sizes are allowed, some of the current designs (e.g., affine parameter derivation, IBC prediction, IBC buffer size, merging triangular prediction, CIIP, normal merging mode, etc.) may be redesigned. 4) In the current VVC draft 6, the CTU size is signaled at the SPS level. However, the adoption of reference picture resampling (also known as adaptive resolution change) allows pictures to be coded at different resolutions within one bitstream, so the CTU size may vary across layers. 5) In WD6, the maximum block size used for MIP and ISP depends on the VPDU size or the maximum transform size other than 64x64, which may not be efficient for coding efficiency. 6) In WD6, the maximum block size used for transform skip and intra-BDPCM depends on the maximum transform skip size, which is limited by the maximum transform size. 7) In WD6, the maximum block size used for SBT depends on the maximum SBT size, which is limited by the maximum transform size. 8) In WD6, the size of the coding blocks used for IBC and PLT is limited to 64x64, which may be adjusted by the maximum transform size, CTU size, and / or VPDU size. 9) In WD6, the size of the coding block used for CIIP can be larger than the maximum transform size. 10) In WD6, the LMCS enable flag is not conditioned by the transform quantization bypass flag.

[0033] 4. Examples of embodiments and techniques The following list of solutions should be regarded as examples to illustrate some concepts. These items should not be construed narrowly. Moreover, these items can be combined in any way.

[0034] In this document, C=min(a,b) denotes that C is equal to the smallest value between a and b.

[0035] In this document, a video unit size / dimension can be either the height or width of a video unit (e.g., the width or height of a picture / subpicture / slice / brick / tile / CTU / CU / CB / TU / TB). When a video unit size is expressed by MxN, M represents the width of the video unit and N represents the height of the video unit.

[0036] In this document, a "coding block" may be a luma coding block and / or a chroma coding block. The size / dimension in luma samples of a coding block may be used in this invention to represent the size / dimension measured in luma samples. For example, a 128x128 coding block (or a coding block size 128x128 in luma samples) may refer to a 128x128 luma coding block and / or a 64x64 chroma coding block in a 4:2:0 color format. Similarly, in the case of a 4:2:2 color format, it may refer to a 128x128 luma coding block and / or a 64x128 chroma coding block. In the case of a 4:4:4 color format, it may refer to a 128x128 luma coding block and / or a 128x128 chroma coding block. Configurable CTU size 1. It is proposed to allow different CTU dimensions (e.g. width and / or height) for different video units, e.g. layers / pictures / subpictures / slices / tiles / bricks, etc.: a) In one example, a set or sets of CTU dimensions may be explicitly signaled at a video unit level, such as at the VPS / DPS / SPS / PPS / APS / picture / subpicture / slice / slice header / tile / brick level; b) In one example, when reference picture resampling (also known as adaptive resolution change) is allowed, the CTU dimensions may differ between different layers: i. For example, the CTU dimensions of an inter-layer picture may be implicitly derived according to the downsample / upsample scaling factor: 1. For example, if the CTU size signaled for the base layer is M×N (e.g., M=128 and N=128), and an interlayer coded picture is resampled in width with a scaling factor S and in height with a scaling factor T (the scaling factors may be greater than or less than 1 (e.g., S=1 / 4 and T=1 / 2 indicates that the interlayer coded picture is downsampled to 1 / 4 in width and 1 / 2 in height), then the CTU size of the interlayer coded picture may be derived to be (M×S)×(N×T) or (M / S)×(N / T); ii. For example, different CTU dimensions may be explicitly signaled for multiple layers at the video unit level, e.g., for inter-layer resampled pictures / sub-pictures, the CTU dimensions may be signaled at the VPS / DPS / SPS / PPS / APS / picture / sub-picture / slice / slice header / tile / brick level that are different from the base layer CTU dimensions. 2. It is proposed that whether TT or BT splitting is allowed may depend on the VPDU dimensions (e.g. width and / or height, etc.). Let the VPDU have dimension VSize in luma samples and the coding tree block have dimension CtbSizeY in luma samples: a) In one example, VSize=min(M,CtbSizeY), where M is an integer value, such as 64; b) In one example, whether TT or BT splitting is allowed may be independent of the maximum transform size; c) In one example, TT splitting may be disabled when the coding block width or height in luminance samples is greater than min(VSize, maxTtSize): i. In one example, when the maximum transform size is equal to 32×32 but VSize is equal to 64×64, TT splitting may be disabled for 128×128 / 128×64 / 64×128 coding blocks; ii. In one example, when the maximum transform size is equal to 32×32, but VSize is equal to 64×64, TT splitting may be allowed for a 64×64 coding block; d) In one example, when a coding block width in luma samples is less than or equal to VSize, but its height in luma samples is greater than VSize, vertical BT splitting may be disabled: i. In one example, if the maximum transform size is 32×32, but the VPDU size is equal to 64×64, vertical BT splitting may be disabled for 64×128 coding blocks; ii. In one example, if the maximum transform size is 32×32, but the VPDU size is equal to 64×64, vertical BT splitting may be allowed for 32×64 / 16×64 / 8×64 coding blocks; e) In one example, when a coding block exceeds the picture / subpicture width in luma samples but its height in luma samples is greater than VSize, vertical BT splitting may be disabled: i. Alternatively, when a coding block exceeds the picture / subpicture width in luma samples, horizontal BT splitting may be allowed; f) In one example, when a coding block width in luma samples is greater than VSize but its height in luma samples is less than or equal to VSize, horizontal BT splitting may be disabled: i. In one example, if the maximum transform size is 32×32 but the VPDU size is equal to 64×64, vertical BT splitting may be disabled for 128×64 coding blocks; ii. In one example, if the maximum transform size is 32x32, but the VPDU size is equal to 64x64, horizontal BT splitting may be allowed for 64x8 / 64x16 / 64x32 coding blocks; g) In one example, when a coding block exceeds the height of the picture / subpicture in luma samples, but its width in luma samples is greater than VSize, horizontal BT splitting may be disabled: i. Alternatively, when a coding block exceeds the picture / subpicture height in luma samples, vertical BT splitting may be allowed; h) In one example, when TT or BT splitting is disabled, the TT or BT split flag is not signaled and may be implicitly derived to be zero: i. Alternatively, when TT and / or BT splitting is enabled, the TT and / or BT split flags may be explicitly signaled in the bitstream; ii. Alternatively, when TT or BT splitting is disabled, the TT or BT split flag may be signaled but ignored by the decoder; iii. Alternatively, when TT or BT splitting is disabled, the TT or BT split flag is signaled but must be zero in a conforming bitstream. 3. It is proposed that CTU dimensions (e.g. width and / or height) may be greater than 128: a) in one example, the signaled CTU size may be 256 or even larger (e.g., log2_ctu_size_minus5 may be 3 or greater); b) In one example, the derived CTU size may be 256 or even larger: i. For example, the derived CTU size for resampling a picture / subpicture may be greater than 128. 4. When larger CTU dimensions are allowed (e.g. CTU width and / or height is larger than 128), it is proposed that the QT split flag can be presumed to be true and QT split can be applied recursively until the dimension of the split coding block reaches a specified value (e.g. the specified value can be set to the maximum transform block dimension or 128 or 64 or 32): a) In one example, the recursive QT splitting may be performed implicitly without signaling until the split coding block size reaches the maximum transform block size; b) In one example, when CTU 256x256 is applied to a dual tree, the QT split flag may not be signaled for coding blocks larger than the maximum transform block size, and QT splitting may be forced to be used for coding blocks until the split coding block size reaches the maximum transform block size. 5. It is proposed that the TT split flag can be conditionally signaled for CU / PU dimensions (width and / or height) greater than 128: a) In one example, both horizontal and vertical TT split flags may be signaled for a 256x256 CU; b) In one example, no vertical TT split is done and horizontal TT split can be signaled for 256x128 / 256x64 CU / PU; c) In one example, no vertical TT split is done and horizontal TT split can be signaled for 128x256 / 64x256 CU / PU; d) In one example, when the TT split flag is prohibited for CU sizes greater than 128, it may not be signaled but may be implicitly derived as zero: i. In one example, horizontal TT splits may be disabled for 256x128 / 256x64 CU / PU; ii. In one example, vertical TT split may be disabled for 128x256 / 64x256 CU / PU. 6. It is proposed that the BT split flag can be conditionally signaled for CU / PU dimensions (width and / or height) greater than 128: a) In one example, both horizontal and vertical TT split flags may be signaled for 256x256 / 256x128 / 128x256 CU / PU; b) In one example, a horizontal BT split flag may be signaled for a 64×256 CU / PU; c) In one example, a vertical BT split flag may be signaled for a 256x64 CU / PU; d) In one example, when the BT split flag is prohibited for CU sizes greater than 128, it may not be signaled but may be implicitly derived as zero: i. In one example, vertical BT split is prohibited for K×256 CU / PU (e.g., K is less than or equal to 64 in luma samples), and the vertical BT split flag may not be signaled but derived as zero: 1. For example, in the above case, vertical BT split can be prohibited for 64x256 CU / PU; 2. For example, in the above case, vertical BT splitting can be prohibited to avoid 32x256 CU / PU at picture / subpicture boundary; ii. In one example, when a coding block exceeds the picture / subpicture width in luma samples but its height in luma samples is greater than M (e.g., M=64 in luma samples), vertical BT splitting may be prohibited; iii. In one example, horizontal BT splitting is prohibited for 256×K coding blocks (e.g., K is less than or equal to 64 in luma samples), and the horizontal BT split flag may not be signaled but derived as zero: 1. For example, in the above case, horizontal BT splitting can be prohibited for 256x64 coding blocks; 2. For example, in the above case, horizontal BT splitting can be prohibited to avoid 256x32 coding blocks at picture / subpicture boundaries; iv. In one example, when a coding block exceeds the picture / subpicture height in luma samples but its width in luma samples is greater than M (eg, M=64 in luma samples), horizontal BT split may be prohibited. 7. It is proposed that the affine model parameter calculation may depend on the CTU dimensions: a) In one example, the derivation of scaled motion vectors and / or control point motion vectors in affine prediction may depend on the CTU size. 8. It is proposed that the Intra Block Copy (IBC) buffer may depend on the maximum configurable / allowable CTU size: a) For example, the IBC buffer width in luma samples may be equal to N×N divided by the CTU width (or height) in luma samples, where N is the maximum configurable CTU size in luma samples, e.g., N=1<<(log2_ctu_size_minus5+5). 9. It is proposed that a specified set of coding tools (one or more) may be disabled for large CUs / PUs, where large CUs / PUs refer to CUs / PUs whose either CU / PU width or CU / PU height is greater than N (e.g., N=64 or 128, etc.): a) In one example, the above specified coding tool(s) may be palette, and / or intra block copy (IBC), and / or intra skip mode, and / or triangular prediction mode, and / or CIIP mode, and / or normal merge mode, and / or decoder side motion derivation, and / or bidirectional optical flow, and / or prediction refinement based optical flow, and / or affine prediction, and / or sub-block based TMVP, etc.: i. Alternatively, screen content coding tools (one or more), such as palette and / or intra block copy (IBC) modes, may be applied to the large CU / PU; b) In one example, explicit syntax constraints may be used to disable a specified coding tool(s) for large CU / PU: i. For example, the palette / IBC flag may be explicitly signaled for CUs / PUs that are not large CUs / PUs; c) In one example, a bitstream constraint may be used to disable a specified coding tool(s) for large CU / PU. 10. Whether TT or BT splitting is allowed may depend on the block size: a) In one example, when a coding block width or height in luma samples is greater than N (e.g., N=64), TT splitting may be disabled: i. In one example, TT splitting may be disabled for 128×128 / 128×64 / 64×128 coding blocks when the maximum transform size is equal to 32×32; ii. In one example, TT splitting may be allowed for a 64×64 coding block when the maximum transform size is equal to 32×32; b) In one example, when a coding block width in luma samples is less than or equal to N (e.g., N=64) but its height in luma samples is greater than N (e.g., N=64), vertical BT splitting may be disabled: i. In one example, vertical BT splitting may be disabled for 64×128 coding blocks when the maximum transform size is 32×32; ii. In one example, when the maximum transform size is 32x32, vertical BT splitting may be allowed for 32x64 / 16x64 / 8x64 coding blocks; c) In one example, when a coding block exceeds the picture / subpicture width in luma samples but its height in luma samples is greater than 64, vertical BT splitting may be disabled: i. Alternatively, horizontal BT splitting may be allowed when a coding block exceeds the picture / subpicture width in luma samples; d) In one example, when a coding block width in luma samples is greater than N (e.g., N=64) but its height in luma samples is less than or equal to N (e.g., N=64), horizontal BT splitting may be disabled: i. In one example, vertical BT splitting may be disabled for 128×64 coding blocks when the maximum transform size is 32×32; ii. In one example, horizontal BT splitting may be allowed for 64×8 / 64×16 / 64×32 coding blocks when the maximum transform size is 32×32; e) In one example, when a coding block exceeds the picture / subpicture height in luma samples but its width in luma samples is greater than N (e.g., N=64), horizontal BT splitting may be disabled: i. Alternatively, when a coding block exceeds the picture / subpicture height in luma samples, vertical BT splitting may be allowed. Configurable maximum conversion size 11. It is proposed that the maximum TU size may depend on the CTU dimensions (width and / or height) or that the CTU dimensions may depend on the maximum TU size: a) In one example, a bitstream constraint may be used such that the maximum TU size is less than or equal to the CTU dimensions; b) In one example, the signaling of the maximum TU size may depend on the CTU dimensions: i. For example, when the CTU dimension is smaller than N (e.g., N=64), the maximum TU size signaled must be smaller than N; ii. For example, when the dimension of the CTU is smaller than N (e.g., N=64), an indication of whether the maximum luma transform size is 64 or 32 (e.g., sps_max_luma_transform_size_64_flag) may not be signaled, and the maximum luma transform size may be implicitly derived as 32. 12. For blocks with width and / or height larger than the transform block size, certain coding tools may be enabled: a) In one example, the specific coding tool may be intra sub-partition prediction (ISP), MIP, SBT, or other coding tool that splits one CU into multiple TUs or splits one CB into multiple TBs; b) In one example, the particular encoding tool may be an encoding tool that does not apply a transform (or only an identity transform is applied), e.g. transform skip mode, BDPCM / DPCM / PCM, etc.; c) The specific tool may be Intra Block Copy (IBC), Palette (PLT); d) A specific tool may be Combined Inter-Intra Prediction (CIIP). 13. Whether or not a particular coding tool is enabled may depend on the coding block size: a) In one example, the specific coding tool may be intra sub-partition prediction (ISP), matrix-based intra prediction (MIP), sub-block transform (SBT), intra block copy (IBC), palette (PLT), etc.; b) In one example, when the coding block width and / or height in luma samples is less than or equal to N (e.g., N=64), certain coding tools (e.g., ISP, MIP, etc.) may be allowed: i. Alternatively, certain coding tools may be disabled when the coding block width and / or height in luma samples is greater than N (e.g., N=64); c) Whether a particular coding tool (e.g. ISP, MIP, etc.) is enabled may depend on the relationship between coding block size and VPDU size: i. In one example, when the coding block width and / or height in luma samples is less than or equal to the VPDU size (e.g., 32 or 64), certain coding tools may be allowed: 1. Alternatively, certain coding tools may be disabled when the coding block width and / or height in luma samples is less than or equal to the VPDU size (e.g., 32 or 64); d) Whether intra-sub-partition prediction (ISP) is enabled and / or which partition type(s) (e.g., split direction) are allowed may depend on the relationship between the sub-partition dimensions and the maximum transform block size: i. In one example, ISP may be enabled when a sub-partition width and / or height is not greater than the maximum transform block size for at least one partition type: 1. Alternatively or additionally, the ISP may be otherwise revoked; ii. In one example, ISP may be enabled when the sub-partition width and / or height is not larger than the maximum transform block size for all allowed partition types: 1. Alternatively or additionally, the ISP may be otherwise revoked; iii. In one example, signaling of partition type (e.g., intra_subpartitions_split_flag) may depend on the relationship between the width and / or height of the corresponding subpartition based on the partition type and the maximum transform block size: 1. In one example, if only one partition type satisfies the condition that the width and / or height of the corresponding sub-partition based on the partition type is not larger than the maximum transform block size, the partition type may be inferred without being signaled; e) Whether a particular coding tool (e.g. IBC, PLT, etc.) is enabled may depend on the relationship between the coding block size and the maximum transform size (e.g. 32 or 64): i. in one example, whether a particular coding tool (e.g., IBC, PLT, etc.) is enabled may not be constrained by the relationship between the coding block size and the fixed number 64; ii. In one example, certain coding tools (e.g., IBC, PLT, etc.) may be allowed when the coding block width and height in luma samples are not larger than the maximum transform size: 1. In one example, when the block width and / or height in luma samples is larger than the maximum transform size, certain coding tools (e.g., IBC, PLT, etc.) may be disabled; 2. In one example, when the maximum transform size is equal to 32, certain coding tools (e.g., IBC, PLT, etc.) may be disabled when the block width and / or height in luma samples is equal to 64; f) if a particular coding tool is disabled, the associated syntax elements (e.g. intra_subpartitions_mode_flag and intra_subpartitions_split_flag for ISP, intra_mip_flag and intra_mip_mode for MIP, pred_mode_ibc_flag for IBC, pred_mode_plt_flag for PLT, etc.) may not be signaled and may be inferred to be 0; g) If a particular coding tool is disabled, the associated syntax elements (e.g., intra_subpartitions_mode_flag and intra_subpartitions_split_flag in ISP, intra_mip_flag and intra_mip_mode in MIP, pred_mode_ibc_flag in IBC, pred_mode_plt_flag in PLT, etc.) may be signaled but must be 0 in a conforming bitstream. 14. Implicit QT splitting may depend on VPDU size and / or maximum transform size: a) In one example, the implicit QT split may not be conditioned on the relationship between the coding block size and the fixed number 64; b) In one example, a coding block is implicitly split into 4 partitions, and each subpartition is implicitly split recursively until both the width and height of the subpartition reach the VPDU size; c) In one example, a coding block is implicitly split into 4 partitions, and each subpartition is implicitly split recursively until both the width and height of the subpartition reach the maximum transform size. 15. The maximum block width and / or height used for a sub-block transform (SBT) may depend on the maximum transform size: a) In one example, the maximum SBT size may be set equal to the maximum transform size; b) In one example, syntax elements related to maximum SBT size (e.g., sps_sbt_max_size_64_flag, etc.) may not be signaled; i. For example, when the maximum transform size is less than 64, sps_sbt_max_size_64_flag is not signaled and is inferred to be 0; ii. For example, sps_sbt_max_size_64_flag is signaled when the maximum transform size is less than 64 but must be equal to 0 in a conforming bitstream; c) In one example, the signaling of relevant syntax elements (such as cu_sbt_flag) may depend on the maximum transform size; d) In one example, the signaling of related syntax elements (such as cu_sbt_flag) may be independent of the maximum SBT size. 16. The maximum block size used for transform skip and / or intra-BDPCM may depend on the maximum transform size: a) In one example, the maximum transform skip size may be set equal to the maximum transform size; b) In one example, syntax elements related to maximum transform skip size (eg, log2_transform_skip_max_size_minus2, etc.) may not be signaled. 17. The maximum block size used for intra-BDPCM can be signaled separately: a) In one example, the maximum block size used for intra-BDPCM may be independent of the maximum block size used for transform skip; b) In one example, an SPS / VPS / PPS / slice / VPDU / CTU / CU level flag may be signaled in the bitstream to specify the maximum block size used for intra-BDPCM. 18. Enabling or disabling joint inter-intra prediction (CIIP) for a block may depend on the relationship between the block width and / or height and the maximum transform size: a) In one example, CIIP may be disabled for a block if the block width and / or height is greater than the maximum transform size; b) In one example, if CIIP is disabled, syntax elements indicating CIIP (eg, ciip_flag, etc.) may not be signaled. 19. When both the width and height of a CU coded in CIIP are smaller than 128, splitting the CU into multiple subpartitions is not allowed and intra prediction for a first subpartition may depend on reconstruction of a second subpartition, where intra prediction is performed before the first subpartition. 20. A CIIP-coded CU is allowed to be divided into some subpartitions, and intra prediction for a first subpartition may depend on the reconstruction of a second subpartition, where intra prediction is performed before intra prediction is performed on the first subpartition. Lossless Coding Related 21. The maximum size of a block that is transform-skip coded (i.e., no transform is applied / only an identity transform is applied) is derived from the maximum size for blocks to which a transform is applied (e.g., MaxTbSizeY): a) In one example, the maximum size for a transform skip coding block is estimated to be MaxTbSizeY; b) In one example, the maximum size signaling for transform skip coding blocks is skipped. 22. When lossless coding is enabled, luma mapping chroma scaling (LMCS) may be disabled for the current picture unit at sequence / picture / subpicture / slice / tile group / tile / brick / CTU row / CTU / CU / PU / TU / subblock level: a) In one example, LMCS enabled flags (e.g., sps_lmcs_enabled_flag, slice_lmcs_enabled_flag, slice_chroma_residual_scale_flag, lmcs_data, etc.) may be signaled conditional on sequence / picture / subpicture / slice / tile group / tile / brick / CTU row / CTU / CU / PU / TU / subblock level transform quantization bypass flags (e.g., sps_transquant_bypass_flag, pps_transquant_bypass_flag, cu_transquant_bypass_flag, etc.): i. In one example, if the transform quantization bypass flag is equal to 1, the LMCS enable flag may not be signaled and may be inferred to be 0: 1. In one example, if a sequence-level transform quantization bypass flag (e.g., sps_transquant_bypass_flag, etc.) is equal to 1, sequence and lower-level LMCS enablement flags (e.g., sps_lmcs_enabled_flag, slice_lmcs_enabled_flag, slice_chroma_residual_scale_flag, etc.) may be inferred to be 0 without being signaled; 2. In one example, if sequence level TransquantBypassEnabledFlag is equal to 1, APS level lmcs_data may not be signaled; 3. In one example, if a PPS level transform quantization bypass flag (e.g., pps_transquant_bypass_flag) is equal to 1, slice level LMCS enablement flags (e.g., slice_lmcs_enabled_flag, slice_lmcs_aps_id, slice_chroma_residual_scale_flag, etc.) may not be signaled and may be inferred to be 0; b) In one example, a bitstream constraint may be applied that when the transform quantization bypass flag is equal to 1, the LMCS enable flag should be equal to 0.

[0037] 5. Embodiments New additions are enclosed in bold double brackets, e.g., {{a}} means that “a” has been added, and deletions from the VVC Working Draft are enclosed in bold double square brackets, e.g., [[b]] ​​means that “b” has been deleted. These changes are based on the latest VVC Working Draft (JVET-O2001-v11).

[0038] 5.1 Example implementation #1 The following embodiment relates to the inventive method of making the maximum TU size dependent on the CTU size: (Outside 3) TIFF0007640646000006.tif105170

[0039] 5.2 Example implementation #2 The following embodiment relates to an inventive method of making the TT and BT splitting process dependent on the VPDU size: (outside 4) TIFF0007640646000007.tif228170TIFF0007640646000008.tif35170

[0040] 5.3 Example implementation #3 The following embodiment relates to an inventive method for making the affine model parameters calculation dependent on the CTU size: (outside 5) TIFF0007640646000009.tif229170TIFF0007640646000010.tif178170

[0041] 5.4 Embodiment #4 on Allowing BT and TT Splits Depending on Block Size As shown in FIG. 1, whether the maximum transform size is 32×32 or 64×64, TT splitting can be allowed for coding blocks of block size 64×64, and BT splitting can be allowed for block sizes 32×64, 16×64, 8×64, 64×32, 64×16, and 64×8.

[0042] FIG. 1 is an example of allowing BT and TT splits depending on block size.

[0043] 5.5 Embodiment #5 on Applying ISP According to VPDU Size or 64x64 The changes are based on the latest VVC working draft (JVET-O2001-v14): (outside 6) TIFF0007640646000011.tif167170TIFF0007640646000012.tif173170TIFF0007640646000013.tif187170

[0044] 5.6 Embodiment #6 on applying MIP according to VPDU size or 64x64 The following embodiment describes the inventive method to make ISP dependent on VPDU size. The modifications are based on the latest VVC working draft (JVET-O2001-v14): (outside 7) TIFF0007640646000014.tif137170

[0045] 5.7 Embodiment #7 on Applying SBT Depending on Maximum Transformation Size (outside 8) TIFF0007640646000015.tif75168TIFF0007640646000016.tif229170

[0046] 5.8 Embodiment #8 on Applying Transform Skip Depending on Maximum Transform Size (outer 9) TIFF0007640646000017.tif234170TIFF0007640646000018.tif162170

[0047] 5.9 Embodiment #9 of clip_flag according to maximum transformation size (Outside 10) TIFF0007640646000019.tif222165TIFF0007640646000020.tif226170

[0048] 5.10 Implementation Example #10 of sps_max_luma_transform_size_64_flag according to CtbSizeY (Outside 11) TIFF0007640646000021.tif229170TIFF0007640646000022.tif56167

[0049] FIG. 2 is a block diagram of a video processing device 200. The device 200 may be used to implement one or more of the methods described herein. The device 200 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver. The device 200 may include one or more processors 202, one or more memories 204, and video processing hardware 206. The processor(s) 202 may be configured to execute one or more of the methods described herein. The memory(s) 204 may be used to store data and code used to execute the methods and techniques described herein. The video processing hardware 206 may be used to implement some of the techniques described herein in hardware circuitry. In some embodiments, the video processing hardware 206 may be at least partially within a processor (graphical co-processor unit).

[0050] In some embodiments, the video encoding method may be implemented using an apparatus implemented on a hardware platform such as that described with respect to FIG.

[0051] Some embodiments of the disclosed technology include making a decision to enable a video processing tool or mode. In one example, when a video processing tool or mode is enabled, the encoder will use or implement that tool or mode in processing blocks of video, but will not necessarily modify the resulting bitstream based on the use of that tool or mode. That is, the conversion of blocks of video to a bitstream representation of video will use the video processing tool or mode when it is enabled based on the decision. In another example, when a video processing tool or mode is enabled, the decoder will process the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, the conversion of a bitstream representation of video to blocks of video will be performed using the video processing tool or mode that was enabled based on the decision.

[0052] Some embodiments of the disclosed technology include making a decision to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, an encoder will not use that tool or mode in converting blocks of video into a video bitstream. In another example, when a video processing tool or mode is disabled, a decoder will process the bitstream with the knowledge that the bitstream has not been modified using the video processing tool or mode that was enabled based on the decision.

[0053] 3 is a block diagram illustrating an example of a video processing system 300 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 300. System 300 may include an input 302 for receiving video content. The video content may be received in a raw or uncompressed format, such as 8-bit or 10-bit multi-component pixel values, or in a compressed or encoded format. Input 302 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0054] The system 300 may include an encoding component 304 that may implement various coding or encoding methods described herein. The encoding component 304 may reduce the average bit rate of the video from the input 302 to the output of the encoding component 304 to generate an encoded representation of the video. Encoding techniques are therefore sometimes referred to as video compression techniques or video transcoding techniques. The output of the encoding component 304 may be stored or transmitted via a communication connection as represented by component 306. The stored or communicated bitstream (or encoded) representation of the video received at the input 302 may be used by component 308 to generate pixel values ​​or a displayable video that is sent to the display interface 310. The process of generating a user-viewable video from the bitstream representation is sometimes referred to as video decompression. Also, although certain video processing operations may be referred to as "encoding" operations or tools, it is understood that the encoding tools or operations are used at the encoder and the corresponding decoding tools or operations that reverse the results of the encoding are performed at the decoder.

[0055] 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 in this document may be embodied in a variety of electronic devices, such as, for example, mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

[0056] 4 is a flow chart of a method 400 of video processing. The method 400 includes, at operation 410, performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of video blocks of one or more video blocks is enabled using a dimension of a virtual pipeline data unit (VPDU) used to convert between a video having one or more video regions with one or more video blocks and a bitstream representation of the video, the dimension being equal to VSize in luma samples.

[0057] The method 400 includes, at operation 420, performing the conversion based on the determination.

[0058] 5 is a flow chart of a method 500 of video processing. The method 500 includes, at operation 510, performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of one or more video blocks is enabled using dimensions of the one or more video blocks for conversion between a video having one or more video regions with the one or more video blocks and a bitstream representation of the video.

[0059] The method 500 includes, at operation 520, performing the conversion based on the determination.

[0060] 6 is a flow chart of a method 600 of video processing. Method 600 includes, at operation 610, performing a determination whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks with a height or width of a video block and a bitstream representation of the video, based on a comparison between the height or width and a value N, where N is a positive integer.

[0061] The method 600 includes, at operation 620, performing the conversion based on the determination.

[0062] 7 is a flow chart of a method 700 of video processing. Method 700 includes performing, at operation 710, a determination of whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks with a comparison between the height or width of a video block and a size of a transform block and a bitstream representation of the video.

[0063] The method 700 includes, at operation 720, performing the conversion based on the determination.

[0064] 8 is a flow chart of a method of video processing 800. Method 800 includes, at operation 810, performing a determination whether an encoding tool is enabled to use the height or width of a video block to convert between a video having one or more video regions having one or more video blocks and a bitstream representation of the video.

[0065] The method 800 includes, at operation 820, performing the conversion based on the determination.

[0066] 9 is a flow chart of a method 900 of video processing. Method 900 includes, at operation 910, using a comparison between dimensions of a sub-partition of a video block and a maximum transform size to (a) determine whether an intra sub-partition prediction (ISP) mode is enabled for transforming between a video having one or more video regions with one or more video blocks with the video block, and (b) select one or more allowed partition types for the transform.

[0067] The method 900 includes, at operation 920, performing the conversion based on the determination and the selection.

[0068] 10 is a flow chart of a method 1000 of video processing. The method 1000 includes, at operation 1010, performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video having a disabled coding tool, where a syntax element relating to the coding tool is excluded from the bitstream representation and is presumed to be a predefined value that specifies that the coding tool is disabled.

[0069] 11 is a flow chart of a method 1100 of video processing. The method 1100 includes, at operation 1110, performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having coding tools disabled, the bitstream representation having syntax elements related to the coding tools that are presumed to be a predetermined value based on the coding tools being disabled.

[0070] 12 is a flow diagram of a method 1200 of video processing. The method 1200 includes, at operation 1210, performing a determination of whether implicit (QT) splitting of video blocks of one or more video blocks is enabled using dimensions of a virtual pipeline data unit (VPDU) and / or a maximum transform size used to convert between a video having one or more video regions with one or more video blocks and a bitstream representation of the video.

[0071] The method 1200 includes, at operation 1220, performing the conversion based on the determination.

[0072] 13 is a flow chart of a method 1300 of video processing. The method 1300 includes, at operation 1310, performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion comprising a sub-block transform (SBT), where a maximum height or width of the SBT is based on a maximum transform size.

[0073] 14 is a flow chart of a method 1400 of video processing. The method 1400 includes, at operation 1410, performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a transform skip mode and / or an intra-block-based differential pulse code modulation (BDPCM) mode, where a maximum block size used for the transform skip mode is based on the maximum transform size.

[0074] 15 is a flow diagram of a method 1500 of video processing. Method 1500 includes, at operation 1510, performing a determination of whether a combined inter-intra prediction (CIIP) mode is enabled for conversion between a video having one or more video regions with one or more video blocks and a bitstream representation of the video using a comparison between a height or width of a video block and a maximum transform size.

[0075] The method 1500 includes, at operation 1520, performing the conversion based on the determination.

[0076] 16 is a flow chart of a method 1600 of video processing. The method 1600 includes, at process 1610, making a decision regarding partitioning a video block of one or more video blocks coded with joint inter-intra prediction (CIIP) for conversion between a video having one or more video regions with one or more video blocks and a bitstream representation of the video.

[0077] The method 1600 includes, at operation 1620, performing the conversion based on the determination.

[0078] 17 is a flow chart of a method 1700 of video processing. The method 1700 includes, at operation 1710, converting between a video having a video region having a plurality of video blocks and a bitstream representation of the video according to a rule that specifies that a maximum block size of video blocks in the video region that are encoded into the bitstream representation using transform coding determines a maximum block size of video blocks in the video region that are encoded into the bitstream representation without transform coding.

[0079] 18 is a flow chart of a method 1800 of video processing. The method 1800 includes, at operation 1810, performing a conversion between a video having an image region having a plurality of video blocks and a bitstream representation of the video according to a rule that specifies that a luma mapping with chroma scaling (LMCS) process is disabled for an image region when lossless coding is enabled for the image region, the image region being a sequence, a picture, a subpicture, a slice, a tile group, a tile, a brick, a coding tree unit (CTU) row, a CTU, a coding unit (CU), a prediction unit (PU), a transform unit (TU), or a subblock.

[0080] In method 400-1800, in ISP mode, a video block of the one or more video blocks is divided into a number of sub-partitions before application of intra prediction and transform.

[0081] In the method 400-1800, the SBT comprises one or more transforms that are applied separately to one or more partitions of an image block of the one or more image blocks.

[0082] In the method 400-1800, the transform skip mode includes skipping the transform and inverse transform processes for the corresponding coding tool, and in the BDPCM mode, the residual of the intra prediction of the current video block is predictively coded using a differential pulse coding modulation process.

[0083] In method 400-1800, in CIIP mode, the final prediction of a video block is based on a weighted sum of an inter prediction of the video block and an intra prediction of the video block.

[0084] In method 400-1800, the LMCS process includes reshaping luma samples in the video domain between a first domain and a second domain, and scaling the chroma residual in a luma-dependent manner.

[0085] In some embodiments, the following technical solutions may be implemented:

[0086] A1. A method of video processing, comprising: performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of one or more video blocks is enabled using dimensions of a virtual pipeline data unit (VPDU) used to convert between an image having one or more image regions having one or more video blocks and a bitstream representation of the image, and performing the conversion based on the determination, wherein the dimensions are equal to VSize in luma samples and the dimensions of the video blocks are CtbSizeY in luma samples, where VSize=min(M,CtbSizeY), where M is a positive integer.

[0087] A2. A method of solution A1, where M=64.

[0088] A3. The method of solution A1 or A2, wherein the dimension of the VPDU is height or width.

[0089] A4. A method of solution A1, wherein said determination does not depend on the maximum transformation size.

[0090] A5. Any of solutions A1 to A4, wherein VSize is a predetermined value.

[0091] A6. The method of solution A5, where VSize=64.

[0092] A7. The method of solution A1, wherein the TT partitioning determination is based on the width or height of the video block in luma samples being greater than min(VSize, maxTtSize), where maxTtSize is a maximum transform size.

[0093] A8. The method of solution A1, wherein the TT partitioning determination is based on the width or height of the video block in luma samples being greater than VSize.

[0094] A9. The method of solution A7, wherein maxTtSize is 32x32 and VSize is 64x64, and the TT partitioning is disabled when the size of the video block is 128x128, 128x64, or 64x128.

[0095] A10. The method of solution A7, wherein maxTtSize is 32x32 and VSize is 64x64, and the TT partitioning is enabled when the size of the video block is 64x64.

[0096] A11. The method of Solution A1, wherein the determination of a vertical BT partition is based on a width of the video block in luma samples being less than or equal to VSize and a height of the video block in luma samples being greater than VSize.

[0097] A12. The method of solution A11, wherein the maximum transform size is 32x32 and VSize is 64x64, and the vertical BT partitioning is disabled when the size of the image block is 64x128.

[0098] A13. The method of solution A11, wherein the maximum transform size is 32x32 and VSize is 64x64, and the vertical BT split is enabled when the size of the image block is 32x64, 16x64, or 8x64.

[0099] A14. The method of Solution A1, in which vertical BT splitting is disabled when (i) the sum of the width of the video block in luma samples and the horizontal coordinate of the top-left luma sample of the video block is greater than the width of a picture or the width of a subpicture that has the video block in luma samples, and (ii) the height of the video block in luma samples is greater than VSize.

[0100] A15. The method of solution A1, in which horizontal BT splitting is enabled when the sum of the width of the image block in luma samples and the horizontal coordinate of the top-left luma sample of the image block is greater than the width of a picture or the width of a subpicture that has the image block in luma samples.

[0101] A16. The method of Solution A1, wherein the determination of a horizontal BT partition is based on a width of the video block in luma samples being greater than VSize and a height of the video block in luma samples being less than or equal to VSize.

[0102] A17. The method of solution A16, wherein the maximum transform size is 32x32 and VSize is 64x64, and the horizontal BT split is disabled when the size of the image block is 128x64.

[0103] A18. The method of solution A16, wherein the maximum transform size is 32x32 and VSize is 64x64, and the horizontal BT split is enabled when the size of the image block is 64x8, 64x16, or 64x32.

[0104] A19. The method of Solution A1, in which horizontal BT splitting is disabled when (i) the sum of the height of the video block in luma samples and the vertical coordinate of the top-left luma sample of the video block is greater than the height of a picture or the height of a sub-picture that has the video block in luma samples, and (ii) the width of the video block in luma samples is greater than VSize.

[0105] A20. The method of solution A1, in which vertical BT splitting is enabled when the sum of the height of the image block in luma samples and the vertical coordinate of the top-left luma sample of the image block is greater than the height of a picture or the height of a subpicture that has the image block in luma samples.

[0106] A21. A method of solution A1, wherein the TT or the BT partitioning is disabled and an indication of the TT or the BT partitioning is excluded from the bitstream representation, the indication being implicitly derived to be a predetermined value indicating that the TT or the BT partitioning is disabled.

[0107] A22. The method of solution A21, wherein the predetermined value is zero.

[0108] A23. The method of solution A1, wherein the TT or the BT splitting is enabled and an indication of the TT or the BT splitting is signaled within the bitstream representation.

[0109] A24. The method of solution A1, wherein the TT or the BT splitting is disabled and an indication of the TT or the BT splitting is signaled in the bitstream representation, which indication is ignored by a decoder.

[0110] A25. The method of Solution A1, wherein the TT or the BT partitioning is disabled, and an indication of the TT or the BT partitioning is signaled within the bitstream representation, the indication being zero based on the TT or the BT partitioning being disabled.

[0111] A26. A method of video processing, comprising: for converting between an image having one or more image regions having one or more video blocks and a bitstream representation of the image, performing a determination of whether ternary tree (TT) or binary tree (BT) partitioning of the video block is enabled using dimensions of the one or more video blocks, and performing the conversion based on the determination.

[0112] A27. The method of solution A26, wherein the determination of the TT or BT partitioning is based on a width or height of the video block in luma samples being greater than N, where N is a positive integer.

[0113] A28. A method of solution A27, where N=64.

[0114] A29. The method of solution A27 or A28, wherein a maximum transform size is 32x32 and the TT partitioning is disabled when the size of the image block is 128x128, 128x64, or 64x128.

[0115] A30. The method of solution A27 or A28, wherein maxTtSize is 32x32 and the TT partitioning is enabled when the size of the video block is 64x64.

[0116] A31. The method of solution A26, wherein the determination of a vertical BT partition is based on a width of the video block in luma samples being less than or equal to N and a height of the video block in luma samples being greater than N, where N is a positive integer.

[0117] A32. A method of solution A31, where N=64.

[0118] A33. The method of solution A31 or A32, wherein the maximum transform size is 32x32 and the vertical BT split is disabled when the size of the image block is 64x128.

[0119] A34. The method of solution A31 or A32, wherein a maximum transform size is 32x32 and the vertical BT partitioning is enabled when the size of the image block is 32x64, 16x64, or 8x64.

[0120] A35. The method of solution A26, in which vertical BT splitting is disabled when (i) the sum of the width of the video block in luma samples and the horizontal coordinate of the top-left luma sample of the video block is greater than the width of a picture or the width of a subpicture that has the video block in luma samples, and (ii) the height of the video block in luma samples is greater than 64.

[0121] A36. The method of solution A26, in which horizontal BT splitting is enabled when the sum of the width of the image block in luma samples and the horizontal coordinate of the top-left luma sample of the image block is greater than the width of a picture or the width of a subpicture that has the image block in luma samples.

[0122] A37. The method of solution A26, wherein the determination of a horizontal BT partition is based on a width of the video block in luma samples being greater than N and a height of the video block in luma samples being less than or equal to N, where N is an integer.

[0123] A38. A method of solution A37, where N=64.

[0124] A39. The method of solution A37 or A38, wherein the maximum transform size is 32x32 and the horizontal BT split is disabled when the image block size is 128x64.

[0125] A40. The method of solution A37 or A38, wherein a maximum transform size is 32x32 and the horizontal BT split is enabled when the size of the image block is 64x8, 64x16, or 64x32.

[0126] A41. The method of solution A26, wherein horizontal BT splitting is disabled when (i) the sum of the height of the video block in luma samples and the vertical coordinate of the luma sample of the video block is greater than the height of a picture or the height of a subpicture having the video block in luma samples, and (ii) the width of the video block in luma samples is greater than N, where N is a positive integer.

[0127] A42. The method of solution A26, in which vertical BT splitting is enabled when the sum of the height of the image block in luma samples and the vertical coordinate of the top-left luma sample of the image block is greater than the height of a picture or the height of a subpicture that has the image block in luma samples.

[0128] A43. Any of the methods of Solutions A1 to A42, wherein the video blocks correspond to coding tree units (CTUs) that represent logical partitions used to encode the video into the bitstream representation.

[0129] A44. The method of any of Solutions A1 to A43, wherein performing the conversion comprises generating the bitstream representation from the video domain.

[0130] A45. The method of any of Solutions A1 to A43, wherein performing the conversion includes generating the video domain from the bitstream representation.

[0131] A46. An apparatus in a video system having a processor and a non-transitory memory having instructions which, when executed by the processor, cause the processor to perform any of the methods of solutions A1 to A45.

[0132] A47. A computer program product stored on a non-transitory computer readable medium, comprising a program code for carrying out the method of any of the solutions A1 to A45.

[0133] In some embodiments, the following technical solutions may be implemented:

[0134] B1. A method of video processing comprising: using a height or width of a video block to determine whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks having the video block and a bitstream representation of the video, and performing the conversion based on the determination, wherein the determination is based on a comparison between the height or width and a value N, where N is a positive integer.

[0135] B2. A method of solution B1 where N=64.

[0136] B3. The method of solution B1, where N=128.

[0137] B4. The method of any of Solutions B1 to B3, wherein the coding tools that are disabled include a palette coding mode, an intra block copy (IBC) mode, and / or a combined intra-inter prediction (CIIP) mode.

[0138] B5. Any of Solutions B1 to B4, wherein the encoding tool further comprises an intra-skip mode, a triangular prediction mode, a normal merge mode, a decoder-side motion derivation mode, a bidirectional optical flow mode, a prediction refinement-based optical flow mode, an affine prediction mode, and / or a sub-block-based temporal motion vector prediction mode.

[0139] B6. The method of any of Solutions B1 to B3, wherein the enabled coding tools include a palette coding mode and / or an intra block copy (IBC) mode.

[0140] B7. The method of any of Solutions B1 to B3, wherein the bitstream representation has explicit syntax constraints for overriding the encoding tool.

[0141] B8. The method of solution B7, wherein the explicit syntax constraint comprises a palette coding mode flag and / or an intra block copy (IBC) mode flag.

[0142] B9. Any of the methods of Solutions B1 to B8, wherein the video block comprises a coding unit (CU) or a prediction unit (PU).

[0143] B10. A method of video processing, comprising: using a comparison between a height or width of a video block and a size of a transformation block to determine whether an encoding tool is enabled to transform between a video having one or more video regions having one or more video blocks having the video block and a bitstream representation of the video; and performing the transformation based on the determination.

[0144] B11. The method of solution B10, wherein the encoding tool includes an encoding tool that performs intra sub-partition prediction (ISP), matrix-based intra prediction (MIP), sub-block transform (SBT), or splits one coding unit (CU) associated with the image domain into multiple transform units (TU) or splits one coding block associated with the image domain into multiple transform blocks (TB).

[0145] B12. The method of solution B10, wherein the encoding tool comprises transform skip mode, block-based delta pulse code modulation (BDPCM), DPCM, or PCM.

[0146] B13. The method of solution B10, wherein the encoding tool has an intra block copy (IBC) mode or a palette mode (PLT).

[0147] B14. The method of Solution B10, wherein the encoding tool has a combined intra-inter prediction (CIIP) mode.

[0148] B15. A method of video processing, comprising: using a height or width of a video block to determine whether an encoding tool is enabled to convert between a video having one or more video regions having one or more video blocks that include the video block and a bitstream representation of the video; and performing the conversion based on the determination.

[0149] B16. The method of solution B15, wherein the encoding tool comprises intra sub-partition prediction (ISP), sub-block transform (SBT), intra block copy (IBC) mode, or palette mode.

[0150] B17. The method of Solution B15, wherein the encoding tool has intra sub-partition prediction (ISP) that is enabled when the height or the width of the video block in luma samples is less than or equal to N, where N is a positive integer.

[0151] B18. The method of Solution B15, wherein the encoding tool has intra sub-partition prediction (ISP) that is disabled when the height or the width of the video block in luma samples is greater than N, where N is a positive integer.

[0152] B19. The method of solutions B17 or B18, where N=64.

[0153] B20. The method of solution B15, wherein the determining is based on a comparison between the height or the width of the video block and a size of a virtual pipeline data unit (VPDU).

[0154] B21. The method of solution B20, wherein the encoding tool is enabled when the height or the width of the video block in luma samples is less than or equal to the size of the VPDU.

[0155] B22. The method of solution B20, wherein the encoding tool is disabled when the height or the width of the video block in luma samples is greater than the size of the VPDU.

[0156] B23. The method of solution B21 or B22, wherein the size of the VPDU is 32 or 64.

[0157] B24. A method of video processing, comprising: using a comparison between dimensions of a sub-partition of a video block and a maximum transform size to (a) determine whether an intra sub-partition prediction (ISP) mode is enabled for transforming between a video having one or more video regions having one or more video blocks having the video block; and (b) performing a selection of one or more allowed partition types for the transform, and performing the transform based on the determination and the selection, wherein in the ISP mode, a video block of the one or more video blocks is divided into a plurality of sub-partitions before application of intra prediction and transform.

[0158] B25. The method of solution B24, wherein the ISP mode is enabled when the height or width of the image block is less than or equal to the maximum transform size for at least one of the one or more allowed partition types.

[0159] B26. The method of solution B24, wherein the ISP mode is disabled when the height or width of the image block is greater than the maximum transform size for at least one of the one or more allowed partition types.

[0160] B27. The method of solution B24, wherein the ISP mode is enabled when the height or width of the image block is less than or equal to the maximum transform size for each of the one or more allowed partition types.

[0161] B28. The method of solution B24, wherein the ISP mode is disabled when the height or width of the image block is greater than the maximum transform size for each of the one or more allowed partition types.

[0162] B29. The method of solution B24, wherein signaling within the bitstream representation of the one or more allowed partition types is based on a relationship between a height or width of a corresponding sub-partition and the maximum transform size.

[0163] B30. The method of solution B24, wherein signaling within the bitstream representation the one or more allowed partition types is based on a relationship between a height or width of the video block and the maximum transform size.

[0164] B31. The method of solution B24, wherein enabling or disabling application of an encoding tool to the video block is based on a relationship between a height or width of the video block and the maximum transform size.

[0165] B32. The method of solution B31, wherein the maximum transform size is 32 or 64.

[0166] B33. The method of solution B31 or B32, wherein the encoding tool is enabled when the height or width of the video block is less than or equal to a maximum transform size.

[0167] B34. The method of any of Solutions B31 to B33, wherein the encoding tool has an intra block copy (IBC) mode or a palette mode.

[0168] B35. A method of video processing, comprising: performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a disabled coding tool, wherein a syntax element relating to the coding tool is excluded from the bitstream representation and is assumed to be a predetermined value specifying that the coding tool is disabled.

[0169] B36. A method of video processing, comprising: performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion having a coding tool that is disabled, the bitstream representation having a syntax element related to the coding tool that is estimated to be a predetermined value based on the coding tool being disabled.

[0170] B37. The method of solution B35 or B36, wherein said predetermined value is zero.

[0171] B38. A method of solution B35 or B36, wherein the encoding tool has intra subpartition prediction (ISP) and the syntax element indicates whether a video block of the one or more video blocks is divided into multiple subpartitions (denoted as intra_subpartitions_mode_flag) and / or indicates how the video block is divided into multiple subpartitions (denoted as intra_subpartitions_split_flag).

[0172] B39. A method of solution B35 or B36, wherein the encoding tool has matrix-based intra prediction (MIP) and the syntax element indicates whether a video block of the one or more video blocks uses the MIP (denoted intra_mip_flag) and / or indicates an indication of a MIP mode index (denoted intra_mip_mode).

[0173] B40. The method of solution B35 or B36, wherein the encoding tool has an intra block copy (IBC) mode and the syntax element indicates whether a video block of the one or more video blocks uses the IBC mode (denoted as pred_mode_ibc_flag).

[0174] B41. The method of solution B35 or B36, wherein the encoding tool has a palette mode and the syntax element indicates whether a video block of the one or more video blocks uses palette mode (denoted as pred_mode_plt_flag).

[0175] B42. A method of video processing, comprising: performing a determination of whether implicit (QT) splitting of video blocks of one or more video blocks is enabled using dimensions of a virtual pipeline data unit (VPDU) and / or a maximum transform size used to convert between a video having one or more video regions having one or more video blocks and a bitstream representation of the video; and performing the conversion based on the determination.

[0176] B43. The method of solution B42, wherein each subpartition of the implicit QT partition is recursively partitioned until the size of the subpartition is equal to the size of the VPDU.

[0177] B44. The method of solution B42, wherein each subpartition of the implicit QT partition is recursively partitioned until the size of the subpartition is equal to the maximum transform size.

[0178] B45. A method of video processing, comprising: performing a transformation between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the transformation comprising a sub-block transform (SBT), a maximum height or width of the SBT being based on a maximum transform size, the SBT comprising one or more transforms applied separately to one or more partitions of a video block of the one or more video blocks.

[0179] B46. The method of solution B45, wherein at least one of the maximum height or the maximum width of the SBT is set equal to the maximum transform size.

[0180] B47. The method of solution B45, wherein the bitstream representation excludes syntax elements relating to the maximum height or the maximum width of the SBT.

[0181] B48. The method of solution B47, wherein the syntax element is sps_sbt_max_size_64_flag, which is presumed to be a predefined value indicating that the maximum transform size is less than 64.

[0182] B49. The method of solution B48, wherein said predetermined value is zero.

[0183] B50. The method of solution B47, wherein signaling within the bitstream representation a syntax element related to the SBT is based on the maximum transform size.

[0184] B51. A method of video processing, comprising: performing a conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video, the conversion comprising a transform skip mode and / or an intra block-based differential pulse code modulation (BDPCM) mode, a maximum block size used for the transform skip mode based on a maximum transform size, the transform skip mode comprising skipping transform and inverse transform processes for a corresponding coding tool, and in the BDPCM mode, a residual of an intra prediction of the current video block is predictively coded using a differential pulse code modulation process.

[0185] B52. The method of solution B51, wherein the maximum block size in the transform skip mode is set equal to the maximum transform size.

[0186] B53. The method of solution B51, wherein the bitstream representation excludes a syntax element relating to the maximum block size in the transform skip mode.

[0187] B54. The method of solution B51, wherein a maximum block size used for the intra-BDPCM mode is signaled independently within the bitstream representation.

[0188] B55. The method of solution B54, wherein the maximum block size used for the intra BDPCM mode is not based on the maximum block size in the transform skip mode.

[0189] B56. The method of solution B51, wherein the maximum block size used for the intra-BDPCM mode is signaled within a sequence parameter set (SPS), a video parameter set (VPS), a picture parameter set (PPS), a slice header, a virtual pipeline data unit (VPDU), a coding tree unit (CTU), or a coding unit (CU) within the bitstream representation.

[0190] B57. A method of video processing, comprising: using a comparison between a height or width of a video block and a maximum transform size to determine whether a combined inter-intra prediction (CIIP) mode is enabled for a conversion between a video having one or more video regions having one or more video blocks having the video block and a bitstream representation of the video; and performing the conversion based on the determination, wherein in the CIIP mode, a final prediction of the video block is based on a weighted sum of an inter prediction of the video block and an intra prediction of the video block.

[0191] B58. The method of solution B57, wherein the CIIP mode is disabled when the height and / or the width of the image block is greater than the maximum transform size.

[0192] B59. A method of video processing, comprising: making a decision regarding partitioning a video block of one or more video blocks coded with combined inter-intra prediction (CIIP) for conversion between a video having one or more video regions having one or more video blocks and a bitstream representation of the video; and performing the conversion based on the decision, wherein in the CIIP mode, a final prediction of the video block is based on a weighted sum of an inter prediction of the video block and an intra prediction of the video block.

[0193] B60. The method of solution B59, wherein the video block is not split when the height and width of the coding unit are less than 128.

[0194] B61. The method of solution B59, wherein the video block is not split when the height and width of the coding unit are less than or equal to 64.

[0195] B62. The method of solution B59, wherein the video block is divided into a plurality of subpartitions, and intra prediction for a first subpartition of the plurality of subpartitions is based on a reconstruction of a second subpartition of the plurality of subpartitions, and intra prediction of the second subpartition is performed prior to the intra prediction of the first subpartition.

[0196] B63. Any of the methods of solutions B59 to B62, wherein the video block is a coding unit (CU).

[0197] B64. A method of video processing, comprising: performing a conversion between a video having a video region having a plurality of video blocks and a bitstream representation of the video according to rules specifying that a maximum block size of the plurality of video blocks in the video region that are encoded into the bitstream representation using transform coding determines a maximum block size of the plurality of video blocks in the video region that are encoded into the bitstream representation without transform coding.

[0198] B65. The method of solution B64, wherein the maximum size in transform skip mode is equal to MaxTbSizeY.

[0199] B66. The method of solution B64, wherein the bitstream representation excludes an indication of the maximum size in the transform skip mode.

[0200] B67. A method of video processing, comprising: performing a conversion between an image having an image domain having a plurality of image blocks and a bitstream representation of the image according to rules that specify that a luma mapping with chroma scaling (LMCS) process is disabled for the image domain when lossless coding is enabled for the image domain, the image domain being a sequence, a picture, a subpicture, a slice, a tile group, a tile, a brick, a coding tree unit (CTU) row, a CTU, a coding unit (CU), a prediction unit (PU), a transform unit (TU), or a sub-block, and the LMCS process includes reshaping luma samples of the image domain between a first domain and a second domain, and scaling chroma residual in a luma-dependent manner.

[0201] B68. The method of solution B67, wherein signaling the indication regarding the LMCS process is based on a transform quantization bypass flag for the video domain.

[0202] B69. The method of solution B68, wherein when the transform quantization bypass flag is equal to one, the indication regarding the LMCS process is excluded from the bitstream representation and is presumed to be zero.

[0203] B70. The method of any of Solutions B1 to B69, wherein performing the conversion comprises generating the bitstream representation from the video domain.

[0204] B71. The method of any of Solutions B1 to B69, wherein performing the conversion includes generating the video domain from the bitstream representation.

[0205] B72. An apparatus in a video system having a processor and a non-transitory memory having instructions which, when executed by the processor, cause the processor to perform any of the methods of solutions B1 to B71.

[0206] B73. A computer program product stored on a non-transitory computer readable medium, comprising a program code for carrying out the method of any of solutions B1 to B71.

[0207] The disclosed and other solutions, examples, embodiments, modules and functional operations described in this document, including the structures disclosed in this document and their structural equivalents, can be implemented in digital electronic circuitry, or computer software, firmware, or hardware, or in a combination of one or more of these. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., as one or more modules of computer program instructions encoded on a computer-readable medium for execution by or for 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 producing a machine-readable propagated signal, or a combination of one or more of these. The term "data processing apparatus" encompasses any apparatus, device, and machine that processes 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 that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these. A propagated signal is an artificially generated signal, for example a machine-generated electrical, optical, or electromagnetic signal generated to encode information for transmission to an appropriate receiver device.

[0208] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and may 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 may be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple cooperating files (e.g., a file that stores one or more modules, subprograms, or portions of code). A computer program may be deployed to be executed on one computer or to be executed on multiple computers, located at one site, or distributed across multiple sites and interconnected by a communication network.

[0209] The processes and logic flows described in this document 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. These processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0210] Processors suitable for executing computer programs include, by way of example, both general purpose and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices for storing data, e.g., magnetic disks, magneto-optical disks, or optical disks, or is operatively coupled to receive data from or transfer data to the 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, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices, magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, dedicated logic circuitry.

[0211] Although this patent document contains numerous details, they should not be construed as limitations on any subject matter or the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular technology. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are 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 acting in a particular combination, and even initially claimed as such, in some cases one or more features from a claimed combination may be removed from the combination, or the claimed combination may be brought into a subcombination or a variation of the subcombination.

[0212] Similarly, although the figures show operations in a particular order, this should not be understood as requiring that those operations be performed in the particular order or sequence shown, or that all of the operations shown be performed, to achieve desired results, nor should the separation of various system components in the embodiments described in this patent document be understood as requiring such separation in all embodiments.

[0213] Only a few implementations and examples have been described; other implementations, extensions and variations may 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 whether a first coding tool is enabled for a first block of the image domain for a first transformation between a video domain of a video and a bitstream of the video based on a height and a width of the first block and a maximum transformation size of the video domain, and if the first coding tool is enabled, the first block is split into a plurality of transformation blocks; performing the first transformation based on the determination; having in response to at least one of the height or the width of the first block being greater than the maximum transform size, the first coding tool is not enabled for the first block; the first coding tool is a sub-block transform (SBT) tool; method.

2. The method of claim 1 , wherein whether or not a first syntax element indicating whether the first coding tool is enabled for the first block is included in the bitstream is based on the maximum transform size.

3. 3. The method of claim 1, wherein the first coding tool is enabled for the first block further based on the first block being coded in an inter prediction mode and not applying joint inter picture merge intra picture prediction.

4. 4. The method of claim 1, wherein, if the first coding tool is enabled, the first block is split into two transform blocks, one transform block having residual data and the other transform block having no residual data.

5. for a second block of the image region, a second coding tool is disabled in response to at least one of a height or a width of the second block being greater than N, where N is a positive integer; the second coding tool is in an intra block copy (IBC) mode; 5. The method according to any one of claims 1 to 4.

6. 6. The method of claim 5, wherein N=64.

7. 7. The method of claim 5 or 6, wherein in response to at least one of the height or the width of the second block being greater than N, a second syntax element indicating whether the second coding tool is enabled for the second block is excluded from the bitstream, and a value of the second syntax element is presumed to indicate that the second coding tool is not enabled for the second block.

8. for a third block of the image region, a third coding tool is disabled in response to at least one of a height or a width of the third block being greater than M, where M is a positive integer; the third coding tool is a palette prediction mode; 8. The method according to any one of claims 1 to 7.

9. 9. The method of claim 8, wherein M=64.

10. 10. The method of claim 8 or 9, wherein in response to at least one of the height or the width of the third block being greater than M, a third syntax element indicating whether the third coding tool is enabled for the third block is excluded from the bitstream, and a value of the third syntax element is presumed to indicate that the third coding tool is not enabled for the third block.

11. for a fourth block that is an intra-coding block, a fourth coding tool is disabled in response to at least one of a height or a width of the fourth block being greater than S, where S is a positive integer; The fourth coding tool is an intra sub-partition prediction mode.

11. The method according to any one of claims 1 to 10.

12. 12. The method of claim 11, wherein in response to at least one of the height or the width of the fourth block being greater than S, a fourth syntax element indicating whether the fourth coding tool is enabled for the fourth block and a fifth syntax element indicating whether a split type of the intra sub-partition prediction mode is horizontal or vertical are excluded from the bitstream, and a value of the fourth syntax element is presumed to indicate that the fourth coding tool is not enabled for the fourth block.

13. 13. The method of claim 11 or 12, wherein S=64.

14. for a fifth block of the image region, a fifth coding tool is disabled in response to at least one of a height or a width of the fifth block being greater than 64; The fifth coding tool is a combined intra-inter prediction (CIIP) mode.

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

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

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

17. 1. An apparatus for processing video data comprising a processor and a non-transitory memory having instructions that, when executed by the processor, cause the processor to: determining whether a first coding tool is enabled for a first block of the image domain for a first transformation between a video domain of a video and a bitstream of the video based on a height and a width of the first block and a maximum transformation size of the video domain, and if the first coding tool is enabled, the first block is split into a plurality of transformation blocks; performing the first transformation based on the determination; in response to at least one of the height or the width of the first block being greater than the maximum transform size, the first coding tool is not enabled for the first block; the first coding tool is a sub-block transform (SBT) tool; Device.

18. A non-transitory computer-readable storage medium having instructions stored thereon, the instructions causing a processor to: determining whether a first coding tool is enabled for a first block of the image domain for a first transformation between a video domain of a video and a bitstream of the video based on a height and a width of the first block and a maximum transformation size of the video domain, and if the first coding tool is enabled, the first block is split into a plurality of transformation blocks; performing the first transformation based on the determination; in response to at least one of the height or the width of the first block being greater than the maximum transform size, the first coding tool is not enabled for the first block; the first coding tool is a sub-block transform (SBT) tool; A computer-readable storage medium.

19. 1. A method for storing a video bitstream, comprising: determining, for an image region of the image, whether a first coding tool is enabled for a first block of the image region based on a height and a width of the first block and a maximum transform size of the image region, where if the first coding tool is enabled, the first block is split into a plurality of transform blocks; generating the bitstream based on the determination; storing the bitstream on a non-transitory computer readable recording medium; having in response to at least one of the height or the width of the first block being greater than the maximum transform size, the first coding tool is not enabled for the first block; the first coding tool is a sub-block transform (SBT) tool; method.

Images