Coding-tree partitioning

Abstract

To provide a coded tree partitioning method and device in video coding or decoding.SOLUTION: The method includes: partitioning a coding tree unit (CTU) in a picture by a quadtree (QT) structure in order to encode the picture; partitioning a QT leaf node by a multi type tree (MTT) structure; and increasing the maximum allowable MTT layer depth to twice the difference between the CTU size and the minimum allowable size of the coding unit in order to increase sets of a reachable coding tree node and a leaf. The method also includes: designating the maximum allowable MTT layer depth for all QT levels in order to add flexibility to a decomposition tree; alternatively, two maximum allowable MTT depth levels, notifying a signal only when QT decomposition is permitted and when not permitted more than that; and setting an upper limit to a minimum allowable coding block size on the basis of the CTU size or a maximum allowable conversion size.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present embodiments generally relate to methods and apparatus for coding tree partitioning in video encoding or decoding. [Background technology]

[0002] To achieve high compression efficiency, image and video coding schemes usually exploit spatial and temporal redundancy in video content using prediction and transformation. In general, intra- or inter-prediction is used to exploit intra- or inter-picture correlation, and then the difference between the original block and the predicted block, often referred to as prediction error or prediction residual, is transformed, quantized, and entropy coded. To reconstruct the video, the compressed data is decoded by an inverse process corresponding to the entropy coding, quantization, transformation, and prediction. Summary of the Invention

[0003] To code a picture, the coding tree units (CTUs) in the picture are partitioned by a quadtree structure, and the quadtree leaf nodes may be further partitioned by a multi-type tree (MTT) structure. To increase the set of reachable coding tree nodes and leaves, we propose to increase the maximum allowed MTT hierarchy depth to twice the difference between the CTU size and the minimum allowed size of a CU. To allow more flexibility in the partitioning tree, the maximum allowed MTT hierarchy depth can be specified for all QT levels. Alternatively, only two levels of the maximum allowed MTT depth are signaled, one when QT partitioning is allowed and another when no further QT partitioning is allowed. In addition, an upper limit can be set on the minimum allowed coding block size based on the coding tree unit size or the maximum allowed transform size. Furthermore, flags can be used to indicate whether binary trees (BT) are allowed and whether ternary trees (TT) are enabled for the MTT. Flags indicating whether BT or TT is enabled can be sent separately for intra / inter slice and luma / chroma components. [Brief description of the drawings]

[0004] [Figure 1] 1 illustrates a block diagram of a system in which aspects of the present embodiments may be implemented. [Diagram 2] 1 illustrates a block diagram of one embodiment of a video encoder. [Diagram 3] 1 illustrates a block diagram of one embodiment of a video decoder. [Figure 4] Illustrates a CTU divided into CUs according to the HEVC standard. [Diagram 5] Illustrates the division of a CTU into CUs, PUs, and TUs according to the HEVC standard. [Figure 6] Illustrates the CTU representation of a quad-plus-binary tree (QTBT) in VVC. [Figure 7] 1 illustrates the set of all coding unit partitioning modes supported in VVC Draft 6. [Figure 8] Illustrates partitioning of a 32x32 block using only BT of depth 5. [Figure 9] Illustrates partitioning of a 32x32 block using only BT of depth 2. [Figure 10] Illustrates partitioning of a 32x32 block using only TT of depth 2. [Figure 11] Illustrates minimum, maximum, and Common Experimental Condition (CTC) values ​​for segmentation-related syntax elements in VVC Draft 6. [Figure 12] 1 illustrates a modified maximum allowed value of minimum coded block size based on maximum allowed transform size, according to one embodiment. [Figure 13] 13 illustrates a modified maximum allowed value of minimum coded block size based on CTU size according to another embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] FIG. 1 illustrates a block diagram of an example of a system in which various aspects and embodiments can be implemented. System 100 may be embodied as a device including various components described below and configured to perform one or more of the aspects described herein. Examples of such devices include various electronic devices, such as, but not limited to, personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television sets, personal video recording systems, connected appliances, and servers. The elements of system 100, alone or in combination, may be embodied in a single integrated circuit, multiple ICs, and / or separate components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 100 are distributed across multiple ICs and / or separate components. In various embodiments, system 100 is communicatively coupled to other systems or to other electronic devices, for example, via a communication bus or via dedicated input and / or output ports. In various embodiments, system 100 is configured to implement one or more of the aspects described herein.

[0006] The system 100 includes at least one processor 110 configured to execute instructions loaded therein, for example, to implement various aspects described herein. The processor 110 may include embedded memory, input / output interfaces, and various other circuits as known in the art. The system 100 includes at least one memory 120 (e.g., a volatile memory device and / or a non-volatile memory device). The system 100 includes a storage device 140, which may include non-volatile and / or volatile memory, including, but not limited to, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drives, and / or optical disk drives. The storage device 140 may include, as non-limiting examples, an internal storage device, a removable storage device, and / or a network-accessible storage device.

[0007] System 100 includes an encoder / decoder module 130 configured to process data to provide, for example, encoded or decoded video, which may include its own processor and memory. Encoder / decoder module 130 represents a module that may be included in a device that performs encoding and / or decoding functions. As is known, a device may include one or both of an encoding module and a decoding module. Furthermore, encoder / decoder module 130 may be implemented as a separate element of system 100 or may be incorporated within processor 110 as a combination of hardware and software known to those skilled in the art.

[0008] Program code to be loaded into the processor 110 or the encoder / decoder 130 to perform various aspects described herein may be stored in the storage device 140 and subsequently loaded onto the memory 120 for execution by the processor 110. According to various embodiments, one or more of the processor 110, the memory 120, the storage device 140, and the encoder / decoder module 130 may store one or more of various items during execution of the processes described herein. Such stored items may include, but are not limited to, input video, decoded video or portions of decoded video, bitstreams, matrices, variables, and intermediate or final results from processing of equations, expressions, operations, and computational logic.

[0009] In some embodiments, memory internal to the processor 110 and / or the encoder / decoder module 130 is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other embodiments, memory external to the processing device (e.g., the processing device can be either the processor 110 or the encoder / decoder module 130) is used for one or more of these functions. The external memory can be the memory 120 and / or the storage device 140, and can be, for example, a dynamic volatile memory and / or a non-volatile flash memory. In some embodiments, an external non-volatile flash memory is used to store the television's operating system. In at least one embodiment, a high-speed external dynamic volatile memory, such as a RAM, is used as working memory for video coding and decoding operations, such as MPEG-2, HEVC, or VVC.

[0010] Input to the elements of system 100 may be provided via various input devices as shown in block 105. Such input devices include, but are not limited to, (i) an RF section that receives, for example, an RF signal transmitted over the air by a broadcaster, (ii) a composite input, (iii) a USB input, and / or (iv) an HDMI input.

[0011] In various embodiments, the input devices of block 105 have associated respective input processing elements as known in the art. For example, the RF section may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal or band-limiting a signal to a frequency band), (ii) down-converting the selected signal, (iii) band-limiting again to a narrower frequency band to select a signal frequency band, which in certain embodiments may be referred to as a channel (for example), (iv) demodulating the down-converted band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. The RF section of various embodiments includes one or more elements that perform these functions, such as a frequency selector, a signal selector, a band limiter, a channel selector, a filter, a down-converter, a demodulator, an error corrector, and a demultiplexer. The RF section may include, for example, a tuner that performs various of these functions, including down-converting a received signal to a lower frequency (e.g., an intermediate frequency or a frequency close to baseband) or to baseband. In one set-top box embodiment, the RF section and its associated input processing elements perform frequency selection by receiving, filtering, downconverting, and filtering again to the desired frequency band an RF signal transmitted over a wired (e.g., cable) medium. Various embodiments rearrange the order of the above (and other) elements, remove some of these elements, and / or add other elements that perform similar or different functions. Adding elements may include inserting elements between existing elements, for example, inserting amplifiers and analog-to-digital converters. In various embodiments, the RF section includes an antenna.

[0012] Additionally, the USB and / or HDMI terminals may include respective interface processors for connecting the system 100 to other electronic devices over USB and / or HDMI connections. It should be appreciated that various aspects of the input processing, e.g., Reed-Solomon error correction, may be implemented, for example, in a separate input processing IC or in the processor 110, as desired. Similarly, aspects of the USB or HDMI interface processing may be implemented, for example, in a separate interface IC or in the processor 110, as desired. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements including, for example, the processor 110 and an encoder / decoder 130 that operates in combination with memory and storage elements to process the data stream as desired for display on an output device.

