Restrictions on partitioning structures

Abstract

Apparatus, systems, and methods for digital video encoding and decoding include determining whether a partition type associated with a partition tree is allowed or disallowed for a video block based at least in part on a virtual pipeline data unit (VPDU) size, wherein the VPDU size comprises a VPDU height and a VPDU width, and wherein, responsive to the partition type not being allowed, an indication of the partition type is absent in the bitstream.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of PCT / CN2019 / 076785, entitled “Restrictions on Segmentation Structures,” filed on March 2, 2019. The entire disclosure of the foregoing application is incorporated by reference as a part of the disclosure of this application for all purposes. Technical Field

[0003] This patent document relates to video encoding and decoding technology, equipment and systems. Background Art

[0004] Currently, efforts are underway to improve the performance of current video codec technologies to provide better compression ratios or to provide video encoding and decoding schemes that allow for less complex or parallel implementations. Several new video codec tools have recently been proposed by industry experts and are currently being tested to determine their effectiveness. Summary of the Invention

[0005] The present invention relates to digital video coding and, in particular, to devices, systems, and methods for deriving motion vectors. The methods described can be applied to existing video coding standards (e.g., high efficiency video coding (HEVC) or versatile video codec) as well as future video coding standards or video codecs.

[0006] In one representative aspect, the disclosed technology can be used to provide a method for video processing, the method comprising determining whether a partition type associated with a partition tree is allowed or disallowed for a video block based at least in part on a virtual pipeline data unit (VPDU) size, wherein the VPDU size comprises a VPDU height and a VPDU width, wherein, responsive to the partition type being disallowed, an indication of the partition type is absent from the bitstream.

[0007] In another representative aspect, the disclosed technology can be used to provide another method for video processing, the method comprising determining whether a partition type associated with a partition tree is allowed or not allowed for a video block based at least in part on a maximum allowed sub-block transform size, wherein the maximum allowed sub-block transform size comprises a maximum allowed sub-block transform height and a maximum allowed sub-block transform width, wherein responsive to the partition type not being allowed, an indication of the partition type is not present in the bitstream.

[0008] In another representative aspect, the disclosed technology can be used to provide a method for video processing, the method comprising determining whether a partition type associated with a partition tree is allowed or not allowed for a video block based at least in part on a maximum allowed transform size and a virtual pipeline data unit (VPDU) size, or based at least in part on a maximum allowed sub-block transform size and a virtual pipeline data unit (VPDU) size, wherein the VPDU size comprises a VPDU height and a VPDU width, wherein the maximum allowed transform size comprises a maximum allowed transform height and a maximum allowed transform width, and wherein, responsive to the partition type not being allowed, no indication of the partition type is present in the bitstream.

[0009] In another representative aspect, the disclosed technology can be used to provide a method for video processing, comprising: determining whether a sample is located at a sub-block transform boundary when a sub-block transform is applied; applying a deblocking filter process if the sample is determined to be located at the sub-block transform boundary; and performing conversion between a video and a bitstream representation of the video.

[0010] In another representative aspect, the disclosed technology can be used to provide a method for video processing, comprising: determining how to apply filtering to a video block based on whether a sub-block transform is applied; performing filtering based on the determination; and performing conversion between the video block and a bitstream representation of the video.

[0011] Furthermore, in one representative aspect, a video decoding apparatus is disclosed, comprising a processor configured to implement any one or more of the disclosed methods.

[0012] Furthermore, in one representative aspect, a video encoding apparatus is disclosed, comprising a processor configured to implement any one or more of the disclosed methods.

[0013] Furthermore, in one representative aspect, an apparatus in a video system is disclosed, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform any one or more of the disclosed methods.

[0014] Furthermore, a computer program product stored on a non-transitory computer-readable medium is disclosed, the computer program product comprising program code for performing any one or more of the disclosed methods.

[0015] The above and other aspects and features of the disclosed technology are described in more detail in the drawings, the description, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 An example of macroblock partitioning is shown.

[0017] Figure 2 An example of a pattern for dividing coding blocks (CB) into prediction blocks (PB) is shown.

[0018] Figure 3A An example of a coding tree block (CTB) and its partitioning is shown.

[0019] Figure 3B Shown with Figure 3A An example of a quadtree corresponding to the CTB in .

[0020] Figure 4A and Figure 4B A diagram combining a quadtree plus binary tree (QTBT) block structure is shown.

[0021] Figures 5A-5E Examples of segmentation types are shown.

[0022] Figure 6 An example of a sub-block transform mode is shown.

[0023] Figure 7 is a block diagram of an example of a hardware platform for implementing the visual media decoding or visual media encoding techniques described herein.

[0024] Figure 8 A flow chart illustrating an example method for video encoding and decoding is shown.

[0025] Figure 9 A flow chart illustrating an example method for video encoding and decoding is shown.

[0026] Figure 10 A flow chart illustrating an example method for video encoding and decoding is shown.

[0027] Figure 11 A flow chart illustrating an example method for video encoding and decoding is shown.

[0028] Figure 12 A flow chart illustrating an example method for video encoding and decoding is shown.

[0029] Figure 13 A flow chart illustrating an example method for video encoding and decoding is shown. DETAILED DESCRIPTION

[0030] 1. Video Codec in H.264 / AVC

[0031] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, ISO / IEC developed MPEG-1 and MPEG-4 Visual, and the two organizations jointly developed H.262 / MPEG-2 Video, H.264 / MPEG-4 Advanced Video Coding (AVC), and H.265 / HEVC. Since H.262, video codec standards have been based on a hybrid video codec architecture that utilizes temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and input them into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Experts Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) was created to work on the VVC standard with the goal of a 50% bitrate reduction compared to HEVC.

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

[0033] 2.1 Segmentation Tree Structure in H.264 / AVC

[0034] The terms used in H.264 / AVS are macroblock and MB mode / 8x8 mode (partitioning). A macroblock is the unit into which each picture / slice is divided and intra / inter mode decisions are applied. Partitioning defines the level at which motion information is signaled.

[0035] The codec layers in H.264 / AVC rely on macroblocks, which consist of a 16x16 block of luma samples and, in the typical case of 4:2:0 color sampling, two corresponding 8x8 blocks of chroma samples.

[0036] 2.1.1 H.264 / AVC Main Profile

[0037] In this profile, the intra codec block uses spatial prediction to exploit the spatial correlation between pixels. Two partitions are defined: 16×16 and 4×4.

