Patent Description:
This document is related to video and image coding and decoding technologies.

Digital video accounts for the largest bandwidth use on the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, it is expected that the bandwidth demand for digital video usage will continue to grow. Non-patent literature <NPL> discloses a technique for coding large size CUs;.

Non-patent literature <NPL>discloses a technique related to partitioning structure selection;.

The disclosed techniques may be used by video or image decoder or encoder embodiments to performing coding or decoding of video in which the picture partition mode is determined based on block size.

In an example aspect a method of video processing is disclosed. The method includes using a dimension of a virtual pipeline data unit (VPDU) used for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video to perform a determination of whether a ternary-tree (TT) or a binary tree (BT) partitioning of a video block of the one or more video blocks is enabled, and performing, based on the determination, the conversion, wherein the dimension is equal to VSize in luma samples, wherein dimensions of the video block are CtbSizeY in luma samples, wherein VSize = min(M, CtbSizeY), and wherein M is a positive integer.

In another example aspect a method of video processing is disclosed. The method includes using, for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, a dimension of a video block of the one or more video blocks to perform a determination of whether a ternary-tree (TT) or a binary-tree (BT) partitioning of the video block is enabled, and performing, based on the determination, the conversion.

In yet another example aspect a method of video processing is disclosed. The method includes using a height or a width of a video block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video, and performing, based on the determination, the conversion, wherein the determination is based on a comparison between the height or the width with a value N, where N is a positive integer.

In yet another example aspect a method of video processing is disclosed. The method includes using comparison between a height or a width of a video block and a size of a transform block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video, and performing, based on the determination, the conversion.

In yet another example aspect a method of video processing is disclosed. The method includes using a height or a width of a video block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video, and performing, based on the determination, the conversion.

In yet another example aspect a method of video processing is disclosed. The method includes using a comparison between a dimension of a sub-partition of a video block and a maximum transform size to perform (a) a determination of whether an intra sub-partition prediction (ISP) mode is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block, and (b) a selection of one or more allowable partition types for the conversion, and performing, based on the determination and the selection, the conversion, wherein, in the ISP mode, a video block of the one or more video blocks is partitioned into multiple sub-partitions before application of an intra-prediction and transform.

In yet another example aspect a method of video processing is disclosed. The method includes performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion comprises a coding tool that has been disabled, and wherein syntax elements related to the coding tool are excluded from the bitstream representation and inferred to be a predetermined value specifying that the coding tool is disabled.

In yet another example aspect a method of video processing is disclosed. The method includes performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion comprises a coding tool that has been disabled, and wherein the bitstream representation comprises syntax elements related to the coding tool that are inferred to be a predetermined value based on the coding tool being disabled.

In yet another example aspect a method of video processing is disclosed. The method includes using a dimension of a virtual pipeline data unit (VPDU) and/or a maximum transform size used for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video to perform a determination of whether an implicit (QT) partitioning of a video block of the one or more video blocks is enabled, and performing, based on the determination, the conversion.

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

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

In yet another example aspect a method of video processing is disclosed. The method includes using a comparison between a height or a width of a video block and a maximum transform size to perform a determination of whether a combined inter intra prediction (CIIP) mode is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video, and performing, based on the determination, the conversion, 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.

In yet another example aspect a method of video processing is disclosed. The method includes making a determination, for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, regarding partitioning a video block of the one or more video blocks coded with combined inter intra prediction (CIIP), and performing, based on the determination, the conversion, 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.

In yet another example aspect a method of video processing is disclosed. The method includes performing a conversion between a video comprising a video region comprising multiple video blocks and a bitstream representation of the video according to a rule, wherein the rule specifies that a maximum block size of the multiple video blocks in the video region that are coded in the bitstream representation using a transform coding determines a maximum block size of the multiple video blocks in the video region that are coded in the bitstream representation without using transform coding.

In yet another example aspect a method of video processing is disclosed. The method includes performing a conversion between a video comprising a video region comprising multiple video blocks and a bitstream representation of the video according to a rule, wherein the rule specifies that a luma mapping with chroma scaling (LMCS) process is disabled for the video region when lossless coding is enabled for the video region, wherein the video region is 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, and wherein the LMCS process comprises luma samples of the video region being reshaped between a first domain and a second domain and a chroma residual being scaled in a luma-dependent manner.