[0013] The various elements of system 100 may be provided within a unitary housing in which the various elements are interconnected and may transmit data therebetween using a suitable connection arrangement 115, e.g., an internal bus as is known in the art, including an I2C bus, hardwire, and printed circuit board.

[0014] System 100 includes a communication interface 150 that enables communication with other devices over a communication channel 190. Communication interface 150 may include, but is not limited to, a transceiver configured to transmit and receive data over communication channel 190. Communication interface 150 may include, but is not limited to, a modem or a network card, and communication channel 190 may be implemented in a wired and / or wireless medium, for example.

[0015] In various embodiments, data is streamed to the system 100 using a Wi-Fi network, such as IEEE 802.11. The Wi-Fi signal in these embodiments is received via a communication channel 190 and communication interface 150 adapted for Wi-Fi communication. The communication channel 190 in these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet, to enable streaming applications and other over-the-top communications. Other embodiments provide streamed data to the system 100 using a set-top box that delivers data via an HDMI connection in the input block 105. Still other embodiments provide streamed data to the system 100 using an RF connection in the input block 105.

[0016] System 100 may provide output signals to various output devices, including display 165, speakers 175, and other peripheral devices 185. Other peripheral devices 185, in various example embodiments, include one or more of a stand-alone DVR, a disc player, a stereo system, a lighting system, and other devices that provide functionality based on the output of system 100. In various embodiments, control signals are transmitted between system 100 and display 165, speakers 175, or other peripheral devices 185 using signaling such as AV link, CEC, or other communication protocols that allow device-to-device control with or without user intervention. Output devices may be communicatively coupled to system 100 via dedicated connections through respective interfaces 160, 170, and 180. Alternatively, output devices may be connected to system 100 using communication channel 190 via communication interface 150. Display 165 and speakers 175 may be integrated into a single unit with other components of system 100 in an electronic device such as a television. In various embodiments, the display interface 160 includes a display driver, such as a timing controller (T Con) chip.

[0017] Display 165 and speakers 175 may alternatively be separate from one or more of the other components, for example, if the RF portion of input 105 is part of a separate set-top box. In various embodiments in which display 165 and speakers 175 are external components, output signals may be provided via dedicated output connections including, for example, an HDMI port, a USB port, or a COMP output.

[0018] 2 illustrates an example video encoder 200, such as a High Efficiency Video Coding (HEVC) encoder. FIG. 2 may also illustrate an encoder that has improvements to the HEVC standard or that employs technology similar to HEVC, such as the Versatile Video Coding (VVC) encoder under development by the Joint Video Exploration Team (JVET).

[0019] In this application, the terms "reconstructed" and "decoded" may be used interchangeably, the terms "encoded" or "coded" may be used interchangeably, and the terms "image", "picture", and "frame" may be used interchangeably. Typically, but not necessarily, the term "reconstructed" is used on the encoder side, while "decoded" is used on the decoder side.

[0020] Before being encoded, the video sequence may undergo a pre-encoding process (201), for example applying a color transformation to the input color picture (e.g., from RGB 4:4:4 to YCbCr 4:2:0) or performing a remapping of the input picture components to obtain a signal distribution that is more resilient to compression (e.g., using histogram equalization of one of the color components). Metadata may be associated with the pre-processing and may be attached to the bitstream.

[0021] To encode a video sequence with one or more pictures, a picture is partitioned into one or more slices, where each slice may contain one or more slice segments (202). In HEVC, slice segments are organized into coding units, prediction units, and transform units. The HEVC specification distinguishes between "blocks" and "units," where a "block" addresses a particular region of a sample array (e.g., luma, Y), and a "unit" includes a collocated block of all coded color components (Y, Cb, Cr, or monochrome), syntax elements, and prediction data (e.g., motion vectors) associated with the block.

[0022] In HEVC coding, a picture is partitioned into square coding tree blocks (CTBs) with a configurable size (typically 64x64, 128x128, or 256x256 pixels), and a contiguous set of coding tree blocks is grouped into a slice. A coding tree unit (CTU), also called a largest coding unit (LCU), contains the CTBs of the coded color components. The CTB (also called largest coding block, LCB) is the root of the quadtree partitioning into coding blocks (CBs) as illustrated in Figure 4, and the coding blocks may be partitioned into one or more prediction blocks (PBs), forming the root of the quadtree partitioning into transform blocks (TBs), as illustrated in Figure 5.

[0023] Corresponding to the coding block, the prediction block, and the transform block, the coding unit (CU) includes a prediction unit (PU) and a tree-structured set of transform units (TUs), where the PU includes prediction information for all color components, and the TU includes the residual coding syntax structure for each color component. The sizes of the CB, PB, and TB of the luma component apply to the corresponding CU, PU, ​​and TU. In this application, the term "block" may be used to refer to any of the CTU, CU, PU, ​​TU, CB, PB, and TB. Furthermore, the "block" may also be used to refer to macroblocks and partitions defined in H.264 / AVC or other video coding standards, and more generally to refer to arrays of data of various sizes.

[0024] In the encoder 200, a picture is encoded by the encoder elements as described below. The picture to be encoded is processed, for example, in units of CUs. Each coding unit is encoded using either intra mode or inter mode. When the coding unit is encoded in intra mode, intra prediction is performed (260). In inter mode, motion estimation (275) and motion compensation (270) are performed. The encoder decides (205) whether to use one of the intra mode or inter mode to encode the coding unit, and indicates the intra / inter decision by a prediction mode flag. A prediction residual is calculated (210) by subtracting the prediction block from the original image block.

[0025] The prediction residual is then transformed (225) and quantized (230). The quantized transform coefficients, as well as the motion vectors and other syntax elements, are entropy coded (245) to output a bitstream. As a non-limiting example, context-based adaptive binary arithmetic coding (CABAC) can be used to encode the syntax elements into the bitstream.

[0026] The encoder may also skip the transform and apply quantization directly to the untransformed residual signal, for example on a 4×4 TU basis. The encoder may also bypass both the transform and quantization, i.e., the residual is directly coded without applying a transform or quantization process. In direct PCM coding, no prediction is applied and coded unit samples are coded directly into the bitstream.

[0027] The encoder decodes the coded block to provide a reference for further prediction. The quantized transform coefficients are inverse quantized (240) and inverse transformed (250) to decode the prediction residual. The decoded prediction residual is combined (255) with the prediction block to reconstruct an image block. An in-loop filter (265) is applied to the reconstructed picture, for example to perform deblocking / SAO (sample adaptive offset) filtering to reduce coding artifacts. The filtered image is stored in a reference picture buffer (280).

[0028] FIG. 3 illustrates a block diagram of an exemplary video decoder 300, such as an HEVC decoder. In the decoder 300, a bitstream is decoded by decoder elements as described below. The video decoder 300 generally performs a reverse decoding pass of the encoding pass as described in FIG. 2, which performs video decoding as part of encoding the video data. FIG. 3 may also illustrate a decoder that has improvements made to the HEVC standard or that employs techniques similar to HEVC, such as a VVC decoder.

[0029] In particular, the decoder input includes a video bitstream that may be generated by the video encoder 200. The bitstream is first entropy decoded (330) to obtain transform coefficients, motion vectors, picture partitioning information, and other coded information. The picture partitioning information indicates how a picture is partitioned, e.g., the size of the CTUs, and how the CTUs are partitioned into CUs and, if applicable, into PUs. Thus, the decoder may, for example, divide the picture into CTUs (335) and each CTU into CUs according to the decoded picture partitioning information. The transform coefficients are inverse quantized (340) and inverse transformed (350) to decode the prediction residual.

[0030] The decoded prediction residual is combined with the prediction block (355) to reconstruct an image block. The prediction block may be obtained from intra prediction (360) or motion compensated prediction (i.e., inter prediction) (375) (370). An in-loop filter (365) is applied to the reconstructed image. The filtered image is stored in a reference picture buffer (380).

[0031] The decoded picture may further undergo a post-decoding process (385), such as an inverse color conversion (e.g., converting from YCbCr 4:2:0 to RGB 4:4:4) or an inverse remapping that performs the inverse of the remapping process performed in the pre-encoding process (201). The post-decoding process may use metadata derived in the pre-encoding process and signaled in the bitstream.