[0038] Inter-frame codec blocks use temporal prediction instead of spatial prediction by estimating motion between pictures. Motion can be estimated independently for 16×16 macroblocks or any of their macroblock partitions: 16×8, 8×16, 8×8. A syntax element (MB-mode) is signaled to indicate whether 16×16, 16×8, 8×16 or 8×8 is selected. If 8×8 is selected, another syntax element (8×8-mode) is further signaled to indicate whether 8×8, 8×4, 4×8, 4×4 (e.g., Figure 1 Only one motion vector (MV) is allowed per segmentation.

[0039] Only 4×4 transforms are used.

[0040] 2.1.2 H.264 / AVC High Profile

[0041] In the high-level, 8×8 transform and I_8×8 (8×8 intra prediction) are introduced. For intra-frame codec macroblocks, the transform size is fixed. I_16×16 and I_4×4 use 4×4 transform; I_8×8 uses 8×8 transform.

[0042] For inter-coded macroblocks, a 4×4 or 8×8 transform can be selected. However, the transform size cannot exceed the partition size. For example, if a macroblock selects 8×8 partitioning and also selects 8×4 submode, only a 4×4 transform can be applied. If a macroblock selects 16×16, 16×8, 8×16, or 8×8 partitioning and 8×8 submode, a 4×4 or 8×8 transform can be selected.

[0043] 2.1.3 Summary

[0044] Mode selection is determined at the macroblock level. The transform size must not be larger than the partition size.

[0045] 2.2 Segmentation Tree Structure in HEVC

[0046] In HEVC, the coding tree unit (CTU) and the largest coding unit (LCU) are divided into coding units (CU) by using a quadtree structure represented as a codec tree to adapt to various local characteristics. A decision is made at the CU level whether to use inter-picture (temporal domain) or intra-picture (spatial domain) prediction to encode and decode the picture area. Depending on the PU partition type, each CU can be further divided into one, two or four PUs. Within a PU, the same prediction process is applied, and relevant information is transmitted to the decoder on a PU basis. After obtaining the residual block by applying the prediction process based on the PU partition type, the CU can be partitioned into transform units (TU) according to another quadtree structure similar to the codec tree of the CU. One of the important features of the HEVC structure is that it has a multi-partition concept, including CU, PU and TU.

[0047] In the following, various features involved in hybrid video coding using HEVC are highlighted as follows.

[0048] 1) Codec Tree Unit and Codec Tree Block (CTB) Structure: A similar structure in HEVC is the Codec Tree Unit (CTU), which has a size selected by the encoder and can be larger than a traditional macroblock. A CTU consists of a luma CTB and corresponding chroma CTBs and syntax elements. The size L×L of the luma CTB can be selected as L=16, 32, or 64 samples, where larger sizes generally enable better compression. HEVC then supports splitting the CTB into smaller blocks using a tree structure and signaling like a quadtree.

[0049] 2) Codec Unit (CU) and Codec Block (CB): The quadtree syntax of a CTU specifies the size and position of its luma and chroma CBs. The root of the quadtree is associated with the CTU. Therefore, the size of the luma CTB is the maximum supported size of the luma CB. The partitioning of the CTU into luma CBs and chroma CBs is signaled jointly. One luma CB and typically two chroma CBs, together with the associated syntax, form a codec unit (CU). A CTB may contain only one CU or may be partitioned to form multiple CUs, and each CU is associatedly partitioned into a tree of prediction units (PUs) and transform units (TUs).

[0050] 3) Prediction Unit (PU) and Prediction Block (PB): The decision to use inter-picture or intra-picture prediction to encode or decode a picture region is made at the CU level. The PU partitioning structure is rooted at the CU level. Depending on the basic prediction type decision, the luma and chroma CBs can be further split in size and predicted from the prediction blocks (PBs). HEVC supports variable PB sizes from 64×64 to 4×4 samples. Figure 2 The allowed PBs are shown.

[0051] 4) Transform Unit (TU) and Transform Block (TB): The prediction residual is encoded and decoded using block transform. The root of the TU tree structure is at the CU level. The luma CB residual can be the same as the luma transform block (TB), or can be further divided into smaller luma TBs. The same applies to chroma TBs. For square TBs of size 4×4, 8×8, 16×16, and 32×32, integer basis functions similar to the discrete cosine transform (DCT) are defined. For the 4×4 transform of the prediction residual within the luma picture, an integer transform derived from the form of the discrete sine transform (DST) is optionally specified.

[0052] 2.2.1 Depth of Quadtree

[0053] For a given luma CB of size M×M, a flag signals whether it is partitioned into four blocks of size M / 2×M / 2. If further partitioning is possible, as signaled by the maximum depth of the residual quadtree indicated in the SPS, each quadrant is assigned a flag indicating whether it is partitioned into four quadrants. The leaf blocks resulting from the residual quadtree are transform blocks that are further processed by the transform codec. The encoder indicates the maximum and minimum luma TB sizes it can use. When the CB size is larger than the maximum TB size, the partitioning is implicit. When the partitioning would result in the luma TB size being smaller than the indicated minimum, the non-partitioning is implicit. The chroma TB size is half the luma TB size in each dimension, except when the luma TB size is 4×4, in which case a single 4×4 chroma TB is used for the area covered by the four 4×4 luma TBs. In the case of an intra-picture predicted CU, the decoded samples of the nearest neighbor TB (inside or outside the CB) are used as reference data for intra-picture prediction.

[0054] 2.2.2 Summary

[0055] Based on the increasing quadtree depth, a CTU can be recursively divided into multiple CUs. Figure 3A and 3B As shown, only square CB and TB partitions are specified, where blocks can be recursively divided into quadrants.

[0056] Mode selection is determined at the CU level. Side information related to the selected mode (such as motion information and intra prediction mode) is signaled at the PU level. The residual is signaled at the TU level.

[0057] For inter-coded blocks, a PU shall not be larger than a CU, and for intra-coded blocks, a PU is equal to a CU.

[0058] For inter-coded blocks, TU can exceed PU, but for intra-coded blocks, TU is equal to PU.

[0059] 2.3 Quadtree plus binary tree block structure with larger CTU in JEM

[0060] To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and input them into reference software called the Joint Exploration Model (JEM).

[0061] 2.3.1 Quadtree plus Binary Tree (QTBT) Block Partitioning Structure

[0062] Unlike HEVC, the QTBT structure removes the concept of multiple partition types, that is, it removes the separation of CU, PU and TU concepts and supports greater flexibility in CU partition shape. In the QTBT block structure, CU can be square or rectangular. Figures 5A-5E As shown, the codec tree unit (CTU) is first partitioned by a quadtree structure. The quadtree leaf nodes are further partitioned by a binary tree structure. There are two types of partitioning in the binary tree partitioning, symmetrical horizontal partitioning and symmetrical vertical partitioning. The binary tree leaf nodes are called codec units (CUs), and this partitioning is used for the prediction and transform processes without any further partitioning. This means that in the QTBT codec block structure, CU, PU and TU have the same block size. In JEM, a CU sometimes includes codec blocks (CBs) of different color components, for example, in the case of P slices and B slices of a 4:2:0 chroma format, a CU contains one luminance CB and two chroma CBs, and a CU sometimes includes CBs of a single component, for example, in the case of an I slice, a CU contains only one luminance CB, or only two chroma CBs.

[0063] For the QTBT segmentation scheme, the following parameters are defined.

[0064] – CTU size: the size of the root node of the quadtree (e.g., the same concept as in HEVC)

[0065] –MinQTSize: Minimum allowed quadtree leaf node size

[0066] –MaxBTSize: Maximum allowed binary tree root node size

[0067] –MaxBTDepth: Maximum allowed binary tree depth

[0068] –MinBTSize: minimum allowed binary tree leaf node size

[0069] In one example of a QTBT partitioning structure, the CTU size is set to 128×128 luma samples with two corresponding 64×64 chroma sample blocks, MinQTSize is set to 16×16, MaxBTSize is set to 64×64, MinBTSize (for both width and height) is set to 4×4, and MaxBTDepth is set to 4. Quadtree partitioning is first applied to the CTU to generate quadtree leaf nodes. Quadtree leaf nodes can have sizes from 16×16 (i.e., MinQTSize) to 128×128 (i.e., CTU size). If a leaf quadtree node is 128×128, it will not be further partitioned by the binary tree because its size exceeds MaxBTSize (i.e., 64×64). Otherwise, the leaf quadtree node can be further partitioned by the binary tree. Therefore, the quadtree leaf node is also the root node of the binary tree, and its binary tree depth is 0. When the binary tree depth reaches MaxBTDepth (i.e., 4), no further partitioning is considered. When the width of a binary tree node is equal to MinBTSize (i.e., 4), no further horizontal splits are considered. Similarly, when the height of a binary tree node is equal to MinBTSize, no further vertical splits are considered. The leaf nodes of the binary tree are further processed through the prediction and transform processes without any further splitting. In JEM, the maximum CTU size is 256×256 luma samples.