In yet another example aspect, the above-described method may be implemented by a video encoder apparatus that comprises a processor.

In yet another example aspect, these methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.

These, and other, aspects are further described in the present document.

The present document provides various techniques that can be used by a decoder of image or video bitstreams to improve the quality of decompressed or decoded digital video or images. For brevity, the term "video" is used herein to include both a sequence of pictures (traditionally called video) and individual images. Furthermore, a video encoder may also implement these techniques during the process of encoding in order to reconstruct decoded frames used for further encoding.

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

This document is related to video coding technologies. Specifically, it is about rules for controlling size of coding tree unit or transform unit in video coding and decoding. It may be applied to the existing video coding standard like HEVC, or the standard (Versatile Video Coding) to be finalized. It may be also applicable to future video coding standards or video codec.

Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO/IEC standards. The ITU-T produced H. <NUM> and H. <NUM>, ISO/IEC produced MPEG-<NUM> and MPEG-<NUM> Visual, and the two organizations jointly produced the H. <NUM>/MPEG-<NUM> Video and H. <NUM>/MPEG-<NUM> Advanced Video Coding (AVC) and H. <NUM>/HEVC standards. <NUM>, the video coding standards are based on the hybrid video coding structure wherein temporal prediction plus transform coding are utilized. To explore the future video coding technologies beyond HEVC, Joint Video Exploration Team (JVET) was founded by VCEG and MPEG jointly in <NUM>. Since then, many new methods have been adopted by JVET and put into the reference software named Joint Exploration Model (JEM). The JVET meeting is concurrently held once every quarter, and the new coding standard is targeting at <NUM>% bitrate reduction as compared to HEVC. The new video coding standard was officially named as Versatile Video Coding (VVC) in the April <NUM> JVET meeting, and the first version of VVC test model (VTM) was released at that time. As there are continuous effort contributing to VVC standardization, new coding techniques are being adopted to the VVC standard in every JVET meeting. The VVC working draft and test model VTM are then updated after every meeting. The VVC project is now aiming for technical completion (FDIS) at the July <NUM> meeting.

VTM-<NUM> software allows <NUM> different CTU sizes: 16x16, 32x32, 64x64 and 128x128. However, at the July <NUM> JVET meeting, the minimum CTU size was redefined to 32x32 due to the adoption of JVET-O0526. And the CTU size in VVC working draft <NUM> is encoded in the SPS header in a UE-encoded syntax element called log2_ctu_size_minus_5.

Below are the corresponding spec modifications in VVC draft <NUM> with the definition of Virtual pipeline data units (VPDUs) and the adoption of JVET-O0526.

log2_ctu_size_minus5 plus <NUM> specifies the luma coding tree block size of each CTU. It is a requirement of bitstream conformance that the value of log2_ctu_size_minus5 be less than or equal to <NUM>. log2_min_luma_coding_block_size_minus2 plus <NUM> specifies the minimum luma coding block size. The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC and Vsize are derived as follows:
<IMG>.

The variables Ctb WidthC and CtbHeightC, which specify the width and height, respectively, of the array for each chroma CTB, are derived as follows:.

For log2BlockWidth ranging from <NUM> to <NUM> and for log2BlockHeight ranging from <NUM> to <NUM>, inclusive, the upright diagonal and raster scan order array initialization process as specified in clause <NUM>. <NUM> is invoked with <NUM> << log2BlockWidth and <NUM> << log2BlockHeight as inputs, and the output is assigned to.

slice_log2_diff_max_bt_min_qt_luma specifies the difference between the base <NUM> logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be split using a binary split and the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree splitting of a CTU in the current slice. The value of slice_log2_diff_max_bt_min_qt_luma shall be in the range of <NUM> to CtbLog2SizeY - MinQtLog2SizeY, inclusive. When not present, the value of slice_log2_diff_max_bt_min_qt_luma is inferred as follows:.