[0032] New video compression tools in VVC include a coded tree unit representation in the compressed domain, which can represent picture data in a more flexible way. In VVC, a quadtree with nested multi-type trees (MTTs) using bipartite and tripartite segmentation structures replaces the concept of multiple partition unit types, i.e., VVC removes the separation of CU, PU, ​​and TU concepts except for some special cases. In the VVC coded tree structure, a CU can have either a square or rectangular shape. A coded tree unit (CTU) is first partitioned by a quadtree structure. Then, the quadtree leaf nodes can be further partitioned by a multi-type tree structure.

[0033] In particular, the tree decomposition of a CTU proceeds in various stages, first splitting the CTU in a quadtree manner, and then each quadtree leaf can be further split in a bisection or trisection manner. This is illustrated on the right side of Figure 6, where the solid lines represent the quadtree decomposition phase and the dashed lines represent the bisection decomposition spatially embedded in the quadtree leaf. For intra slices, when the dual tree mode is activated, the luma and chroma block partitioning structures are separated and determined independently.

[0034] As shown in Fig. 7, the multi-type tree structure has four partition types: vertical bisection (VER), horizontal bisection (HOR), vertical trisection (VER_TRIPLE), and horizontal trisection (HOR_TRIPLE). HOR_TRIPLE or VER_TRIPLE partition (horizontal or vertical triple tree partition mode) partitions a coding unit (CU) into three sub-coded units (sub-CUs), with sizes equal to ¼, ½, and ¼ of the parent CU size in the direction of the considered spatial partition.

[0035] The multi-type tree leaf nodes are called coding units (CUs), and this segmentation is used for prediction and transformation processes without further partitioning, except in some special cases. Exceptions occur under the following conditions: If the width or height of a CU is greater than 64, tiling of the CU into TUs of size equal to the maximum supported transform size is performed. Typically, the maximum transform size may be equal to 64. - If an intra CU is coded in ISP (intra sub-partition) mode, the CU is split into two or four transform units, depending on the type of ISP mode used and the shape of the CU. - If an inter CU is coded in SBT (Sub-Block Transform) mode, the CU is split into two transform units, and one of the resulting TUs necessarily has residual data equal to zero. - If an inter CU is coded in Triangle Prediction Merge (TPM) mode, the CU is composed of two triangular prediction units, and each PU is assigned its own motion data.

[0036] According to VVC draft 6, the syntax related to partitioning is coded in the sequence parameter set (SPS). If partition_constraints_override_enabled_flag is true, the syntax related to partitioning can be overridden in the slice header (SH). The SPS syntax and SH syntax used in VVC draft 6 are shown in Table 1 and Table 2. [Table 1]

[0037] The semantics of some SPS syntax elements are described below.

[0038] log2_ctu_size_minus5+5 specifies the luma coding tree block size of each CTU. The value of log2_ctu_size_minus5 must be less than or equal to 2 for bitstream conformance.

[0039] Log2_min_luma_coding_block_size_minus2+2 specifies the minimum luma coding block size.

[0040] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows: CtbLog2SizeY=log2_ctu_size_minus5+5 (7-15) CtbSizeY=1< <CtbLog2SizeY (7-16) MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2 (7-17) MinCbSizeY=1< <MinCbLog2SizeY (7-18) IbcBufWidthY=128*128 / CtbSizeY (7-19) IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20) VSize=Min(64,CtbSizeY) (7-21)

[0041] The variables CtbWidthC and CtbHeightC, which specify the width and height, respectively, of each chroma CTB's array, are derived as follows: - If chroma_format_idc is equal to 0 (monochrome) or separate_colour_plane_flag is equal to 1, then CtbWidthC and CtbHeightC are both equal to 0. - Otherwise, CtbWidthC and CtbHeightC are derived as follows: CtbWidthC=CtbSizeY / SubWidthC (7-22) CtbHeightC=CtbSizeY / SubHeightC (7-23)

[0042] sps_log2_diff_min_qt_min_cb_intra_slice_luma specifies the default difference between the base 2 logarithm of the minimum size of luma samples of luma leaf blocks resulting from a quadtree decomposition of a CTU and the base 2 logarithm of the minimum coded block size of luma samples of luma CUs of slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_min_qt_min_cb_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_min_qt_min_cb_intra_slice_luma must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. The base 2 logarithm of the minimum size of luma samples of luma leaf blocks resulting from a quadtree decomposition of a CTU is derived as follows: MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY(7-24)

[0043] sps_log2_diff_min_qt_min_cb_inter_slice specifies the default difference between the base 2 logarithm of the minimum size of luma samples of luma leaf blocks resulting from a quadtree decomposition of a CTU and the base 2 logarithm of the minimum luma coding block size of luma samples of luma CUs in slices with slice_type equal to 0 (B) or 1 (P) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_min_qt_min_cb_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_min_qt_min_cb_inter_slice must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. The base 2 logarithm of the minimum size of luma samples of luma leaf blocks resulting from a quadtree decomposition of a CTU is derived as follows: MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY(7-25)

[0044] sps_max_mtt_hierarchy_depth_inter_slice specifies the default maximum hierarchy depth of coding units resulting from a multitype tree partition of quadtree leaves of slices with slice_type equal to 0 (B) or 1 (P) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default maximum hierarchy depth can be overridden by slice_max_mtt_hierarchy_depth_luma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_inter_slice must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0045] sps_max_mtt_hierarchy_depth_intra_slice_luma specifies the default maximum hierarchy depth of coding units resulting from a multitype tree partition of quadtree leaves of slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default maximum hierarchy depth can be overridden by slice_max_mtt_hierarchy_depth_luma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_intra_slice_luma must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0046] sps_log2_diff_max_bt_min_qt_intra_slice_luma specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a luma coded block that can be divided using bisection and the minimum size (width or height) of luma samples of a luma leaf block resulting from a quadtree decomposition of a CTU for slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_max_bt_min_qt_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_bt_min_qt_intra_slice_luma must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeIntraY, inclusive. If sps_log2_diff_max_bt_min_qt_intra_slice_luma is not present, the value of sps_log2_diff_max_bt_min_qt_intra_slice_luma is inferred to be equal to 0.

[0047] sps_log2_diff_max_tt_min_qt_intra_slice_luma specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a luma coding block that can be divided using trisection and the minimum size (width or height) of luma samples of a luma leaf block resulting from a quadtree decomposition of a CTU of a slice with slice_type equal to 2(I) that references an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_max_tt_min_qt_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_tt_min_qt_intra_slice_luma must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeIntraY, inclusive. If sps_log2_diff_max_tt_min_qt_intra_slice_luma is not present, the value of sps_log2_diff_max_tt_min_qt_intra_slice_luma is inferred to be equal to 0.

[0048] sps_log2_diff_max_bt_min_qt_inter_slice specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a luma coding block that can be divided using bisection and the minimum size (width or height) of luma samples of a luma leaf block resulting from a quadtree decomposition of a CTU of a slice with slice_type equal to 0 (B) or 1 (P) that references an SPS. If partition_constraints_override_flag equals 1, the default difference can be overridden by slice_log2_diff_max_bt_min_qt_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_bt_min_qt_inter_slice must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeInterY, inclusive. If sps_log2_diff_max_bt_min_qt_inter_slice is not present, the value of sps_log2_diff_max_bt_min_qt_inter_slice is inferred to be equal to 0.

[0049] sps_log2_diff_max_tt_min_qt_inter_slice specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a luma coding block that can be divided using trisection and the minimum size (width or height) of luma samples of a luma leaf block resulting from a quadtree decomposition of a CTU of a slice with slice_type equal to 0 (B) or 1 (P) that references an SPS. If partition_constraints_override_flag equals 1, the default difference can be overridden by slice_log2_diff_max_tt_min_qt_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_tt_min_qt_inter_slice must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeInterY, inclusive. If sps_log2_diff_max_tt_min_qt_inter_slice is not present, the value of sps_log2_diff_max_tt_min_qt_inter_slice is inferred to be equal to 0.