[0070] Figure 4A shows an example of block segmentation using QTBT, and Figure 4B The corresponding tree representation is shown. Solid lines indicate quadtree partitioning, and dashed lines indicate binary tree partitioning. In each partition (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which partition type is used (i.e., horizontal or vertical), where 0 indicates horizontal partitioning and 1 indicates vertical partitioning. For quadtree partitioning, there is no need to indicate the partition type, because quadtree partitioning always divides the block horizontally and vertically to produce 4 equally sized sub-blocks.

[0071] In addition, the QTBT scheme supports the ability for luma and chroma to have separate QTBT structures. Currently, for P and B slices, the luma CTB and chroma CTB in one CTU share the same QTBT structure. However, for I slices, the luma CTB is split into CUs using the QTBT structure, and the chroma CTB is split into chroma CUs using another QTBT structure. This means that a CU in an I slice includes a codec block for the luma component or a codec block for two chroma components, and a CU in a P or B slice includes codec blocks for all three color components.

[0072] In HEVC, inter prediction for small blocks is restricted to reduce memory access for motion compensation, such as 4×8 and 8×4 blocks do not support bidirectional prediction, and 4×4 blocks do not support inter prediction. In JEM's QTBT, these restrictions are removed.

[0073] 2.3.2 Summary of QTBT

[0074] A CTU can be recursively partitioned into multiple CUs based on increasing depth of the quadtree or binary tree. Square and rectangular CBs (with width / height equal to 1 / 2 or 2) are specified.

[0075] Mode selection is determined at CU level. PU and TU are always equal to CU.

[0076] 2.4 VVC Multi-Type Tree

[0077] 2.4.1 Proposal

[0078] According to the proposal, tree types other than quadtree and binary tree are supported. Figure 5D and Figure 5E As shown, two other ternary tree (TT) partitions are introduced, namely horizontal and vertical center-side ternary trees.

[0079] There are two levels of trees, region tree (quadtree) and prediction tree (binary tree or ternary tree). The CTU is first split by the region tree (RT). The RT leaf can be further divided by the prediction tree (PT). The PT leaf can also be further divided by the PT until the maximum PT depth is reached. The PT leaf is the basic coding unit. For convenience, it is still called CU. The CU cannot be further divided. Prediction and transformation are applied to the CU in the same way as JEM. The entire segmentation structure is named "multi-type tree".

[0080] 2.4.2 Segmentation Tree in VVC

[0081] Several syntax elements are defined / signaled in VVC to indicate the use of different partitioning trees.

[0082] For example:

[0083] – Maximum multi-type tree depth maxMttDepth with offset,

[0084] – Maximum binary tree size maxBtSize

[0085] –MinBtSizeY

[0086] – Maximum binary tree size maxBtSize

[0087] – Maximum ternary tree size maxTtSize

[0088] 2.4.2.1 Restrictions on the use of BT and TT

[0089] 2.4.2.1.1 Variable Definition

[0090] log2_ctu_size_minus2 and log2_min_luma_coding_block_size_minus2 may be signaled in the SPS.

[0091] log2_ctu_size_minus2 plus 2 specifies the luma codec tree block size for each CTU.

[0092] log2_min_luma_coding_block_size_minus2 plus 2 specifies the minimum luma coding block size.

[0093] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, MaxTbSizeY, PicWidthInCtbsY, PicHeightInCtbsY, PicSizeInCtbsY, PicWidthInMinCbsY, PicHeightInMinCbsY, PicSizeInMinCbsY, PicSizeInSamplesY, PicWidthInSamplesC, and PicHeightInSamplesC are derived as follows:

[0094] CtbLog2SizeY=log2_ctu_size_minus2+2

[0095] CtbSizeY=1<<CtbLog2SizeY

[0096] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2

[0097] MinCbSizeY=1<<MinCbLog2SizeY

[0098] MinTbLog2SizeY=2

[0099] MaxTbLog2SizeY=6

[0100] MinTbSizeY=1<<MinTbLog2SizeY

[0101] MaxTbSizeY=1<<MaxTbLog2SizeY

[0102] PicWidthInCtbsY=Ceil(pic_width_in_luma_samples÷CtbSizeY)

[0103] PicHeightInCtbsY=Ceil(pic_height_in_luma_samples÷CtbSizeY)

[0104] PicSizeInCtbsY=PicWidthInCtbsY*PicHeightInCtbsY

[0105] PicWidthInMinCbsY=pic_width_in_luma_samples / MinCbSizeY

[0106] PicHeightInMinCbsY=pic_height_in_luma_samples / MinCbSizeY

[0107] PicSizeInMinCbsY=PicWidthInMinCbsY*PicHeightInMinCbsY

[0108] PicSizeInSamplesY=pic_width_in_luma_samples*pic_height_in_luma_samples

[0109] PicWidthInSamplesC=pic_width_in_luma_samples / SubWidthC

[0110] PicHeightInSamplesC=pic_height_in_luma_samples / SubHeightC

[0111] 2.4.2.1.2 Allowable binary partitioning processes

[0112] The inputs to this process are:

[0113] –Binary split mode btSplit,

[0114] – Codec block width cbWidth,

[0115] – Codec block height cbHeight,

[0116] – the position of the upper left corner luma sample of the considered codec block relative to the upper left corner luma sample of the picture (x0, y0),

[0117] –Multi-type tree depth mttDepth,

[0118] – Maximum multi-type tree depth maxMttDepth with offset,

[0119] – Maximum binary tree size maxBtSize,

[0120] – Partition index partIdx.

[0121] The output of this process is the variable allowBtSplit.

[0122] Table 1 shows the specifications of parallelTtSplit and cbSize based on btSplit.

[0123]

[0124] The variables parallelTtSplit and cbSize are derived as specified in Table 1.

[0125] For different embodiments, the variable allowBtSplit (e.g., a split variable that takes a Boolean true or false value) can be based on or according to different conditions. Using these conditions, the value of the variable can be derived as follows:

[0126] – allowBtSplit is set equal to FALSE if one or more of the following conditions are true:

[0127] / / According to the allowed BT block size and the maximum allowed MTT depth conditions

[0128] –cbSize is less than or equal to MinBtSizeY

[0129] –cbWidth is greater than maxBtSize

[0130] –cbHeight is greater than maxBtSize

[0131] –mttDepth is greater than or equal to maxMttDepth

[0132] – Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE

[0133] / / According to the picture boundary (there is no vertical BT at the bottom picture boundary and the bottom right picture boundary) condition

[0134] –btSplit equals SPLIT_BT_VER

[0135] –y0+cbHeight is greater than pic_height_in_luma_samples

[0136] – Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE

[0137] / / According to the picture boundary (there is no horizontal BT at the bottom right picture boundary) condition

[0138] –btSplit is equal to SPLIT_BT_HOR

[0139] –x0+cbWidth is greater than pic_width_in_luma_samples

[0140] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[0141] – Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE:

[0142] / / Determine the TT split index 1 (middle split) based on the parent TT split direction (for example, for vertical TT, there is no vertical BT in the middle split; for horizontal TT, there is no horizontal BT in the middle split)

[0143] –mttDepth is greater than 0

[0144] –partIdx is equal to 1

[0145] –MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[0146] – Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE

[0147] / / According to the maximum allowed transform size (for example, when MaxTbSizeY is equal to 64, for 64×128, there is no vertical BT; for 128×64, there is no horizontal BT) condition

[0148] –btSplit equals SPLIT_BT_VER

[0149] –cbWidth is less than or equal to MaxTbSizeY

[0150] –cbHeight is greater than MaxTbSizeY

[0151] – Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE

[0152] –btSplit is equal to SPLIT_BT_HOR

[0153] –cbWidth is greater than MaxTbSizeY

[0154] –cbHeight is less than or equal to MaxTbSizeY

[0155] – Otherwise, allowBtSplit is set equal to TRUE.

[0156] 2.4.2.1.3 Allowable ternary partitioning process

[0157] The inputs to this process are:

[0158] – ternary split mode ttSplit,

[0159] – Codec block width cbWidth,

[0160] – Codec block height cbHeight,

[0161] – the position of the upper left corner luma sample of the considered codec block relative to the upper left corner luma sample of the picture (x0, y0),

[0162] –Multi-type tree depth mttDepth,

[0163] – Maximum multi-type tree depth maxMttDepth with offset,

[0164] – Maximum binary tree size maxTtSize.

[0165] The output of this process is a partition variable allowTtSplit (e.g., it takes a Boolean true or false value). The value of the partition variable allowTtSplit can be based on or based on different conditions. Using these conditions, the value of this variable can be derived as follows:

[0166] Table 2 Specification of cbSize based on ttSplit

[0167]

[0168] The variable cbSize is derived as specified in Table 2.

[0169] The variable allowTtSplit is derived as follows:

[0170] – allowTtSplit is set equal to FALSE if one or more of the following conditions are true:

[0171] / / According to the allowed TT block size and the maximum allowed transform size conditions

[0172] –cbsize is less than or equal to 2*MinTtSizeY

[0173] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0174] –cbheight is greater than Min(MaxTbSizeY, maxTtSize)