slice_log2_diff_max_tt_min_qt_luma specifies the difference between the base <NUM> logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be split using a ternary split and the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree splitting of a CTU in in the current slice. The value of slice log2_diff_max_tt_min_qt_luma shall be in the range of <NUM> to CtbLog2SizeY - MinQtLog2SizeY, inclusive. When not present, the value of slice_log2_diff_max_tt_min_qt_luma is inferred as follows:.

slice_log2_diff_min_qt_min_cb_chroma specifies the difference between the base <NUM> logarithm of the minimum size in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base <NUM> logarithm of the minimum coding block size in luma samples for chroma CUs with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice log2_diff_min_qt_min_cb_chroma shall be in the range of <NUM> to CtbLog2SizeY - MinCbLog2SizeY, inclusive. When not present, the value of slice_log2_diff_min_qt_min_cb_chroma is inferred to be equal to sps log2_diff_min_qt_min_cb_intra_slice_chroma.

slice_max_mtt_hierarchy_depth_chroma specifies the maximum hierarchy depth for coding units resulting from multi-type tree splitting of a quadtree leaf with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice_max_mtt_hierarchy_depth_chroma shall be in the range of <NUM> to CtbLog2SizeY - MinCbLog2SizeY, inclusive. When not present, the values of slice_max_mtt_hierarchy_depth_chroma is inferred to be equal to sps_max_mtt_hierarchy_depth_intra_slices_chroma.

slice_log2_diff_max_bt_min_qt_chroma specifies the difference between the base <NUM> logarithm of the maximum size (width or height) in luma samples of a chroma coding block that can be split using a binary split and the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with tree Type equal to DUAL_TREE_CHROMA in the current slice. The value of slice_log2_diff_max_bt_min_qt_chroma shall be in the range of <NUM> to CtbLog2SizeY - MinQtLog2SizeC, inclusive. When not present, the value of slice log2_diff_max_bt_min_qt_chroma is inferred to be equal to sps log2_diff_max_bt_min_qt_intra_slice_chroma.

slice_log2_diff_max_tt_min_qt_chroma specifies the difference between the base <NUM> logarithm of the maximum size (width or height) in luma samples of a chroma coding block that can be split using a ternary split and the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice_log2_diff_max_tt_min_qt_chroma shall be in the range of <NUM> to CtbLog2SizeY - MinQtLog2SizeC, inclusive. When not present, the value of slice_log2_diff_max_tt_min_qt_chroma is inferred to be equal to sps_log2_diff_max_tt_min_qt_intra_slice_chroma.

The variables MinQtLog2SizeY, MinQtLog2SizeC, MinQtSizeY, MinQtSizeC, MaxBtSizeY, MaxBtSizeC, MinBtSizeY, MaxTtSizeY, MaxTtSizeC, MinTtSizeY, MaxMttDepthY and MaxMttDepthC are derived as follows:
<IMG>.

In VVC Draft <NUM>, the max transform size is signalled in the SPS but it is fixed as <NUM>-length and not configurable. However, at the July <NUM> JVET meeting, it was decided to enable the max luma transform size to be either <NUM> or <NUM> only with a flag at the SPS level. Max chroma transform size is derived from the chroma sampling ratio relative to the max luma transform size.

Below are the corresponding spec modifications in VVC draft <NUM> with the adoption of JVET-O05xxx.

sps_max_luma_transform_size_64_flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>. sps_max_luma_transform_size_64_flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>.

When CtbSizeY is less than <NUM>, the value of sps_max_luma_transform_size_64 flag shall be equal to <NUM>. The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, and MaxTbSizeY are derived as follows:
<IMG>.

sps_sbt_max_size_64_flag equal to <NUM> specifies that the maximum CU width and height for allowing subblock transform is <NUM> luma samples. sps_sbt_max_size_64_flag equal to <NUM> specifies that the maximum CU width and height for allowing subblock transform is <NUM> luma samples.

There are several problems in the latest VVC working draft JVET-O2001-v11, which are described below.

The listing of solutions below should be considered as examples to explain some concepts. These items should not be interpreted in a narrow way. Furthermore, these items can be combined in any manner.

In this document, C=min(a,b) indicates that the C is equal to the minimum value between a and b.