[0050] sps_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the default difference between the base 2 logarithm of the minimum size of luma samples of chroma leaf blocks resulting from a quadtree decomposition of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coded block size of luma samples of a chroma CU with treeType equal to DUAL_TREE_CHROMA of slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_min_qt_min_cb_chroma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_min_qt_min_cb_intra_slice_chroma must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of sps_log2_diff_min_qt_min_cb_intra_slice_chroma is inferred to be equal to 0. The base 2 logarithm of the minimum size of luma samples of a chroma leaf block resulting from a quadtree decomposition of a CTU with treeType equal to DUAL_TREE_CHROMA is derived as follows: MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY(7-26)

[0051] sps_max_mtt_hierarchy_depth_intra_slice_chroma specifies the default maximum hierarchical depth of chroma coding units resulting from a multitype tree partition of chroma quadtree leaves with treeType equal to DUAL_TREE_CHROMA for slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default maximum hierarchical depth can be overridden by slice_max_mtt_hierarchy_depth_chroma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_intra_slice_chroma must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of sps_max_mtt_hierarchy_depth_intra_slice_chroma is inferred to be equal to 0.

[0052] sps_log2_diff_max_bt_min_qt_intra_slice_chroma specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a chroma coded block that can be divided using bisection and the minimum size (width or height) of luma samples of a chroma leaf block resulting from a quadtree decomposition of a chroma CTU with treeType equal to DUAL_TREE_CHROMA for slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_max_bt_min_qt_chroma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_bt_min_qt_intra_slice_chroma must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeIntraC, inclusive. If sps_log2_diff_max_bt_min_qt_intra_slice_chroma is not present, the value of sps_log2_diff_max_bt_min_qt_intra_slice_chroma is inferred to be equal to 0.

[0053] sps_log2_diff_max_tt_min_qt_intra_slice_chroma specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a chroma coded block that can be divided using trisection and the minimum size (width or height) of luma samples of a chroma leaf block resulting from a quadtree decomposition of a chroma CTU with treeType equal to DUAL_TREE_CHROMA for slices with slice_type equal to 2(I) that reference an SPS. If partition_constraints_override_flag equals 1, the default difference can be overridden by slice_log2_diff_max_tt_min_qt_chroma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_tt_min_qt_intra_slice_chroma must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeIntraC, inclusive. If sps_log2_diff_max_tt_min_qt_intra_slice_chroma is not present, the value of sps_log2_diff_max_tt_min_qt_intra_slice_chroma is inferred to be equal to 0.

[0054] If sps_max_luma_transform_size_64_flag is equal to 1, it specifies that the maximum transform size of luma samples is equal to 64. If sps_max_luma_transform_size_64_flag is equal to 0, it specifies that the maximum transform size of luma samples is equal to 32.

[0055] If CtbSizeY is less than 64, the value of sps_max_luma_transform_size_64_flag must be equal to 0.

[0056] The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, and MaxTbSizeY are derived as follows: MinTbLog2SizeY=2 (7-27) MaxTbLog2SizeY=sps_max_luma_transform_size_64_flag?6:5 (7-28) MinTbSizeY=1< <MinTbLog2SizeY (7-29) MaxTbSizeY=1< <MaxTbLog2SizeY (7-30) [Table 2]

[0057] In the following, the maximum allowed hierarchical depth (max_mtt_hierarchy_depth) of a multi-type tree splitting from a quadtree leaf is described using the syntax element sps_max_mtt_hierarchy_depth_inter_slice of an inter-slice luminance color component as an example, however, the principle can also be applied to intra-slice or chroma color components (e.g., syntax elements sps_max_mtt_hierarchy_depth_intra_slice_luma and sps_log2_diff_min_qt_min_cb_intra_slice_chroma).

[0058] In VVC Draft 6, the value of sps_max_mtt_hierarchy_depth_inter_slice shall be in the range of 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. Typically, MinCbLog2SizeY is equal to 2 corresponding to 4x4 blocks, and CtbLog2SizeY is equal to 7 corresponding to 128x128 CTUs. In this configuration, max_mtt_hierarchy_depth shall be in the range of 0 to 5. If the minimum QT size (i.e., 1<<MinQtLog2SizeInterY) is equal to 32 and only BT is used, the minimum block sizes that can be reached are 4x8 and 8x4 when the BT split depth is 5, as shown in Figure 8. That is, in this example, the encoder does not have the flexibility to support 4x4 block sizes. More generally, the encoder only supports a subset of the split modes specified by VVC.

[0059] To emphasize the lack of flexibility, a configuration with a CTU size equal to 32, a minimum Cb size of 8, and a minimum QT size of 32 is used. This means that only BT and TT can be used. In this configuration, max_mtt_hierarchy_depth is set to 2. When only BT is used, the minimum block sizes that can be reached are 16x16 or 8x32, and when only TT is used, as shown in Figures 9 and 10, some regions can only be split into 16x16.

[0060] To better illustrate the syntax elements related to splitting, Figure 11 illustrates the possible values of CTU size, minimum coding block size, maximum transform size, minimum QT size, and maximum BT / TT size. The actual values used in the common test conditions (CTC) of VTM6.0 are also illustrated. It can be seen that the minimum coding block size (min_luma_coding_block_size) is only limited by the CTU size.

[0061] As described above, the way in which the coding tree depth is typically limited due to the combined use of the maximum block size and maximum multi-type tree depth allowed by BT or TT partitioning makes the VVC compression scheme potentially suboptimal in terms of coding efficiency given fixed maximum and minimum block sizes. Another problem is that the log2_min_luma_coding_block_size_minus2 syntax element is not related to other syntax elements and does not have a maximum value. This can lead to situations in which an encoder generates a VVC bitstream with a value of log2_min_luma_coding_block_size_minus2 that is larger than the maximum block size, making it inconsistent.

[0062] To address VVC's lack of flexibility for maximum partitioning depth, the maximum binary tree (BT) size, maximum ternary tree (TT) size, and maximum hierarchical depth information are defined separately for intra-slice and inter-slice. In the case of dual trees, the maximum BT size / maximum TT size and maximum MTT depth are also defined for the intra-slice chroma tree. The proposed method may increase the set of reachable coding tree nodes and leaves under the constraints of pre-fixed maximum and minimum coding block sizes, thus improving compression efficiency through a higher degree of flexibility of the allowed coding tree representation.

[0063] In one embodiment, the maximum values ​​of sps_max_mtt_hierarchy_depth_inter_slice and sps_max_mtt_hierarchy_depth_intra_slice_luma are increased. In the following, for ease of notation, max_mtt_hierarchy_depth is used as a generic term to refer to syntax elements related to the maximum MTT hierarchy depth, such as sps_max_mtt_hierarchy_depth_inter_slice and sps_max_mtt_hierarchy_depth_intra_slice_luma. In another embodiment, max_mtt_hierarchy_depth is described for all available QT depths to provide even more flexibility for describing the partitioning tree. In another embodiment, max_mtt_hierarchy_depth is different when QT partitioning is available for a given depth and when QT partitioning is not available for a given depth.

[0064] In another embodiment, the syntax element sps_max_luma_transform_size_64_flag is moved before log2_min_luma_coding_block_size_minus2 and defines the maximum value of the coding block size (log2_min_luma_coding_block_size_minus2) depending on the maximum transform size (sps_max_luma_transform_size_64_flag).

[0065] In the following, different embodiments are explained in more detail.

[0066] Maximum hierarchy depth for VVC Draft 6 In this embodiment, we propose to increase the allowed number of successive splits (i.e., split depth, or MTT hierarchical depth) to twice the difference between the CTU size and the minimum size of a CU, which allows us to reach the minimum CU size in the worst case where no QT is used (minimum QT is defined as the CTU size) and only BT and TT splits are used.

[0067] Changes to the text of the specification are underlined below.

[0068] sps_max_mtt_hierarchy_depth_inter_slice specifies the default maximum hierarchy depth of coding units resulting from a multitype tree partition of quadtree leaves of slices with slice_type equal to 0 (B) or 1 (P) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default maximum hierarchy depth can be overridden by slice_max_mtt_hierarchy_depth_luma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_inter_slice is

number

[0069] slice_max_mtt_hierarchy_depth_luma specifies the maximum hierarchical depth of a coding unit resulting from a multitype tree split of a quadtree leaf of the current slice. The value of slice_max_mtt_hierarchy_depth_luma is

number

[0070] If slice_type is equal to 2(I), the value of slice_max_mtt_hierarchy_depth_luma is inferred to be equal to sps_max_mtt_hierarchy_depth_intra_slice_luma.