[0175] / / According to the maximum allowed MTT depth condition

[0176] –mttDepth is greater than or equal to maxMttDepth

[0177] / / According to whether it is at the boundary condition of the picture

[0178] –x0+cbWidth is greater than pic_width_in_luma_samples

[0179] –y0+cbHeight is greater than pic_height_in_luma_samples

[0180] – Otherwise, allowTtSplit is set equal to TRUE.

[0181] 2.4.2.1.4 Semantics

[0182] VVC specification subclause 7.4.5.5 Multi-type tree semantics

[0183] The variables allowSplitBtVer, allowSpliBtHor, allowSplitTtVer, and allowSplitTtHor are derived as follows:

[0184] – The variables maxBtSize, maxTtSize and maxMttDepth are derived as follows:

[0185] – If treeType is equal to DUAL_TREE_CHROMA, maxBtSize, maxTtSize, and maxMttDepth are set equal to MaxBtSizeC, MaxTtSizeC, and MaxMttDepthC+depthOffset, respectively.

[0186] Otherwise, maxBtSize, maxTtSize, and maxMttDepth are set equal to MaxBtSizeY, MaxTtSizeY, and MaxMttDepthY + depthOffset, respectively.

[0187] – As specified in clause 2.4.2.1.1, the allowed binary split process is called with the binary split mode SPLIT_BT_VER, the codec block width cbWidth, the codec block height cbHeight, the position (x0, y0), the current multi-type tree depth mttDepth, the maximum multi-type tree depth maxMttDepth with offset, the maximum binary tree size maxBtSize and the current split index partIdx as input, and the output is assigned to allowSplitBtVer.

[0188] – As specified in clause 2.4.2.1.1, the allowed binary split process is called with binary split mode SPLIT_BT_HOR, codec block height cbHeight, codec block width cbWidth, position (x0, y0), current multi-type tree depth mttDepth, maximum multi-type tree depth maxMttDepth with offset, maximum binary tree size maxBtSize and current split index partIdx as input, and the output is assigned to allowSplitBtHor.

[0189] – As specified in clause 2.4.2.1.3, the allowed ternary splitting process is called with the ternary splitting mode SPLIT_TT_VER, the codec block width cbWidth, the codec block height cbHeight, the position (x0, y0), the current multi-type tree depth mttDepth, the maximum multi-type tree depth maxMttDepth with offset and the maximum ternary tree size maxTtSize as input, and assigns the output to allowSplitTtVer.

[0190] – As specified in clause 2.4.2.1.3, the allowed ternary splitting process is called with the ternary splitting mode SPLIT_TT_HOR, the codec block height cbHeight, the codec block width cbWidth, the position (x0, y0), the current multi-type tree depth mttDepth, the maximum multi-type tree depth maxMttDepth with offset and the maximum ternary tree size maxTtSize as input, and assigns the output to allowSplitTtHor.

[0191] 2.4.3. Sub-block Transform

[0192] For inter-prediction CUs with cu_cbf equal to 1, cu_sbt_flag can be signaled to indicate whether to decode the entire residual block or a sub-part of the residual block. In the former case, the inter-frame multiple transform selection (MTS, also known as EMT) information is further parsed to determine the transform type of the CU. In the latter case, a portion of the residual block is coded and decoded using the inferred adaptive transform, and the other portion of the residual block is cleared to zero.

[0193] 2.4.3.1. Sub-block TU splicing

[0194] When SBT is used for inter CU, SBT type and SBT location information are further decoded from the bitstream. Figure 6 As shown, there are two SBT types and two SBT positions. For SBT-V (or SBT-H), the TU width (or height) can be equal to half of the CU width (or height) or 1 / 4 of the CU width (or height), signaled by another flag, resulting in 2:2 partitioning or 1:3 / 3:1 partitioning. The 2:2 partitioning is similar to the binary tree (BT) partitioning, while the 1:3 / 3:1 partitioning is similar to the asymmetric binary tree (ABT) partitioning. If one side of the CU in the luma samples is 8, 1:3 / 3:1 partitioning is not allowed along that side. Therefore, there are up to 8 SBT modes for a CU.

[0195] SBT-V and SBT-H are allowed for CUs whose width and height are both no larger than maxSbtSize. maxSbtSize is signaled in the SPS. For HD and 4K sequences, the encoder sets maxSbtSize to 64; for other smaller resolution sequences, maxSbtSize is set to 32.

[0196] 2.5. Sub-block Transform Type

[0197] In JVET-M0140, position-dependent transforms are applied to luma transform blocks in SBT-V and SBT-H (chroma TBs always use DCT-2). The two positions of SBT-H and SBT-V are associated with different core transforms. More specifically, Figure 1 The horizontal and vertical transforms for each SBT position are specified in . For example, the horizontal and vertical transforms for SBT-V position 0 are DCT-8 and DST-7, respectively. When one side of the residual TU is larger than 32, the corresponding transform is set to DCT-2. Therefore, the sub-block transform jointly specifies the TU splicing, cbf, and horizontal and vertical transforms of the residual block, which can be considered a syntactic shortcut for the case where the main residual part of the block is on one side of the block.

[0198] For inter-frame blocks, the summary from the SBT adoption section is:

[0199] -1-d division (symmetrical or 1 / 4)

[0200] - If symmetric, signal which half; otherwise use 1 / 4

[0201] - The transform type of the inferred residual TU

[0202] 3. Question

[0203] The current design of the split tree limit is based on the assumption of full block transformation and universal test conditions. It may have the following problems:

[0204] i. Whether partitioning is enabled or disabled according to a partitioning structure depends on the maximum allowed transform size. The motivation for enabling / disabling a partitioning structure is mainly due to hardware implementation considerations, i.e. larger blocks (such as 128×128) are difficult to implement. In Versatile Video Codec (VVC), the concept of VPDU (virtual pipeline data unit) is used, in which the maximum allowed block for motion compensation is defined. Under currently common test conditions, the VPDU size is equal to the maximum allowed transform size. However, the maximum allowed transform size is adaptively signaled in high-level syntax elements (such as sequence parameters).

[0205] ii. Assuming the maximum allowed transform size is 64×64, vertical BT is not allowed if a codec block is 64×128. However, due to the adoption of sub-block transform, vertical BT can still be applied when the sub-block transform size is set to 32×64.

[0206] iii. How to handle the boundaries of blocks encoded with sub-block transform has not been solved in the art.

[0207] 4. Example Techniques and Embodiments