In this document, the video unit size/dimension may be either the height or width of a video unit (e.g., width or height of a picture/sub-picture/slice/brick/tile/CTU/CU/CB/TU/TB). If a video unit size is denoted by MxN, then M denotes the width and N denotes the height of the video unit.

In this document, "a coding block" may be a luma coding block, and/or a chroma coding block. The size/dimension in luma samples for 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 indicate a 128x128 luma coding block, and/or a 64x64 chroma coding block for <NUM>:<NUM>:<NUM> color format. Similarly, for <NUM>:<NUM>:<NUM> color format, it may refer to a 128x128 luma coding block and/or a 64x128 chroma coding block. For <NUM>:<NUM>:<NUM> color format, it may refer to a 128x128 luma coding block and/or a 128x128 chroma coding block.

Newly added parts are enclosed in bolded double parentheses, e.g., {{a}} denotes that "a" has been added, whereas the deleted parts from VVC working draft are enclosed in bolded double brackets, e.g., [[b]] denotes that "b" has been deleted. The modifications are based on the latest VVC working draft (JVET-O2001-v11).

The embodiment below is for the invented method that making the maximum TU size dependent on the CTU size.

sps_max_luma_transform_size_64_flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>. sps_max_luma_transform_size_64_flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>.

When CtbSizeY is less than <NUM>, the value of sps_max_luma_transform_size_64_flag shall be equal to <NUM>.

The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, andMaxTbSizeY are derived as follows:
<IMG>.

The embodiment below is for the invented method that making the TT and BT split process dependent on the VPDU size.

The variable allowBtSplit is derived as follows:.

The variable allowTtSplit is derived as follows:.

The embodiment below is for the invented method that making the affine model parameters calculation dependent on the CTU size.

log2_ctu_size_minus5 plus <NUM> specifies the luma coding tree block size of each CTU. It is a requirement of bitstream conformance that the value of log2_ctu_size_minus5 be less than or equal to [[<NUM>]] {{<NUM> (could be larger per specified)}}.

CtbLog2SizeY = log2_ctu_size_minus5 + <NUM>.

{{CtbLog2SizeY is used to indicate the CTU size in luma sampales of current video unit. When a single CTU size is used for the current video unit, the CtbLog2SizeY is calculated by above equation. Otherwise, CtbLog2SizeY may depend on the actual CTU size which may be explicit signalled or implicit derived for the current video unit. (an example) }}.

The variables mvScaleHor, mvScaleVer, dHorX and dVerX are derived as follows:.

When availableFlagCorner[ <NUM> ] is equal to TRUE and availableFlagcorner[ <NUM> ] is equal to TRUE, the following applies:.

The variables mvScaleHor, mvscale Ver, dHorXand dVerX are derived as follows: <MAT> <MAT>.

As shown in <FIG>, TT split may be allowed for a coding block with block size 64x64, and BT split may be allowed for block sizes 32x64, 16x64, 8x64, 64x32, 64x16, 64x8, no matter the maximum transform size is 32x32 or 64x64.

<FIG> is an example of allowing BT and TT split depending on block size.

The modifications are based on the latest VVC working draft (JVET-O2001-v14).

intra_subpartitions_split_flag[ x0 ][ y0 ] specifies whether the intra subpartitions split type is horizontal or vertical. When intra_subpartitions_split_flag[ x0 ][ y0 ] is not present, it is inferred as follows:.

The embodiment below is for the invented method that making the ISP dependent on the VPDU size. The modifications are based on the latest VVC working draft (JVET-O2001-v14).