[0071] Otherwise (slice_type equals 0 (B) or 1 (P)), the value of slice_max_mtt_hierarchy_depth_luma is inferred to be equal to sps_max_mtt_hierarchy_depth_inter_slice.

[0072] The reason for the value 2*(CtbLog2SizeY-MinCbLog2SizeY) instead of (CtbLog2SizeY-MinCbLog2SizeY) as specified in VVC draft 6 is that it allows to reach the minimum allowable block size regardless of which partitioning type is used: QT, BT, or TT. In particular, it can only be reached with binary tree (BT) partitioning, which is not the case for the standard constraints currently specified in VVC draft 6. Thus, the advantage of the proposed approach is that it maximizes the compression performance that can be achieved with a VVC encoder, subject to the constraints of the maximum and minimum coded block sizes.

[0073] Maximum MTT depth In this embodiment, max_mtt_hierarchy_depth is specified standardly for all QT levels to provide more flexibility in the partitioning tree. The advantage of specifying the maximum multitype tree depth associated with each level that can be reached by the quadtree leaf is that it allows finely allocating the encoder rate-distortion combinations. Indeed, the rate-distortion search for the optimal coding tree implies a large combination of the encoder search space. It is therefore interesting to fine-tune the multitype coding tree search combinations to obtain a good trade-off between the encoder search and compression performance for all combinations. Allocating a maximum mtt hierarchy depth to each quadtree level provides a way to obtain a better trade-off between the RD search combinations and compression performance. Thus, more flexibility in the standard signaling of the maximum mtt coding tree depth for each quadtree level leads to encoder complexity / compression efficiency trade-offs that are not currently reachable in the VVC Draft 6 specification. [Table 3]

[0074] Here we first signal a syntax element that indicates what the maximum size at which an mtt tree can be started is compared to the minimum quadtree size sps_log2_diff_max_mtt_size_min_qt_size_inter_slice_luma. The maximum size at which an mtt can be started is estimated as follows: max_mtt_size=1<<(sps_log2_diff_max_mtt_size_min_qt_size_inter_slice_luma+MinQtLog2SizeInterY).

[0075] The maximum value of sps_log2_diff_max_mtt_size_min_qt_size_inter_slice_luma is CtbLog2SizeY-MinQtLog2SizeInterY.

[0076] If sps_log2_diff_max_mtt_size_min_qt_size_inter_slice_luma is equal to 0, it means that no mtt splitting is allowed. If it is non-zero, the maximum depth of both BT and TT is signaled for each QT level where mtt is allowed. For each level, the allowed range of sps_max_bt_depth_inter_slice_luma[i] is 0 to 2x(i+MinQtLog2SizeInterY-MinCbLog2SizeY). This last value corresponds to twice the difference between the log2 of the currently considered quadtree leaf node size and the log2 of the minimum coded block size. This ensures that the minimum coded block size can be reached by a binary tree splitting.

[0077] As an example, a partitioning tree can be defined in VVC as follows: [Table 4] - by signalling the following value: -log2_ctu_size_minus5=2 (CTU size is 128) -log2_min_luma_coding_block_size_minus2=0 (the minimum CU size is 4) -sps_log2_diff_min_qt_min_cb_intra_slice_luma=1 (The minimum CU size resulting from a QT split is 8) -sps_log2_diff_max_mtt_size_min_qt_size=2 (The maximum CU size for mtt splitting is 32) -sps_max_bt_depth_inter_slice_luma[0]=2 (2 BT splits allowed for 8x8CU) -sps_max_bt_depth_inter_slice_luma[1]=4 (4 BT splits allowed for 16x16CU) -sps_max_bt_depth_inter_slice_luma[2]=2 (allows 2 BT slices for 32x32CU) The same principle applies to intra_slice_luma and intra_slice_chroma.

[0078] In another embodiment, a maximum allowed hierarchical depth is specified standardly for a multitype tree split of a quadtree leaf, associated with each quadtree level at which a BT or TT is allowed to split the quadtree leaf. Essentially, the coding units corresponding to a quadtree leaf for which an MTT split necessarily is a square CU whose size log2 is comprised between MinQtLog2SizeIntraY and (MinQtLog2SizeIntraY+log2_diff_max_mtt_min_qt_intra_slice_luma).

[0079] Here we define log2_diff_max_mtt_min_qt_intra_slice_luma as the maximum between the signalled values ​​sps_log2_diff_max_bt_min_qt_intra_slice_luma and sps_log2_diff_max_tt_min_qt_intra_slice_luma. For each block size where log2 is between MinQtLog2SizeIntraY and (MinQtLog2SizeIntraY+log2_diff_max_mtt_min_qt_intra_slice_luma), a maximum multitype tree depth is signalled.

[0080] The value sps_max_mtt_hierarchy_depth_intra_slice_luma[i] specifies the maximum hierarchical depth of the multitype tree for emitting CUs corresponding to quadtree leaves. [Table 5]

[0081] Similar to log2_diff_max_mtt_min_qt_intra_slice_luma, the parameter log2_diff_max_mtt_min_qt_inter_slice is defined as the maximum between the signalled values ​​sps_log2_diff_max_bt_min_qt_inter_slice_luma and sps_log2_diff_max_tt_min_qt_inter_slice_luma. For each block size where log2 is between MinQtLog2SizeInterY and (MinQtLog2SizeInterY+log2_diff_max_mtt_min_qt_inter_slice), the maximum multitype tree depth is signalled.

[0082] Similar to log2_diff_max_mtt_min_qt_intra_slice_luma, the parameter log2_diff_max_mtt_min_qt_intra_slice_chroma is defined as the maximum between the signalled values ​​sps_log2_diff_max_bt_min_qt_intra_slice_chroma and sps_log2_diff_max_tt_min_qt_intra_slice_chroma. The maximum multitype tree depth is signalled for each block size where log2 is between MinQtLog2SizeIntraC and (MinQtLog2SizeIntraC+log2_diff_max_mtt_min_qt_intra_slice).

[0083] According to a variant of the embodiment of Table 5, the syntax elements sps_max_mtt_hierarchy_depth_intra_slice_luma_present_flag, sps_max_mtt_hierarchy_depth_inter_slice_luma_present_flag and sps_max_mtt_hierarchy_depth_intra_slice_chroma_present_flag are not included in the SPS specification. [Table 6]

[0084] In another variation, the encoding of the maximum MTT hierarchical depth is indexed by the quadtree depth rather than the log2 of the quadtree leaf size. This may take a slightly different form than in Table 7.

[0085] In a variation of Table 7, the quantity strat_qt_depth_inter_slice is defined as follows: start_qt_depth_inter_slice=CtbLog2SizeY-max(MaxBtLog2SizeY,MaxTtLog2SizeY) During the ceremony, MaxBtLog2SizeY=(MinQtLog2SizeInterY+sps_log2_diff_max_bt_min_qt_inter_slice) MaxTtLog2SizeY=(MinQtLog2SizeY+sps_log2_diff_max_bt_min_qt_inter_slice) Additionally, max_qt_depth_inter_slice is defined as follows: max_qt_depth_inter_slice=CtbLog2SizeY-MinQtLog2SizeInterY

[0086] The quantities start_qt_depth_intra_slice_luma, max_qt_depth_intra_slice_luma, start_qt_depth_intra_slice_chroma, and max_qt_depth_intra_slice_chroma are defined in a similar manner to start_qt_depth_inter_slice and max_qt_depth_inter_slice, except for the intra slice luma and intra slice chroma cases (dual tree case), respectively. [Table 7]

[0087] In yet another embodiment, any of the aforementioned variants proposed herein are also used for coding the slice header. Indeed, in the VVC Draft 6 specification, coding tree parameters signaled in the SPS can be overridden in the slice header, for example according to the syntax table shown in Table 2.

[0088] Note that on the encoder side, the maximum MTT hierarchy depth coded may be upper bounded depending on the depth difference between the log2 of the size of the quadtree leaf node considered and the log2 of the size of the minimum coded block size. This may take the following form: Given a depth value i (an index in one of the loops in Table 7), the maximum mtt hierarchy depth to code may be upper bounded by the value 2*(CtbLog2SizeY-i-MinCbLog2SizeY), where 2*(CtbLog2SizeY-i-MinCbLog2SizeY) represents the number of splits required to reach the minimum block size in both width and height using only BT splits. In fact, to obtain a block half the size in width and height from a given block to split, exactly two symmetric bisection stages are needed. Clipping the value at the upper bound 2*(CtbLog2SizeY-i-MinCbLog2SizeY) may be beneficial in terms of bit savings in coding of SPS and slice headers.