[0208] The detailed embodiments described below should be considered as examples for explaining the general concept. These embodiments should not be interpreted narrowly. In addition, these embodiments can be combined in any way.

[0209] 1. Instead of using the maximum allowed transform size, it is proposed that whether a partition tree is allowed can depend on the VPDU size.

[0210] a. In one example, if the block width is not greater than the VPDU width and the block height is greater than the VPDU height, vertical BT is not allowed.

[0211] b. In one example, if the block width is greater than the VPDU width and the block height is not greater than the VPDU height, horizontal BT is not allowed.

[0212] c. Similarly, for TT partitioning, it may not be allowed if one (or some\or all) of the following conditions are true:

[0213] –cbSize is less than or equal to 2*MinTtSizeY

[0214] –cbWidth is greater than Min(VPDUSizeX, maxTtSize)

[0215] –cbHeight is greater than Min(VPDUSizeY, maxTtSize)

[0216] Where MinTtSizeY and maxTtSize represent the minimum and maximum allowed TT sizes respectively; cbWidth and cbHeight represent the width and height of the codec block respectively; VPDUSizeX and VPDUSizeY represent the width and height of the VPDU respectively.

[0217] d. In one example, the VPDU height is equal to the VPDU width.

[0218] i. In one example, only one of the VPDU height and width is signaled from the encoder to the decoder. The other is set equal to the signaled one.

[0219] ii. In an alternative example, the VPDU height may not be equal to the VPDU width.

[0220] a) In one example, both the height and width of the VPDU are signaled from the encoder to the decoder.

[0221] 2. Instead of using the maximum allowed transform size, it is proposed that whether a partition tree is allowed may depend on the maximum allowed sub-block transform size of the partition tree.

[0222] a. In one example, vertical BT may be allowed even if the block width is not larger than the maximum allowed transform width and the block height is larger than the maximum allowed transform height.

[0223] i. Alternatively, furthermore, sub-block transform may be applied to the above case, ie, transform is applied to a portion of a sub-block resulting from vertical BT.

[0224] ii. In one example, if the block width is not larger than the maximum allowed transform width and the block height is larger than the maximum allowed transform height, but the sub-blocks resulting from the vertical BT partition support at least one sub-block transform size, vertical BT may be allowed.

[0225] iii. In one example, vertical BT may be allowed if the block width is not greater than the maximum allowed transform width and the block height is greater than the maximum allowed transform height, but the block height is not greater than the maximum allowed sub-block transform height.

[0226] iv. Alternatively, furthermore, if the block width is not larger than the maximum allowed sub-block transform width, and the block height is larger than the maximum allowed sub-block transform height, vertical BT may not be allowed.

[0227] a) In one example, the specified maximum allowed sub-block transform width / height is for vertical BT (V-BT).

[0228] v. In one example, the maximum allowed sub-block transform width of V-BT may be defined as half or one quarter of the maximum allowed transform width.

[0229] vi. In one example, the maximum allowed sub-block transform height for V-BT may be defined as half or one quarter of the maximum allowed transform height, or larger than the maximum allowed transform height.

[0230] b. In one example, horizontal BT may be allowed even if the block width is larger than the maximum allowed transform width and the block height is not larger than the maximum allowed transform height.

[0231] i. Alternatively, furthermore, sub-block transform may be applied to the above case, ie, the transform is applied to a portion of the sub-block resulting from vertical BT.

[0232] ii. Alternatively, furthermore, if the block width is larger than the maximum allowed sub-block transform width and the block height is not larger than the maximum allowed sub-block transform height, then horizontal BT is not allowed.

[0233] a) In one example, the specified maximum allowed sub-block transform width / height is for horizontal BT (H-BT).

[0234] iii. In one example, the maximum allowed sub-block transform width for V-BT may be defined as half or one quarter of the maximum allowed transform width.

[0235] iv. In one example, the maximum allowed sub-block transform height for V-BT may be defined as half or one quarter of the maximum allowed transform height.

[0236] c. In one example, set Tx=maximum{maximum allowed transform width, maximum allowed sub-block width}, Ty=maximum{maximum allowed transform height, maximum allowed sub-block height}, and then propose whether to allow splitting can depend on Tx and / or Ty.

[0237] i. In one example, if the block width is not greater than Tx and the block height is greater than Ty, vertical BT may not be allowed.

[0238] ii. If the block width is greater than Tx and the block height is not greater than Ty, horizontal BT is not allowed.

[0239] d. Alternatively, furthermore, when the sub-block transform technique is enabled, such as when the SPS flag is true, such a method may be applied.

[0240] 3. Whether a partition tree is allowed may depend on both the VPDU size and the maximum allowed sub-block transform size.

[0241] a. Alternatively, whether a partition tree is allowed may depend on both the VPDU size and the maximum allowed sub-block transform size.

[0242] b. In one example, if the block width is not greater than f(VPDU width, maximum allowed transform width), and the block height is greater than f(VPDU height, maximum allowed transform height), vertical BT is not allowed.

[0243] c. In one example, if the block width is greater than f(VPDU width, maximum allowed transform width), and the block height is not greater than f(VPDU height, maximum allowed transform height), horizontal BT is not allowed.

[0244] d. In one example, the function f(x, y) returns the larger of x and y.

[0245] e. In one example, the function f(x, y) returns the smaller of x and y.

[0246] f. In one example, the VPDU height is equal to the VPDU width.

[0247] g. In one example, the maximum allowed transform width is equal to the maximum allowed transform height.

[0248] 4. The above VPDU size (including width and height) can be pre-defined, for example, 64×64.

[0249] a. Alternatively, it can be signaled in SPS / VPS / PPS / sequence header / picture header / slice group header / slice header / CTU row / region / other types of video processing data units.

[0250] 5. It is proposed that how filtering processes, such as deblocking filtering, SAO and / or ALF, are applied may depend on the sub-block transform size.

[0251] a. In one example, boundaries of sub-block transforms can be filtered in a deblocking filtering process.

[0252] b. In one example, the decision of deblocking filtering (such as whether to filter or not, strong filter or weak filter, or which filter or how to apply clipping to the filtered samples) may depend on whether the sample is located at a sub-block transform boundary.

[0253] 5. Additional Example Embodiments

[0254] 5.1.1.1.1 Allowable binary partitioning processes

[0255] Inputs to the process:

[0256] –Binary split mode btSplit,

[0257] – Codec block width cbWidth,

[0258] – Codec block height cbHeight,

[0259] – the position of the upper left corner luma sample of the considered codec block relative to the upper left corner luma sample of the picture (x0, y0),

[0260] –Multi-type tree depth mttDepth,

[0261] – Maximum multi-type tree depth maxMttDepth with offset,

[0262] – Maximum binary tree size maxBtSize,

[0263] – Partition index partIdx.

[0264] The output of this process is the variable allowBtSplit (eg, a Boolean variable that takes on the value true or false).

[0265] Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE:

[0266] –btSplit equals SPLIT_BT_VER

[0267] –cbWidth is less than or equal to VPDUSizeY

[0268] –cbHeight is greater than VPDUSizeY

[0269] Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE

[0270] –btSplit is equal to SPLIT_BT_HOR

[0271] –cbWidth is greater than VPDUSizeY

[0272] –cbHeight is less than or equal to VPDUSizeY

[0273] 5.1.1.1.2 Allowable ternary partitioning processes

[0274] The inputs to this process are:

[0275] – ternary split mode ttSplit,

[0276] – Codec block width cbWidth,

[0277] – Codec block height cbHeight,

[0278] – the position of the upper left corner luma sample of the considered codec block relative to the upper left corner luma sample of the picture (x0, y0),

[0279] –Multi-type tree depth mttDepth