[[sps_sbt_max_size_64_flag equal to <NUM> specifies that the maximum CU width and height for allowing subblock transform is <NUM> luma samples. sps_sbt_max_size_64_flag equal to <NUM> specifies that the maximum CU width and height for allowing subblock transform is <NUM> luma samples.

[[log2_transform_skip_max_size_minus2 specifies the maximum block size used for transform skip, and shall be in the range of <NUM> to <NUM>.

When not present, the value of log2_transform_skip_max_size_minus2 is inferred to be equal to <NUM>.

The variable MaxTsSize is set equal to <NUM> << ( log2_transform_skip_max_size_minus2 + <NUM> ).

ciip_flag[ x0 ][ y0 ] specifies whether the combined inter-picture merge and intra-picture prediction is applied for the current coding unit. The array indices x0, y0 specify the location (x0, y0 J of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture.

When ciip_flag[ x0 ][ y0 ] is not present, it is inferred as follows:.

sps_max_luma_transform_size_64 flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>. sps_max_luma_transform_size_64_flag equal to <NUM> specifies that the maximum transform size in luma samples is equal to <NUM>.

When [[CtbSizeY is less than <NUM>,]] {{sps_max_luma_transform_size_64_flag is not present,}} the value of sps_max_luma_transform_size_64_flag [[shall]] {{is inferred to}} be equal to <NUM>.

The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, andMaxTbSizeY are derived as follows: <MAT> <MAT> <MAT> <MAT>.

<FIG> is a block diagram of a video processing apparatus <NUM>. The apparatus <NUM> may be used to implement one or more of the methods described herein. The apparatus <NUM> may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and so on. The apparatus <NUM> may include one or more processors <NUM>, one or more memories <NUM> and video processing hardware <NUM>. The processor(s) <NUM> may be configured to implement one or more methods described in the present document. The memory (memories) <NUM> may be used for storing data and code used for implementing the methods and techniques described herein. The video processing hardware <NUM> may be used to implement, in hardware circuitry, some techniques described in the present document. In some embodiments, the video processing hardware <NUM> may be at least partially within the processors <NUM> (e.g., a graphics coprocessor).

In some embodiments, the video coding methods may be implemented using an apparatus that is implemented on a hardware platform as described with respect to <FIG>.

Some embodiments of the disclosed technology include making a decision or determination to enable a video processing tool or mode. In an example, when the video processing tool or mode is enabled, the encoder will use or implement the tool or mode in the processing of a block of video, but may not necessarily modify the resulting bitstream based on the usage of the tool or mode. That is, a conversion from the block of video to the bitstream representation of the video will use the video processing tool or mode when it is enabled based on the decision or determination. In another example, when the video processing tool or mode is enabled, the decoder will process the bitstream with the knowledge that the bitstream has been modified based on the video processing tool or mode. That is, a conversion from the bitstream representation of the video to the block of video will be performed using the video processing tool or mode that was enabled based on the decision or determination.

Some embodiments of the disclosed technology include making a decision or determination to disable a video processing tool or mode. In an example, when the video processing tool or mode is disabled, the encoder will not use the tool or mode in the conversion of the block of video to the bitstream representation of the video. In another example, when the video processing tool or mode is disabled, the 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 or determination.

<FIG> is a block diagram showing an example video processing system <NUM> in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of the system <NUM>. The system <NUM> may include input <NUM> for receiving video content. The video content may be received in a raw or uncompressed format, e.g., <NUM> or <NUM> bit multi-component pixel values, or may be in a compressed or encoded format. The input <NUM> may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interface include wired interfaces such as Ethernet, passive optical network (PON), etc. and wireless interfaces such as Wi-Fi or cellular interfaces.

The system <NUM> may include a coding component <NUM> that may implement the various coding or encoding methods described in the present document. The coding component <NUM> may reduce the average bitrate of video from the input <NUM> to the output of the coding component <NUM> to produce a coded representation of the video. The coding techniques are therefore sometimes called video compression or video transcoding techniques. The output of the coding component <NUM> may be either stored, or transmitted via a communication connected, as represented by the component <NUM>. The stored or communicated bitstream (or coded) representation of the video received at the input <NUM> may be used by the component <NUM> for generating pixel values or displayable video that is sent to a display interface <NUM>. The process of generating user-viewable video from the bitstream representation is sometimes called video decompression. Furthermore, while certain video processing operations are referred to as "coding" operations or tools, it will be appreciated that the coding tools or operations are used at an encoder and corresponding decoding tools or operations that reverse the results of the coding will be performed by a decoder.

Examples of a peripheral bus interface or a display interface may include universal serial bus (USB) or high definition multimedia interface (HDMI) or Displayport, and so on. Examples of storage interfaces include SATA (serial advanced technology attachment), PCI, IDE interface, and the like. The techniques described in the present document may be embodied in various electronic devices such as mobile phones, laptops, smartphones or other devices that are capable of performing digital data processing and/or video display.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a dimension of a virtual pipeline data unit (VPDU) used for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video to perform a determination of whether a ternary-tree (TT) or a binary tree (BT) partitioning of a video block of the one or more video blocks is enabled, the dimension being equal to VSize in luma samples.

The method <NUM> includes, at operation <NUM>, performing, based on the determination, the conversion.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using, for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, a dimension of a video block of the one or more video blocks to perform a determination of whether a ternary-tree (TT) or a binary-tree (BT) partitioning of the video block is enabled.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a height or a width of a video block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video, the determination being based on a comparison between the height or the width with a value N, and N being a positive integer.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using comparison between a height or a width of a video block and a size of a transform block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a height or a width of a video block to perform a determination of whether a coding tool is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a comparison between a dimension of a sub-partition of a video block and a maximum transform size to perform (a) a determination of whether an intra sub-partition prediction (ISP) mode is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block, and (b) a selection of one or more allowable partition types for the conversion.

The method <NUM> includes, at operation <NUM>, performing, based on the determination and the selection, the conversion.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, the conversion comprising a coding tool that has been disabled, and syntax elements related to the coding tool being excluded from the bitstream representation and inferred to be a predetermined value specifying that the coding tool is disabled.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, the conversion comprising a coding tool that has been disabled, and the bitstream representation comprising syntax elements related to the coding tool that are inferred to be a predetermined value based on the coding tool being disabled.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a dimension of a virtual pipeline data unit (VPDU) and/or a maximum transform size used for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video to perform a determination of whether an implicit (QT) partitioning of a video block of the one or more video blocks is enabled.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, the conversion comprising a sub-block transform (SBT), and a maximum height or a maximum width of the SBT being based on a maximum transform size.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising one or more video regions comprising 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, and a maximum block size used for the transform skip mode being based on a maximum transform size.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, using a comparison between a height or a width of a video block and a maximum transform size to perform a determination of whether a combined inter intra prediction (CIIP) mode is enabled for a conversion between a video comprising one or more video regions comprising one or more video blocks comprising the video block and a bitstream representation of the video.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, making a determination, for a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, regarding partitioning a video block of the one or more video blocks coded with combined inter intra prediction (CIIP).

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising a video region comprising multiple video blocks and a bitstream representation of the video according to a rule, the rule specifying that a maximum block size of the multiple video blocks in the video region that are coded in the bitstream representation using a transform coding determines a maximum block size of the multiple video blocks in the video region that are coded in the bitstream representation without using transform coding.

<FIG> is a flowchart for a method <NUM> of video processing. The method <NUM> includes, at operation <NUM>, performing a conversion between a video comprising a video region comprising multiple video blocks and a bitstream representation of the video according to a rule, the rule 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, and 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.

In the methods <NUM>-<NUM>, in the ISP mode, a video block of the one or more video blocks is partitioned into multiple sub-partitions before application of an intra-prediction and transform.

In the methods <NUM>-<NUM>, the SBT comprises one or more transforms being separately applied to one or more partitions of a video block of the one or more video blocks.

In the methods <NUM>-<NUM>, the transform skip mode comprises 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 coding modulation operation.

In the methods <NUM>-<NUM>, 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.

In the methods <NUM>-<NUM>, the LMCS process comprises luma samples of the video region being reshaped between a first domain and a second domain and a chroma residual being scaled in a luma-dependent manner.

The disclosed and other solutions, examples, embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them.

This patent document contains many specifics which should be construed as descriptions of features that may be specific to particular embodiments of particular techniques. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment.

Claim 1:
A method of processing video data, comprising:
determining, for a conversion between a video region of a video and a bitstream of the video, whether a first coding tool is allowed or not for a first block of the video region, based on a height and a width of the first block and a maximum transform size of the video region, wherein in a case where the first coding tool is allowed, the first block is split into multiple transform blocks according to the first coding tool; and
performing the conversion based on the determining,
wherein 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 allowed for the first block;
wherein the first coding tool is a subblock transform (SBT) tool;
wherein for a second block of the video 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 <NUM>; and wherein the second coding tool is an intra block copy (IBC) mode.