[0089] Furthermore, note that typically allowing the maximum mtt hierarchy depth to range from 0 to the value 2*(CtbLog2SizeY-i-MinCbLog2SizeY) ensures that the minimum coded block size can be reached by BT partitioning.

[0090] Finally, the proposed high-level signaling of the maximum MTT hierarchical depth at each quadtree level is taken into account during the CU-level decoder-side parsing process of the CU partition information.

[0091] To do so, when the te decoder evaluates whether a given bisection or trisection mode is allowed for a current node of a coding tree of a given CTU, it compares the multitype tree depth of the current coding tree node with the maximum multitype tree depth at the quadtree depth associated with the current coding tree node. If the multitype tree depth is greater than or equal to the maximum allowed multitype tree depth at the quadtree depth considered, then all bisection and trisection modes are prohibited at the current tree node. Thus, the decoder infers that the partitioning mode of the considered tree node is different from any bisection or trisection mode.

[0092] The difference with the VVC Draft 6 parsing process of partition information is that in VVC Draft 6, the maximum allowed multitype tree depth of the current tree node does not depend on the quadtree depth associated with the coding tree node being considered. For intra-slice types, it only depends on the slice type and component type.

[0093] Enable split into halves / thirds In this embodiment, two new flags are introduced into the SPS to signal whether BT and TT partitioning is used. Then, if at least one of the two types of partitioning is used, the sps_max_mtt_hierarchy_depth syntax element is coded as shown in Table 8. In a variation of the embodiment of Table 8, sps_bt_enabled_flag is defined as follows: sps_bt_enabled_flag, when equal to 1, specifies that bisection is allowed in the block partitioning coding process. [Table 8]

[0094] In another variation, BT and TT splitting is enabled or disabled differently for intra luma, inter chroma, and intra chroma, allowing more flexibility. In the embodiment shown in Table 9, sps_bt_enabled_flag is defined as follows: sps_bt_enabled_flag equal to 1 specifies that bisection is allowed in the process of encoding block partitions of quadtree leaves of slices with slice_type equal to 2(I) that refer to an SPS. [Table 9]

[0095] Another variation is to disable BT or TT using the sps_log2_diff_max_bt_min_qt or sps_log2_diff_max_tt_min_qt syntax elements. In the current VVC draft 6, BT and TT splitting is enabled together by setting the sps_max_mtt_hierarchy_depth syntax element to a value greater than 0. In the variation of Table 9, sps_log2_diff_max_bt_min_qt and sps_log2_diff_max_bt_min_qt are defined first, and then sps_max_mtt_hierarchy_depth is conditionally parsed. sps_log2_diff_max_bt_min_qt (sps_log2_diff_max_tt_min_qt) is changed to sps_log2_diff_max_bt_min_qt_plus_one (sps_log2_diff_max_tt_min_qt_plus_one), a value of 0 indicates that BT / TT is disabled. Indeed, in this case the maximum BT size is never used, since it is strictly inferior to the minimum QT size. The sps_log2_diff_max_bt_min_qt_plus_one (sps_log2_diff_max_tt_min_qt_plus_one) syntax element is defined as follows: sps_log2_diff_max_bt_min_qt_plus_one_intra_slice_luma specifies the default difference between the base 2 logarithm of the maximum size (width or height) of luma samples of a luma coded block that can be divided using bisection and the minimum size (width or height) of luma samples of a luma leaf block resulting from a quadtree decomposition of a CTU of slice+1 with slice_type equal to 2(I) that references an SPS. If partition_constraints_override_flag is equal to 1, the default difference can be overridden by slice_log2_diff_max_bt_min_qt_luma present in the slice header of a slice that references an SPS. The value of sps_log2_diff_max_bt_min_qt_minus_one_intra_slice_luma must be in the range 0 to CtbLog2SizeY-MinQtLog2SizeIntraY+1, inclusive. If sps_log2_diff_max_bt_min_qt_minus_intra_slice_luma is not present, the value of sps_log2_diff_max_bt_min_qt_intra_slice_luma is inferred to be equal to 0. [Table 10]

[0096] Simplification of adaptive maximum mtt depth In another variation, only two levels of maximum mtt depth are signaled (instead of one per QT level as in the previous embodiment), namely the maximum mtt depth when QT division is permitted, and the maximum mtt depth when no further QT division is permitted. [Table 11]

[0097] In this embodiment, the syntax element sps_max_mtt_hierarchy_depth_before_minqt_inter_slice is signaled first.

[0098] sps_max_mtt_hierarchy_depth_before_minqt_inter_slice specifies the default maximum hierarchy depth of coding units resulting from a multitype tree partition of a quadtree leaf, if this quadtree leaf size is not equal to (strictly larger than) MinQtLog2SizeInterY for slices with slice_type equal to 0 (B) or 1 (P) that reference an SPS. If partition_constraints_override_flag is equal to 1, the default maximum hierarchy depth can be overridden by slice_max_mtt_hierarchy_depth_before_minqt_luma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_before_min_qt_inter_slice must be in the range 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0099] If sps_log2_diff_min_qt_min_cb_inter_slice is not equal to 0, it means that the QT tree stops before reaching the minimum coded block size and therefore more bisections / trisections need to be used to reach the minimum coded block size. Therefore, this sps_log2_diff_min_qt_min_cb_inter_slice value is a condition for parsing the sps_log2_diff_max_hierarchy_depth_after_minqt_intra_slice_luma syntax element.

[0100] sps_max_mtt_hierarchy_depth_after_minqt_inter_slice specifies the default maximum hierarchy depth of coding units resulting from a multitype tree partition of a quadtree leaf if this quadtree leaf size is equal to MinQtLog2SizeInterY for slices with slice_type equal to 0 (B) or 1 (P) that reference an SPS. If partition_constraints_override_ flag is equal to 1, the default maximum hierarchy depth can be overridden by slice_max_mtt_hierarchy_depth_after_minqt_luma present in the slice header of a slice that references an SPS. The value of sps_max_mtt_hierarchy_depth_after_min_qt_inter_slice must be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0101] The same principle applies to intra_slice_luma and intra_slice_chroma.

[0102] The previous embodiments may be used separately or in combination. For example, the embodiment that doubles the hierarchy depth as described above is combined with the embodiment described in Table 11. This typically means that the maximum mtt hierarchy depth is doubled compared to the maximum allowed in VVC draft 6. This takes the following form:

[0103] The value sps_max_mtt_hierarchy_depth_before_minqt_inter_slice ranges from 0 (no splits allowed) to 2*(CtbLog2SizeY-MinCbLog2SizeY).

[0104] The value sps_max_mtt_hierarchy_depth_before_minqt_intra_slice_luma ranges from 0 (no splits allowed) to 2*(CtbLog2SizeY-MinCbLog2SizeY).

[0105] The value of sps_max_mtt_hierarchy_depth_after_minqt_inter_slice ranges from 0 (no splits allowed) to 2*(MinQtLog2SizeY-MinCbLog2SizeY).

[0106] The value range of sps_max_mtt_hierarchy_depth_after_minqt_intra_slice_luma is changed to 0 (no splits allowed) to 2*(MinQtLog2SizeY-MinCbLog2SizeY).

[0107] The value range of sps_max_mtt_hierarchy_depth_before_minqt_intra_slice_chroma is changed to 0 (no splits allowed) to 2*(MinQtLog2SizeY-MinCbLog2SizeY).

[0108] The value range of sps_max_mtt_hierarchy_depth_after_minqt_intra_slice_chroma is changed to 0 (no splits allowed) to 2*(MinQtLog2SizeY-MinCbLog2SizeY).

[0109] In one example, a partitioning tree can be defined as shown in Table 12. [Table 12]

[0110] Maximum value of log2_min_luma_coding_block_size_minus2 syntax element In this embodiment, the sps_max_luma_transform_size_64_flag syntax element is moved after log2_ctu_size_minus5 and before log2_min_luma_coding_block_size_minus2, as shown in Table 13. [Table 13]