[0280] – Maximum multi-type tree depth maxMttDepth with offset,

[0281] – Maximum binary tree size maxTtSize.

[0282] The output of this procedure is the variable allowTtSplit.

[0283] Table 3 Specification of cbSize based on ttSplit

[0284]

[0285]

[0286] The variable cbSize may be derived based on the information specified in Table 3.

[0287] The variable allowTtSplit can be derived based on or according to various conditions:

[0288] – allowTtSplit is set equal to FALSE if one or more of the following conditions are true:

[0289] / / According to the allowed TT block size and the maximum allowed transform size conditions

[0290] –cbSize is less than or equal to 2*MinTtSizeY

[0291] –cbWidth is greater than Min(VPDUSizeX, maxTtSize)

[0292] –cbHeight is greater than Min(VPDUSizeY, maxTtSize)

[0293] / / According to the maximum allowed MTT depth condition

[0294] –mttDepth is greater than or equal to maxMttDepth

[0295] / / According to whether it is at the boundary condition of the picture

[0296] –x0+cbWidth is greater than pic_width_in_luma_samples

[0297] –y0+cbHeight is greater than pic_height_in_luma_samples

[0298] – Otherwise, allowTtSplit is set equal to TRUE.

[0299] 6. Example Implementations of the Disclosed Technology

[0300] Figure 77 is a block diagram of a video processing device 700. The device 700 can be used to implement one or more methods described herein. The device 700 can be embodied in a smartphone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. The device 700 may include one or more processors 702, one or more memories 704, and video processing hardware 706. The processor(s) 702 can be configured to implement one or more methods described herein. The memory(s) 704 can be used to store data and code for implementing the methods and techniques described herein. The video processing hardware 706 can be used to implement some of the techniques described herein in a hardware circuit system and can be partially or completely part of the processor 702 (e.g., a graphics processor core GPU or other signal processing circuit system).

[0301] As used herein, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to, for example, co-located or distributed bits in the bitstream, as defined by the syntax. For example, a macroblock may be encoded based on a post-transform and post-encoding error residual value, and may also be encoded using bits in the header and other fields in the bitstream.

[0302] It will be appreciated that the disclosed methods and techniques will benefit video encoder and / or decoder embodiments included in video processing devices, such as smartphones, laptops, desktops, and similar devices, by enabling use of the techniques disclosed herein.

[0303] Figure 8 8 is a flow chart of an example method 800 for video processing. The method 800 includes, at 810, calculating (based at least in part on the size of a virtual pipeline data unit (VPDU) and one or more parameters of a partitioning tree) a value of a partitioning variable associated with a video block for use in converting between a video block of visual media data and a corresponding bitstream of the video block, wherein the size of the VPDU includes a height and a width. The method 800 also includes, at 820, in response to determining that the value of the partitioning variable is Boolean true, allowing the video block to be partitioned according to the partitioning tree. The method 800 also includes, at 830, in response to determining that the value of the partitioning variable is Boolean false, not allowing the video block to be partitioned. The term video block as used herein may apply to any form of media block, including (but not limited to) codec blocks, prediction blocks, macroblocks, etc. Furthermore, in various embodiments, these blocks may be intra blocks or inter blocks.

[0304] Figure 9is a flow chart of an example method 900 for video processing. The method 900 includes, at 910, determining whether a partition type associated with a partition tree is allowed or disallowed for a video block based at least in part on a virtual pipeline data unit (VPDU) size, wherein the VPDU size includes a VPDU height and a VPDU width, wherein, responsive to the partition type not being allowed, an indication of the partition type is not present in the bitstream.

[0305] Figure 10 is a flow chart of an example method 1000 of video processing. The method 1000 includes, at 1010, determining whether a partition type associated with a partition tree is allowed or not allowed for a video block based at least in part on a maximum allowed sub-block transform size, wherein the maximum allowed sub-block transform size includes a maximum allowed sub-block transform height and a maximum allowed sub-block transform width, wherein, responsive to the partition type being not allowed, an indication of the partition type is not present in the bitstream.

[0306] Figure 11 is a flow chart of an example method 1100 of video processing. The method 1100 includes, at 1110, determining whether a partition type associated with a partition tree is allowed or not allowed for a video block based at least in part on a maximum allowed transform size and a virtual pipeline data unit (VPDU) size, or based at least in part on a maximum allowed sub-block transform size and a virtual pipeline data unit (VPDU) size, wherein the VPDU size includes a VPDU height and a VPDU width, wherein the maximum allowed transform size includes a maximum allowed transform height and a maximum allowed transform width, wherein, responsive to the partition type not being allowed, an indication of the partition type is not present in the bitstream.

[0307] Figure 12 12 is a flow chart of an example method 1200 for video processing. The method 1200 includes, at 1210, determining whether a sample is located at a sub-block transform boundary if a sub-block transform is applied; at 1220, applying a deblocking filter process if the sample is determined to be located at a sub-block transform boundary; and at 1230, performing conversion between a video and a bitstream representation of the video.

[0308] Figure 13 13 is a flow chart of an example method 1300 for video processing. The method 1300 includes, at 1310, determining how to apply filtering to a video block based on whether a sub-block transform is applied; at 1320, performing filtering based on the determination; and at 1330, performing conversion between the video block and a bitstream representation of the video.

[0309] Some embodiments may be described using the following clause-based format.

[0310] 1. A video processing method, comprising:

[0311] determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a virtual pipeline data unit (VPDU) size, wherein the VPDU size includes a VPDU height and a VPDU width,

[0312] In response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream.

[0313] 2. The method of clause 1, wherein the partition tree comprises a vertical binary tree, a horizontal binary tree, or a ternary tree.

[0314] 3. The method of clause 2, wherein if the width of the video block is not greater than the VPDU width and the height of the video block is greater than the height of the VPDU, then vertical binary trees are not allowed.

[0315] 4. The method of clause 2, wherein if the width of the video block is greater than the VPDU width and the height of the video block is not greater than the VPDU height, then the horizontal binary tree is not allowed.

[0316] 5. The method of clause 2, wherein a ternary tree is not allowed if at least one of the following conditions is true: (1) the size of the video block is less than or equal to 2*MinTtSizeY, (2) the width of the video block is greater than Min(VPDUSizeX, maxTtSize), and (3) the height of the video block is greater than Min(VPDUSizeY, maxTtSize), where MinTtSizeY and maxTtSize represent the minimum and maximum allowed sizes of the ternary tree, and VPDUSizeX and VPDUSizeY represent the width and height of the VPDU.

[0317] 6. A method according to any of clauses 1-5, wherein the height and VPDU width are equal.

[0318] 7. A method according to clause 6, wherein one of the height or width is signalled from the encoder to the decoder, and wherein the other of the height or width which is not signalled is set equal to the signalled height or width.

[0319] 8. A method according to any of clauses 1-5, wherein the height and the VPDU width are not equal.

[0320] 9. A method according to clause 8, wherein both the height and the VPDU width are signalled from the encoder to the decoder.

[0321] 10. The method according to any of clauses 1-9, wherein the VPDU size is predefined.

[0322] 11. The method of clause 10, wherein the VPDU size is 64x64.

[0323] 12. A method according to any of clauses 1-9, wherein the VPDU size is signaled in at least one of a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a picture header, a slice group header, a slice header, a codec tree unit row or a region associated with a codec tree unit.

[0324] 13. A video processing method, comprising:

[0325] determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a maximum allowed sub-block transform size, wherein the maximum allowed sub-block transform size comprises a maximum allowed sub-block transform height and a maximum allowed sub-block transform width,

[0326] In response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream.

[0327] 14. The method of clause 13, wherein the partition tree comprises a vertical binary tree or a horizontal binary tree.

[0328] 15. The method of clause 14, wherein vertical binary trees are allowed if the width of the video block is not greater than a maximum allowed transform width and the height of the video block is greater than a maximum allowed transform height.

[0329] 16. The method according to clause 15, further comprising:

[0330] The sub-block transform is applied to the portion of the sub-block resulting from the vertical binary tree.

[0331] 17. The method of clause 14, wherein vertical binary trees are allowed if the width of the video block is not greater than a maximum allowed transform width and the height of the video block is greater than a maximum allowed transform height, and the sub-blocks resulting from the vertical binary tree support at least one sub-block transform size.

[0332] 18. The method of clause 14, wherein vertical binary trees are allowed if the width of the video block is not greater than the maximum allowed transform width, and the height of the video block is greater than the maximum allowed transform height, and the block height is not greater than the maximum allowed sub-block transform height.

[0333] 19. The method of clause 14, wherein if the width of the video block is not greater than a maximum allowed sub-block transform width and the height of the video block is greater than a maximum allowed sub-block transform height, then vertical binary trees are not allowed.

[0334] 20. The method of clause 19, wherein the maximum allowed sub-block transform width and height are associated with the vertical binary tree.

[0335] 21. The method of clause 20, wherein the maximum allowed sub-block transform width of the vertical binary tree is equal to half the maximum allowed transform width.

[0336] 22. The method of clause 20, wherein the maximum allowed sub-block transform width of the vertical binary tree is equal to one quarter of the maximum allowed transform width.

[0337] 23. The method of clause 20, wherein the maximum allowed sub-block transform height of the vertical binary tree is equal to half the maximum allowed transform height.

[0338] 24. The method of clause 20, wherein the maximum allowed sub-block transform height of the vertical binary tree is equal to one quarter of the maximum allowed transform width.

[0339] 25. The method of clause 14, wherein horizontal binary trees are allowed if the width of the video block is greater than a maximum allowed transform width and the height of the video block is not greater than a maximum allowed transform height.

[0340] 26. The method according to clause 25, further comprising:

[0341] A sub-block transform is applied to the portion of the sub-block resulting from the horizontal binary tree.

[0342] 27. The method of clause 14, wherein if the width of the video block is larger than a maximum allowed sub-block transform width and the height of the video block is not larger than the maximum allowed sub-block transform height, then horizontal binary trees are not allowed.

[0343] 28. The method of clause 27, wherein the maximum allowed sub-block transform width and height are associated with the horizontal binary tree.

[0344] 29. The method of clause 28, wherein the maximum allowed sub-block transform width of the horizontal binary tree is equal to half the maximum allowed transform width.

[0345] 30. The method of clause 28, wherein the maximum allowed sub-block transform width of the horizontal binary tree is equal to one quarter of the maximum allowed transform width.

[0346] 31. The method of clause 28, wherein the maximum allowed sub-block transform height of the horizontal binary tree is equal to half the maximum allowed transform height.

[0347] 32. The method of clause 28, wherein the maximum allowed sub-block transform height of the horizontal binary tree is equal to one quarter of the maximum allowed transform width.

[0348] 33. A method according to clause 14, wherein the variables Tx and Ty are defined as Tx = maximum (maximum allowed transform width, maximum allowed sub-block width), Ty = maximum (maximum allowed transform height, maximum allowed sub-block height), and wherein the sub-block is included in one or more sub-blocks, the method further comprising:

[0349] In response to determining that the width of the video block is not greater than Tx and the height of the video block is greater than Ty, disallowing vertical binary trees; and

[0350] In response to determining that the width of the video block is greater than Tx and the height of the video block is not greater than Ty, the horizontal binary tree is not allowed.

[0351] 34. A method according to any of clauses 1-33, wherein the method is applied when sub-block transform is enabled.

[0352] 35. A method according to any of clauses 1-34, wherein the method is applied when the SPS flag is true.

[0353] 36. A method for video processing, comprising:

[0354] determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a maximum allowed transform size and a virtual pipeline data unit (VPDU) size, or based at least in part on a maximum allowed sub-block transform size and a virtual pipeline data unit (VPDU) size, wherein the VPDU size comprises a VPDU height and a VPDU width, and wherein the maximum allowed transform size comprises a maximum allowed transform height and a maximum allowed transform width,

[0355] In response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream.

[0356] 37. The method of clause 36, wherein the partition tree comprises a vertical binary tree, a horizontal binary tree, or a ternary tree.

[0357] 38. A method according to clause 37, wherein vertical binary trees are not allowed if the width of the video block is not greater than f(VPDU width, maximum allowed transform width), wherein the height of the video block is greater than f(VPDU height, maximum allowed transform height), and wherein f(x, y) represents a mathematical function.

[0358] 39. A method according to clause 37, wherein horizontal binary trees are not allowed if the width of the video block is greater than f(VPDU width, maximum allowed transform width), wherein the height of the video block is not greater than f(VPDU height, maximum allowed transform height), and wherein f(x, y) represents a mathematical function.

[0359] 40. The method of any of clauses 38-39, wherein the mathematical function f(x,y)=max(x,y).

[0360] 41. The method of any of clauses 38-39, wherein the mathematical function f(x, y) = min(x, y).

[0361] 42. A method according to any of clauses 36-39, wherein the VPDU width is equal to the VPDU height.

[0362] 43. A method according to any of clauses 36-39, wherein the maximum allowed transform width is equal to the maximum allowed transform height.

[0363] 44. A method according to any of clauses 36-43, wherein the VPDU size is predefined.

[0364] 45. The method of clause 44, wherein the VPDU size is 64x64.

[0365] 46. A method according to any of clauses 36-43, wherein the VPDU size is signaled in at least one of a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a picture header, a slice group header, a slice header, a codec tree unit row or a region associated with a codec tree unit.

[0366] 47. A video decoding apparatus comprising a processor configured to implement the method recited in one or more of clauses 1 to 46.

[0367] 48. A video encoding apparatus comprising a processor configured to implement the method recited in one or more of clauses 1 to 46.

[0368] 49. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to carry out the method recited in any one of clauses 1 to 46.

[0369] 50. An apparatus in a video system comprising a processor and non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method of any one of clauses 1 to 46.

[0370] The disclosed and other solutions, examples, embodiments, modules, and functional operations described herein may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in a combination of one or more thereof. The disclosed and other embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by a data processing apparatus or for controlling the operation of the data processing apparatus. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances that effect a machine-readable propagated signal, or a combination of one or more thereof. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, an apparatus may include code that creates an operating environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more thereof. A propagated signal is an artificially generated signal, such as a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to a suitable receiver device.

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

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

[0373] Processors suitable for executing computer programs include, by way of example, both general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from read-only memory or random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include, or be operatively coupled to, one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, to receive data from or transfer data to or from them, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and storage devices, including, by way of example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as 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 into, special-purpose logic circuitry.

[0374] Although this patent document contains many details, these details should not be interpreted as limitations on the scope of any subject matter or the scope that can be claimed, but rather as descriptions of features that can be specified for specific embodiments of a particular technology. Certain features described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. In addition, although the above features may be described as working in certain combinations and even initially claimed as such, one or more features from the claimed combination can be cut out from the combination in some cases, and the claimed combination can be directed to subcombinations or variations of subcombinations.

[0375] Similarly, while operations may be depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown, or in sequential order, or that all illustrated operations be performed, in order to achieve desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

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

Claims

1. A video processing method, comprising: determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a virtual pipeline data unit (VPDU) size, wherein the VPDU size includes a VPDU height and a VPDU width, wherein, in response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream; Wherein, the segmentation tree includes a vertical binary tree, a horizontal binary tree or a ternary tree; Wherein, the ternary tree is not allowed if at least one of the following conditions is true: (1) the size of the video block is less than or equal to 2 * MinTtSizeY, (2) the width of the video block is greater than Min(VPDUSizeX, maxTtSize), and (3) the height of the video block is greater than Min(VPDUSizeY, maxTtSize), where MinTtSizeY and maxTtSize represent the minimum and maximum allowed sizes of the ternary tree, and VPDUSizeX and VPDUSizeY represent the VPDU width and the VPDU height.