[0111] If sps_max_luma_transform_size_64_flag is equal to 1, it specifies that the maximum transform size of luma samples is equal to 64. If sps_max_luma_transform_size_64_flag is equal to 0, it specifies that the maximum transform size of luma samples is equal to 32.

[0112] If CtbSizeY is less than 64, the value of sps_max_luma_transform_size_64_flag is equal to 0.

[0113] The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, and MaxTbSizeY are derived as follows: MinTbLog2SizeY=2 (7-27) MaxTbLog2SizeY=sps_max_luma_transform_size_64_flag?6:5 (7-28) MinTbSizeY=1< <MinTbLog2SizeY (7-29) MaxTbSizeY=1< <MaxTbLog2SizeY

[0114] log2_min_luma_coding_block_size_minus2+2 specifies the minimum luma coding block size.

[0115] In VVC draft 6, the upper limit of the log2_min_luma_coding_block_size_minus2 syntax element is not specified.

[0116] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows: CtbLog2SizeY=log2_ctu_size_minus5+5 (7-15) CtbSizeY=1< <CtbLog2SizeY (7-16) MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2 (7-17) MinCbSizeY=1< <MinCbLog2SizeY (7-18) IbcBufWidthY=128*128 / CtbSizeY (7-19) IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20) VSize=Min(64,CtbSizeY) (7-21)

[0117] The variables CtbWidthC and CtbHeightC, which specify the width and height, respectively, of each chroma CTB's array, are derived as follows: - If chroma_format_idc is equal to 0 (monochrome) or separate_colour_plane_flag is equal to 1, then CtbWidthC and CtbHeightC are both equal to 0. - Otherwise, CtbWidthC and CtbHeightC are derived as follows: CtbWidthC=CtbSizeY / SubWidthC (7-22) CtbHeightC=CtbSizeY / SubHeightC (7-23)

[0118] The proposed changes to the specification of the allowed range of the syntax element log2_min_luma_coding_block_size_minus2 are illustrated in Figure 12. As can be seen from Figure 12, in this embodiment the allowed range of the minimum coding block size is 4 to the maximum transform size.

[0119] According to an alternative method for specifying the limit of the syntax element log2_min_luma_coding_block_size_minus2, it is proposed to specify the maximum possible value of log2_min_luma_coding_block_size_minus2 based on the CTU size.

[0120] So here, the value of log2_min_luma_coding_block_size_minus2 must be in the range of 0 to (CtbLog2SizeY-2). This ensures that each coding block has a size at most equal to the CTU size. It may be larger than the maximum transform size. In such a case, the VVC specification already states that a coding block whose size is larger than the maximum transform size and which is not split into sub-coding units needs to be tiled into transform units in order to code / decode the remaining data.

[0121] The proposed changes to the specification of the allowed range of the syntax element log2_min_luma_coding_block_size_minus2 are illustrated in Figure 13. As can be seen, in this embodiment the allowed range of the minimum coding block size is 4 to the CTU size.

[0122] According to a further embodiment for specifying the limit of the syntax element log2_min_luma_coding_block_size_minus2, it is proposed to specify the maximum possible value of log2_min_luma_coding_block_size_minus2 based on the CTU size and the Virtual Pipeline Decoding Unit (VPDU) size. The VPDU represents the decoding unit assumed in the hardware implementation of the VVC decoder. The VVC decoding process is designed to fully decode and reconstruct each 64x64 picture region, all luma and chroma data within that picture region before starting the decoding and reconstruction of the next 64x64 region in the considered picture.

[0123] In this embodiment, the value of log2_min_luma_coding_block_size_minus2 must be in the range of 0 to (min(CtbLog2SizeY, 6)-2). In other words, the minimum coding block size must be in the range of 0 to min(CtbSizeY, 64), which is exactly equal to the variable VSize (VPDU size) specified in VVC draft 6.

[0124] The advantages of this embodiment are: According to the VVC Draft 6 specification, CtbSize may be equal to 128, and the minimum coded block size (MinCbSizeY) may also be equal to 128. Due to the proposed constraint on the minimum coded block size based on the VPDU size, each 128x128 CTU needs to be split into four 64x64 luma CUs in the luma component. Synchronously, the 64x64 chroma block corresponding to the 128x128 luma CTU needs to be split into four 32x32 chroma CUs. As a result, the coded block size complies with the VPDU constraint.

[0125] The present embodiment solves the above problem with an alternative approach to the previous embodiment, which caps the minimum block size at the maximum transform size.

[0126] Compact slice-level partition constraint override Another embodiment of the present disclosure is to make the coding of slice header partition information more compact than VVC Draft 6.

[0127] In VVC draft 6, the slice header flag partition_constraints_override_flag is coded to indicate that the coding tree configuration signaled in the sequence parameter set is overridden for the considered slice. If this override flag is true, parameters related to the minimum quadtree node size, maximum BT size, maximum TT size, and maximum MTT hierarchical depth level are signaled in the slice header. They are coded respectively for the luma component of the considered slice and also for the chroma component if dual tree coding is active.

[0128] However, in the VTM6 encoder strategy, some of these coding tree parameters are changed in some slices, while others remain unchanged. Thus, in some specific encoding strategies, the VVC Draft 6 slice header syntax specification may cause redundant data to be repeated. Typically, the maximum MTT hierarchical depth information remains unchanged.

[0129] In this embodiment, it is proposed to signal a flag max_mtt_hierarchy_depth_override_flag indicating whether the maximum hierarchy depth parameter is overridden in the slice header. In that case, the slice level maximum hierarchy depth information is coded in the slice header. Otherwise, the slice level maximum hierarchy depth value is set equal to the value of SPS for luma and chroma components (in dual tree case), respectively. Furthermore, the slice level coding of the maximum BT size and maximum MTT size in the form of syntax elements slice_log2_diff_max_bt_min_qt_luma and slice_log2_diff_max_tt_min_qt_luma is no longer dependent on the value of the maximum MTT hierarchy depth, as in VVC draft 6. In case of dual tree coding, this dependency is also removed for the chroma component. The proposed slice header syntax changes are shown in the following table. The advantage of this embodiment is a more compact slice header syntax, resulting in a bitrate saving of up to 0.1% for small video sequences where the overhead linked to the high level syntax cannot be ignored. [Table 14]

[0130] According to a further variant of this embodiment, the minimum quadtree node size information, which corresponds to the maximum quadtree depth, is also coded at slice level based on the flag maximum_hierarchy_depth_override previously signalled in the slice header. This flag maximum_hierarchy_depth_override thus controls the signalling of the minimum QT size and maximum MTT hierarchy depth parameters. The advantage of this variant is an even more compact slice header compared to VVC draft 6. [Table 15]

[0131] Various methods are described herein, each of which includes one or more steps or acts for achieving the described method. Unless a particular order of steps or acts is necessary for the correct operation of the method, the order and / or use of certain steps and / or acts may be altered or combined. Additionally, terms such as "first", "second", etc. may be used in various embodiments to alter elements, components, steps, operations, etc., such as, for example, "first decode" and "second decode". The use of such terms does not imply an altered order of operations, unless specifically required. Thus, in this example, the first decode need not be performed before the second decode, but may occur, for example, before, during, or at an overlapping time period with the second decode.

[0132] Various methods and other aspects described in the present application can be used to modify modules, such as the partitioning, entropy encoding and decoding modules (202, 335, 245, 330) of the video encoder 200 and decoder 300, as shown in Figures 2 and 3. Furthermore, the aspects are not limited to VVC or HEVC, but can be applied, for example, to other standards and recommendations, and extensions of any such standards and recommendations. Unless otherwise indicated or technically excluded, the aspects described in the present application can be used individually or in combination.

[0133] Various numerical values ​​are used in this application. The specific values ​​are for illustrative purposes and the described aspects are not limited to these specific values.

[0134] Various implementations involve decoding. "Decoding" as used in this application may encompass all or part of the processing performed on a received encoded sequence to generate a final output suitable for display, for example. In various embodiments, such processing includes one or more of the processing typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. Whether the phrase "decoding processing" is intended to refer specifically to a subset of operations or to the broader decoding process in general will be clear based on the context of the particular description and will be well understood by one of ordinary skill in the art.

[0135] Various implementations involve encoding. Similar to the above discussion of "decoding," "encoding" as used in this application may encompass, for example, all or part of the processing performed on an input video sequence to generate an encoded bitstream.