2. The method according to claim 1, wherein If the width of the video block is not greater than the VPDU width and the height of the video block is greater than the height of the VPDU, the vertical binary tree is not allowed.

3. The method according to claim 1, wherein If the width of the video block is greater than the VPDU width and the height of the video block is not greater than the VPDU height, the horizontal binary tree is not allowed.

4. The method according to claim 1, wherein The VPDU height is equal to the VPDU width.

5. The method according to claim 4, wherein One of the height or width is signaled from the encoder to the decoder, and wherein the other of the height or width that is not signaled is set equal to the signaled height or width.

6. The method according to claim 1, wherein The VPDU height and the VPDU width are not equal.

7. The method according to claim 6, wherein: Both the VPDU height and the VPDU width are signaled from the encoder to the decoder.

8. The method according to claim 1, wherein The VPDU size is predefined.

9. The method according to claim 8, wherein The VPDU size is 64×64.

10. The method according to claim 1, wherein The VPDU size is signaled in at least one of a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a picture header, a slice group header, a slice header, a codec tree unit row, or a region associated with a codec tree unit.

11. A video processing method, comprising: determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a maximum allowed sub-block transform size, wherein the maximum allowed sub-block transform size comprises a maximum allowed sub-block transform height and a maximum allowed sub-block transform width, wherein, in response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream; Wherein, the segmentation tree includes a vertical binary tree or a horizontal binary tree; If the width of the video block is not greater than a maximum allowed transform width, and the height of the video block is greater than a maximum allowed transform height, then the vertical binary tree is allowed.

12. The method according to claim 11, further comprising: A sub-block transform is applied to the portion of the sub-block resulting from the vertical binary tree.

13. The method according to claim 11, wherein The vertical binary tree is allowed if the width of the video block is not greater than the maximum allowed transform width and the height of the video block is greater than the maximum allowed transform height, and the sub-blocks generated by the vertical binary tree support at least one sub-block transform size.

14. The method according to claim 11, wherein If the width of the video block is not greater than the maximum allowed transform width, and the height of the video block is greater than the maximum allowed transform height, and the block height is not greater than the maximum allowed sub-block transform height, then the vertical binary tree is allowed.

15. The method according to claim 11, wherein If the width of the video block is not greater than the maximum allowed sub-block transform width and the height of the video block is greater than the maximum allowed sub-block transform height, then the vertical binary tree is not allowed.

16. The method according to claim 15, wherein The maximum allowed sub-block transform width and the maximum allowed sub-block transform height are associated with the vertical binary tree.

17. The method according to claim 16, wherein The maximum allowed sub-block transform width of the vertical binary tree is equal to half of the maximum allowed transform width.

18. The method according to claim 16, wherein The maximum allowed sub-block transform width of the vertical binary tree is equal to one quarter of the maximum allowed transform width.

19. The method according to claim 16, wherein The maximum allowed sub-block transformation height of the vertical binary tree is equal to half of the maximum allowed transformation height.

20. The method according to claim 16, wherein The maximum allowed sub-block transform height of the vertical binary tree is equal to one quarter of the maximum allowed transform height.

21. The method according to claim 11, wherein If the width of the video block is greater than a maximum allowed transform width and the height of the video block is not greater than a maximum allowed transform height, then the horizontal binary tree is allowed.

22. The method according to claim 21, further comprising: A sub-block transform is applied to the portion of the sub-blocks resulting from the horizontal binary tree.

23. The method according to claim 11, wherein If the width of the video block is greater than the maximum allowed sub-block transform width and the height of the video block is not greater than the maximum allowed sub-block transform height, then the horizontal binary tree is not allowed.

24. The method according to claim 23, wherein The maximum allowed sub-block transform width and the maximum allowed sub-block transform height are associated with the horizontal binary tree.

25. The method according to claim 24, wherein The maximum allowed sub-block transform width of the horizontal binary tree is equal to half of the maximum allowed transform width.

26. The method according to claim 24, wherein The maximum allowed sub-block transform width of the horizontal binary tree is equal to one quarter of the maximum allowed transform width.

27. The method according to claim 24, wherein The maximum allowed sub-block transformation height of the horizontal binary tree is equal to half of the maximum allowed transformation height.

28. The method according to claim 24, wherein The maximum allowed sub-block transform height of the horizontal binary tree is equal to one quarter of the maximum allowed transform height.

29. The method according to claim 11, wherein Variables Tx and Ty are defined as Tx=maximum(maximum allowed transform width, maximum allowed sub-block width), Ty=maximum(maximum allowed transform height, maximum allowed sub-block height), and wherein the sub-block is included in one or more sub-blocks, the method further comprising: In response to determining that the width of the video block is not greater than Tx and the height of the video block is greater than Ty, disallowing the vertical binary tree; and In response to determining that the width of the video block is greater than Tx and the height of the video block is not greater than Ty, the horizontal binary tree is not allowed.

30. The method according to any one of claims 1 to 29, wherein The method is applied when sub-block transform is enabled.

31. The method according to any one of claims 1 to 29, wherein When the SPS flag is true, the method is applied.

32. A video processing method, comprising: determining whether a partition type associated with the partition tree is allowed or not allowed for the video block based at least in part on a maximum allowed transform size and a virtual pipeline data unit VPDU size, or based at least in part on a maximum allowed sub-block transform size and the virtual pipeline data unit VPDU size, wherein the VPDU size includes a VPDU height and a VPDU width, and wherein the maximum allowed transform size includes a maximum allowed transform height and a maximum allowed transform width, In response to the segmentation type not being allowed, there is no indication of the segmentation type in the bitstream.

33. The method according to claim 32, wherein The partition tree includes a vertical binary tree, a horizontal binary tree or a ternary tree.

34. The method according to claim 33, wherein If the width of the video block is not greater than f(VPDU width, maximum allowed transform width), the vertical binary tree is not allowed, wherein the height of the video block is greater than f(VPDU height, maximum allowed transform height), and wherein f(x, y) represents a mathematical function.

35. The method of claim 33, wherein: If the width of the video block is greater than f(VPDU width, maximum allowed transform width), the horizontal binary tree is not allowed, wherein the height of the video block is not greater than f(VPDU height, maximum allowed transform height), and wherein f(x, y) represents a mathematical function.

36. The method according to claim 34 or 35, wherein The mathematical function f(x, y)=max(x, y).

37. The method according to claim 34 or 35, wherein The mathematical function f(x, y)=min(x, y).

38. The method of claim 32, wherein: The VPDU width is equal to the VPDU height.

39. The method of claim 32, wherein: The maximum allowed transformation width is equal to the maximum allowed transformation height.

40. The method of claim 32, wherein The VPDU size is predefined.

41. The method according to claim 40, wherein The VPDU size is 64×64.

42. The method of claim 32, wherein: The VPDU size is signaled in at least one of a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a picture header, a slice group header, a slice header, a codec tree unit row, or a region associated with a codec tree unit.

43. A video decoding device, comprising a processor, wherein the processor is configured to implement the method according to any one of claims 1 to 42.

44. A video encoding apparatus comprising a processor configured to implement the method of any one of claims 1 to 42.

45. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to carry out the method of any one of claims 1 to 42.

46. An apparatus in a video system comprising a processor and a non-transitory memory having instructions thereon, wherein: When the instructions are executed by the processor, the processor is caused to implement the method of any one of claims 1 to 42.

Images