[0136] It should be noted that the syntax elements used in this specification are descriptive terms. Therefore, they do not exclude the use of other syntax element names. In the above, the syntax elements SPS and SH are mainly used to illustrate various embodiments. It should be noted that these syntax elements can be arranged in other syntax structures.

[0137] The implementations and aspects described herein may be implemented, for example, in a method or process, an apparatus, a software program, a data stream, or a signal. Even if discussed only in the context of a single implementation (e.g., discussed only as a method), the implementation of the discussed features may also be implemented in other forms (e.g., an apparatus or a program). An apparatus may be implemented, for example, in appropriate hardware, software, and firmware. The method may be implemented, for example, in an apparatus, for example, a processor, which generally refers to a processing device, including a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, for example, computers, mobile phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate the transfer of information between end users.

[0138] References to "one embodiment" or "one implementation" or "one implementation," as well as other variations thereof, mean that a particular feature, structure, characteristic, etc. described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in one implementation" or "in one implementation" in various places throughout this application, as well as any other variations, are not necessarily all referring to the same embodiment.

[0139] Additionally, the application may refer to "determining" various portions of information. Determining information may include, for example, one or more of estimating information, calculating information, predicting information, or retrieving information from a memory.

[0140] Additionally, the application may refer to "accessing" various portions of information. Accessing information may include, for example, one or more of receiving information, retrieving information (e.g., from a memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or inferring information.

[0141] Additionally, the application may refer to "receiving" various portions of information. Receiving, like "accessing," is intended to be a broad term. Receiving information may include, for example, one or more of accessing information or retrieving information (e.g., from a memory). Additionally, "receiving" typically involves, in some manner, during operation, for example, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0142] For example, in the case of "A / B," "A and / or B," and "at least one of A and B," it should be understood that the use of any of the following " / ," "and / or," and "at least one of" is intended to cover the selection of only the first listed option (A), or the selection of only the second listed option (B), or the selection of both options (A and B). As a further example, in the case of "A, B, and / or C" and "at least one of A, B, and C," such language is intended to cover the selection of only the first listed option (A), or the selection of only the second listed option (B), or the selection of only the third listed option (C), or the selection of only the first and second listed options (A and B), or the selection of only the first and third listed options (A and C), or the selection of only the second and third listed options (B and C), or the selection of all three options (A and B and C). This can be expanded to as many items as are listed, as would be apparent to one skilled in the art.

[0143] As will be apparent to one of ordinary skill in the art, implementations may generate a wide variety of signals formatted to carry information that may be, for example, stored or transmitted. The information may include, for example, instructions to perform a method or data generated by one of the described implementations. For example, a signal may be formatted to carry a bit stream of the described embodiments. Such a signal may be formatted, for example, as an electromagnetic wave (e.g., using a radio frequency portion of the spectrum) or as a baseband signal. Formatting may include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information that the signal carries may be, for example, analog or digital information. The signal may be transmitted over a wide variety of different wired or wireless links, as is known. The signal may be stored in a processor-readable medium.

Claims

1. 1. A method comprising: encoding or decoding a value indicative of a maximum allowable depth of a tree structure, the maximum allowable depth being limited by at least twice the difference between a first value and a second value, the first value indicative of a maximum coded block size and the second value indicative of a minimum allowable coded block size; and partitioning a node representing the largest coded block or a partition of the largest coded block into coded blocks using the tree structure, the tree structure using at least one of a horizontal partition and a vertical partition.

2. The method of claim 1 , wherein the tree structure uses at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection.

3. The method of claim 1 or 2, wherein the tree structure excludes a quadtree division.

4. 3. The method of claim 1, further comprising: partitioning the largest coded block into quadtree leaf nodes according to a quadtree structure, the quadtree leaf nodes including the nodes that represent the partitions of the largest coded block.

5. The method according to any one of claims 1 to 4, wherein the first value corresponds to the logarithm to the base 2 of the size of the largest coded block.

6. The method of any one of claims 1 to 5, wherein the second value corresponds to the logarithm to the base 2 of the minimum allowable coded block size.

7. 1. A method comprising: partitioning the largest coding block into quadtree leaf nodes according to a quadtree structure; partitioning the quadtree leaf nodes into coding blocks according to a second tree structure, the second tree structure using at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection; and encoding or decoding a value indicative of a maximum allowed depth of the second tree structure, the maximum allowed depth being dependent on a quadtree level of the quadtree leaf node.

8. The method of claim 7 , wherein the maximum depth is signaled for each quadtree level at which splitting by the second tree structure is permitted.

9. The method of claim 7 or 8, wherein the maximum allowed depth is signaled to a binary tree.

10. The method according to any one of claims 7 to 9, wherein the maximum allowed depth is signalled to a ternary tree.

11. 1. A method comprising: partitioning the largest coding blocks into quadtree leaf nodes by quadtree reconstruction; partitioning the quadtree leaf nodes into coding blocks according to a second tree structure, the second tree structure using at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection; and encoding or decoding a value indicating a maximum allowed depth of the second tree structure, the maximum allowed depth depending on whether the quadtree leaf node is equal to a minimum allowed quadtree tree node size.

12. 12. The method of claim 11, wherein an upper bound on the maximum allowed depth of the second tree structure is based on the maximum coded block size and a minimum allowed coded block size if the quadtree leaf node is larger than the minimum allowed quadtree tree node size.

13. 13. The method of claim 11 or 12, wherein an upper limit on the maximum allowed depth of the second tree structure is based on a size of the minimum allowed quadtree tree node size if the quadtree leaf node is equal to the minimum allowed quadtree tree node size, and a minimum allowed coding block size.

14. 1. A method comprising: partitioning the largest coded block into coded blocks; and (c) encoding or decoding a value indicative of a minimum allowable coded block size, the upper limit of the minimum coded block size being dependent on the smaller of a value and the maximum coded block size.

15. 15. The method of claim 14, wherein the value indicates a size of a virtual pipeline decoding unit (VPDU).

16. 1. A method comprising: partitioning the coding tree blocks into quadtree leaf nodes according to a quadtree structure; partitioning the quadtree leaf nodes into coding blocks according to a second tree structure, the second tree structure using at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection; 13. A method comprising: (1) encoding or decoding at least one of a first signal indicating whether bisection is used in the second tree structure; and (2) a second signal indicating whether trisection is used in the second tree structure.

17. 17. The method of claim 16, further comprising: encoding or decoding a value indicative of a maximum allowable depth of the second tree structure in response to at least one of a bisection and a trisection being used.

18. 18. The method of claim 16 or 17, wherein whether bisection is used is signalled separately for intra and inter.

19. 18. The method of claim 16 or 17, wherein whether bisection is used is signaled separately for luma and chroma.

20. 20. The method of any one of claims 16 to 19, wherein the first signal depends on a first value and a second value, the first value indicating a maximum allowed size of a coding block that can be divided using bisection and the second value indicating a minimum allowed size of a quadtree leaf node.

21. 21. The method of claim 16, wherein the second signal depends on a third value and a fourth value, the first value indicating a maximum allowed size of a coding block that can be divided using third partitioning and the fourth value indicating a minimum allowed size of a quadtree leaf node.

22. 1. A method comprising: partitioning the largest coding blocks into quadtree leaf nodes by quadtree reconstruction; partitioning the quadtree leaf nodes into coding blocks according to a second tree structure, the second tree structure using at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection; and encoding or decoding a flag indicating whether a parameter indicating one or more maximum hierarchical depth parameters has been overridden in the current syntax structure.

23. The method of claim 22 , wherein the current syntax structure corresponds to a slice header.

24. 1. A method comprising: partitioning the largest coding blocks into quadtree leaf nodes by quadtree reconstruction; partitioning the quadtree leaf nodes into coding blocks according to a second tree structure, the second tree structure using at least one of a horizontal bisection, a vertical bisection, a horizontal trisection, and a vertical trisection; and c) encoding or decoding a signal indicative of a minimum quadtree node size.

25. A non-transitory storage medium for storing a video encoded using the method according to any one of claims 1 to 24.

26. 25. An apparatus comprising: a processor; and a non-transitory computer readable storage medium storing instructions that, when executed on the processor, operate to perform a method for video encoding or decoding according to any one of claims 1 to 24.

Images