Quantization for block-face-based video encoding or decoding

By using a subdivision level counter to determine quantization parameters based on sub-block sizes, the method ensures consistent encoding and decoding efficiency for blocks of varying sizes, addressing the challenge of non-uniform quantization groups in advanced video coding standards.

JP7796171B2Active Publication Date: 2026-01-08INTERDIGITAL VC HOLDINGS INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2024100570
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2018-12-21
Filing Date
2024-06-21
Publication Date
2026-01-08
Estimated Expiration
2039-10-21

AI Technical Summary

Technical Problem

Existing video compression technologies face challenges in achieving consistent quantization parameters for blocks of varying sizes, leading to inconsistent encoding and decoding efficiency due to non-uniform quantization groups in advanced video coding standards like VVC.

Method used

Implement a subdivision level counter (subdiv) to determine quantization parameters based on the type and size of sub-blocks, ensuring consistent quantization by associating blocks with similar sizes to the same quantization group.

Benefits of technology

This approach ensures consistent encoding and decoding efficiency by using the same quantization parameter for blocks of similar sizes, addressing the issue of non-uniform quantization groups in advanced video coding standards.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007796171000001
    Figure 0007796171000001
  • Figure 0007796171000002
    Figure 0007796171000002
  • Figure 0007796171000003
    Figure 0007796171000003
Patent Text Reader

Abstract

To provide an encoding or decoding method for improving coding efficiency of a quantization parameter.SOLUTION: A method includes: splitting an image into a plurality of blocks of various sizes; associating a subdivision level counter with each of the blocks, the value of the subdivision level counter for a block representing the size of the block and being used to determine a quantization parameter for the block; propagating the value of the subdivision level counter, for each subdivision and incrementing the value according to the type of the subdivision; performing, when the image is split, an analysis according to the subdivision level counter, a maximal value of subdivision and the type of split, in order to determine the start of a new quantization group; and propagating, if applicable, the current position of the partition to the further split partitions to be stored with these partitions so as to serve in a prediction process when decoding.SELECTED DRAWING: Figure 12
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure is in the field of video compression, and at least one embodiment relates more particularly to determining quantization parameters based on block surfaces. [Background technology]

[0002] To achieve high compression efficiency, image and video coding schemes typically use prediction and transformation to exploit spatial and temporal redundancy in video content. Generally, intra- or inter-prediction is used to exploit correlation within or between frames, and then the difference between the original and predicted block, often denoted as the 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 entropy coding, quantization, transformation, and prediction. Summary of the Invention [Means for solving the problem]

[0003] According to a first aspect of at least one embodiment, a method for coding video includes, when a block of an image is divided into sub-blocks, associating values ​​representing faces of the sub-blocks, and determining a quantization parameter for the sub-blocks based on the values ​​representing the faces of the sub-blocks.

[0004] According to a second aspect of at least one embodiment, a method for decoding video includes, when a block of an image is divided into sub-blocks, associating values ​​representing faces of the sub-blocks, and determining a quantization parameter for the sub-blocks based on the values ​​representing the faces of the sub-blocks.

[0005] According to a third aspect of at least one embodiment, an apparatus including a video encoder for encoding picture data includes, when a block of an image is divided into sub-blocks, associating values ​​representing faces of the sub-blocks, and determining a quantization parameter for the sub-blocks based on the values ​​representing the faces of the sub-blocks.

[0006] According to a fourth aspect of at least one embodiment, an apparatus including a video decoder for decoding picture data includes, when a block of an image is divided into sub-blocks, associating values ​​representing faces of the sub-blocks, and determining a quantization parameter for the sub-blocks based on the values ​​representing the faces of the sub-blocks.

[0007] According to a variant embodiment of the first, second, third or fourth aspect, the value representing the face of the sub-block is a sub-division level counter that is incremented by a value representing a sub-block division type when a block of the image is divided into sub-blocks. According to a further variant embodiment of the first, second, third or fourth aspect, while the sub-division level counter of a sub-block is less than or equal to a maximum sub-division value, a new quantization group is enabled according to the division type. According to a further variant embodiment of the first, second, third or fourth aspect, when the block of the image is divided into sub-blocks according to a ternary division and the sub-division level counter of the smallest sub-block is greater than the maximum sub-division value, a new quantization group is disabled.

[0008] According to a variant embodiment of the first, second, third or fourth aspect or a variant of these embodiments, the increment value is equal to 2 for all sub-blocks of a quad division, 1 for all sub-blocks of a binary division, 2 for the side sub-blocks of a ternary division, and 1 for the central sub-block of a ternary division. According to another variant embodiment of the first, second, third or fourth aspect or a variant of these embodiments, the increment value is equal to 4 for all sub-blocks of a quad division, 2 for all sub-blocks of a binary division, 4 for the side sub-blocks of a ternary division and 2 for the central sub-block, 4 for the smallest sub-block and 1 for the largest sub-block of an asymmetric 1 / 4 binary division, and 3 for the smallest sub-block and 1 for the largest sub-block of an asymmetric 1 / 3 binary division.

[0009] According to a fifth aspect of at least one embodiment, a storage medium stores video bitstream data including at least a syntax data element representing a value representing a side of a sub-block, the sub-block being the result of dividing a block of an image of a video. According to a variant of the fifth embodiment, the value representing the side of the sub-block is a subdivision level counter that is incremented by a value representing a type of division of the sub-block when the block of the image is divided into sub-blocks. According to a further variant of the fifth embodiment, the increment value is equal to 2 for all sub-blocks in a quad division, 1 for all sub-blocks in a binary division, 2 for side sub-blocks in a ternary division, and 1 for a central sub-block in a ternary division.

[0010] According to a sixth aspect of at least one embodiment, there is provided a computer program comprising program code instructions executable by a processor, the computer program performing at least the steps of a method according to the first or second aspect.

[0011] According to a seventh aspect of at least one embodiment, there is provided a computer program product comprising program code instructions stored on a non-transitory computer readable medium and executable by a processor, the computer program product performing at least the steps of a method according to the first aspect or the second aspect. [Brief explanation of the drawings]

[0012] [Figure 1] 1 shows a block diagram of an example of a video encoder 100. [Figure 2] 2 shows a block diagram of an example video decoder 200. [Figure 3] 1 illustrates a block diagram of an example system in which various aspects and embodiments may be implemented. [Figure 4] 1 shows an example of a coding tree unit and a coding tree in the compressed domain. [Figure 5] 1 shows an example of dividing a CTU into coding units, prediction units, and transform units. [Figure 6] For example, we show various types of partitioning as found in VVC. [Figure 7A] 1 shows the effect of repeated division on block size. [Figure 7B] 1 shows the effect of repeated division on block size. [Figure 8] 1 shows various blocks of the same size at different division levels. [Figure 9] Illustrates the use of quantization groups in the HEVC specification. [Figure 10] 1 illustrates at least one embodiment of the use of a subdivision level counter subdiv. [Figure 11A] 10 illustrates an example of the relationship between division type and subdiv increment, according to one embodiment. [Figure 11B] 10 illustrates an example of the relationship between division type and subdiv increment, according to one embodiment. [Figure 11C] 10 illustrates an example of the relationship between division type and subdiv increment, according to one embodiment. [Figure 12] 1 illustrates an example block diagram of a subdiv process, according to one embodiment. [Figure 13A] An example of the value of the subdiv counter when the process is applied to the examples of FIGS. 6 and 7 is shown below. [Figure 13B] An example of the value of the subdiv counter when the process is applied to the examples of FIGS. 6 and 7 is shown below. [Figure 13C] An example of the value of the subdiv counter when the process is applied to the examples of FIGS. 6 and 7 is shown below. [Figure 14A] 1 illustrates different types of asymmetric binary splits. [Figure 14B] 1 illustrates different types of asymmetric binary splits. [Figure 14C] An example of the results of T-division is shown below. [Figure 15A] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a first variant embodiment for AB division. [Figure 15B] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a first variant embodiment for AB division. [Figure 16A] An example of the value of the subdiv counter when the process is applied to two successive asymmetric binary divisions corresponding to ternary divisions is shown below. [Figure 16B] An example of the value of the subdiv counter when the process is applied to two successive asymmetric binary divisions corresponding to ternary divisions is shown below. [Figure 16C] An example of the value of the subdiv counter when the process is applied to two successive asymmetric binary divisions corresponding to ternary divisions is shown below. [Figure 17] 1 shows an example of the value of the subdiv counter when the process is applied to two successive asymmetric 1 / 4 binary divisions in opposite directions using the first variant for AB division. [Figure 18A] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a second variant embodiment for AB division. [Figure 18B] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a second variant embodiment for AB division. [Figure 18C] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a second variant embodiment for AB division. [Figure 18D] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a second variant embodiment for AB division. [Figure 18E] 10 shows an example of the relationship between the type of division and the increment of subdiv according to a second variant embodiment for AB division. [Figure 19] An example of QG start in the case of T division is shown below. [Figure 20] 10 shows an example of the definition of QG for a T-division according to one embodiment that corrects for the QG problem. [Figure 21] FIG. 1 illustrates a block diagram of an example embodiment of a QG identification process. [Figure 22] 10 shows a block diagram of another example embodiment of a QG identification process. [Figure 23] The results of such an embodiment are shown in the context of FIG. [Figure 24] 1 shows a table illustrating an example of a picture parameter set (PPS) syntax according to an embodiment that uses a subdivision level counter. [Figure 25] 1 shows a table that represents an example of syntax for implementing the main embodiment. [Figure 26] 1 shows a table that represents an example of syntax for implementing the main embodiment. [Figure 27] 1 shows a table that represents an example of syntax for implementing the main embodiment. [Figure 28] 1 shows a table that represents an example of syntax for implementing the main embodiment. [Figure 29] 1 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection. [Figure 30]1 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection. [Figure 31] 1 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection. [Figure 32] 10 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection for chroma-related elements. [Figure 33] 10 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection for chroma-related elements. [Figure 34] 10 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection for chroma-related elements. [Figure 35] 10 shows a table representing an example of a syntax for implementing the main embodiment and handling QG start detection for chroma-related elements. DETAILED DESCRIPTION OF THE INVENTION

[0013] In at least one embodiment, video encoding or decoding divides an image into multiple blocks of various sizes, and a subdivision level counter (hereinafter referred to as "subdiv") is associated with each partition and block. The division may be recursive, so that a block may be further divided into multiple blocks (called subblocks), and so on. The value of this counter for a block or subblock represents the size of the block or subblock and is used to determine the quantization parameter of the block or subblock and the quantization group to which the block belongs. As a result, the same quantization parameter is used for blocks of similar sizes, thus providing consistent encoding / decoding.

[0014] For clarity of explanation, the following description describes aspects with respect to embodiments involving video compression technologies such as High Efficiency Video Coding (HEVC) or Versatile Video Coding (VVC), which are emerging standards being developed by the Joint Video Experts Team (JVET), although the described aspects are also applicable to other video processing technologies and standards.

[0015] This application describes various aspects, including tools, features, embodiments, models, techniques, etc. Many of these aspects are specifically described and, in many cases, explained in a manner that may appear limiting, at least to illustrate their individual characteristics. However, this is for the purpose of clarity of explanation and is not intended to limit the application or scope of the aspects. Indeed, all of the various aspects can be combined or interchanged to produce additional aspects. Furthermore, aspects can also be combined or interchanged with aspects described in prior applications. The aspects described and contemplated herein can be implemented in many different forms. Figures 1, 2, and 3 below illustrate some embodiments, but other embodiments are contemplated, and the discussion of Figures 1, 2, and 3 is not intended to limit the scope of implementations. At least one of the aspects generally relates to encoding and decoding video, and at least one other aspect generally relates to transmitting the generated or encoded bitstream. These and other aspects may be implemented as a method, an apparatus, a computer-readable storage medium storing instructions for encoding or decoding video data according to any of the described methods and / or a computer-readable storage medium storing a bitstream generated according to any of the described methods.

[0016] In this application, the terms "reconstruct" and "decode" may be used interchangeably, the terms "pixel" and "sample" may be used interchangeably, and the terms "image," "picture," and "frame" may be used interchangeably. Typically, but not necessarily, the term "reconstruct" is used on the encoder side, while "decode" is used on the decoder side.

[0017] Various methods are described herein, each of which includes one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for the method to operate properly, the order and / or use of specific steps and / or actions can be modified or combined.

[0018] Various methods and other aspects described herein can be used to modify modules, such as the quantization module (130) of the video encoder (100) shown in Figure 1 and / or the inverse quantization module (240) of the video decoder (200) shown in Figure 2. Furthermore, aspects of the present application are not limited to VVC or HEVC, but can be applied, for example, to other standards and recommendations, existing or developed in the future, and extensions of any such standards and recommendations (including VVC and HEVC). Unless otherwise specified or technically excluded, aspects described herein can be used individually or in combination.

[0019] For example, various numerical values ​​for block sizes are used herein, and the specific values ​​are for illustrative purposes only and the described aspects are not limited to those specific values.

[0020] Figure 1 shows a block diagram of an example video encoder 100. Although variations of this encoder 100 are possible, encoder 100 is described below for clarity without describing all anticipated variations. For example, the encoder of Figure 1 may be an HEVC encoder that incorporates improvements to the HEVC standard or an encoder that uses HEVC-like technology, such as the Joint Exploration Model (JEM) encoder being developed by JVET.

[0021] Before being encoded, the video sequence may be subjected to pre-encoding processing (101), for example, applying a color transformation to the input color picture (e.g., from RGB 4:4:4 to YCbCr 4:2:0) or remapping 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 related to the pre-processing and may be added to the bitstream.

[0022] In HEVC, to encode a video sequence having one or more pictures, the picture is divided into one or more slices (102), and each slice may include one or more slice segments. A slice segment consists of a coding unit, a prediction unit, and a transform unit. The HEVC specification distinguishes between "blocks" and "units," where a "block" addresses a specific region (e.g., luma, Y) within a sample array, and a "unit" includes a co-located block of all coded color components (Y, Cb, Cr, or monochrome), syntax elements, and prediction data (e.g., motion vectors) associated with the block.

[0023] For coding in HEVC, a picture is divided into square coding tree blocks (CTBs) with configurable sizes, and a set of consecutive coding tree blocks is grouped into a slice. A coding tree unit (CTU) includes the CTB of a coded color component. The CTB is the root of a quadtree division into coding blocks (CBs), which can be divided into one or more prediction blocks (PBs), forming the root of a quadtree division into transform blocks (TBs). Corresponding to the coding blocks, prediction blocks, and transform blocks, a coding unit (CU) includes a tree-structured set of prediction units (PUs) and transform units (TUs), where a PU includes prediction information for all color components and a TU includes a residual coding syntax structure for each color component. The sizes of the CB, PB, and TB for the luma component apply to the corresponding CU, PU, ​​and TU. In this application, the term "block" may be used to refer to, for example, any of the CTU, CU, PU, ​​TU, CB, PB, and TB. Additionally, "block" can also be used to refer to macroblocks and partitions defined within H.264 / AVC or other video coding standards, and more broadly to refer to arrays of data of various sizes.

[0024] In one example of encoder 100, a picture is encoded by the elements of the encoder as described below. The picture to be encoded is divided (102) into coded units representing portions of the picture and processed. Each unit is coded, for example, using intra or inter mode. If the unit is coded in intra mode, the encoder performs intra prediction (160). In inter mode, motion estimation (175) and motion compensation (170) are performed. The encoder determines (105) whether to use intra or inter mode to code the unit, and indicates the intra / inter decision, for example, with a prediction mode flag. A prediction residual is calculated by subtracting (110) the predicted block from the original image block. The prediction residual is then transformed (125) and quantized (130). The quantized transform coefficients, as well as motion vectors and other syntax elements, are entropy coded (145) to output a bitstream. The encoder can skip the transform and directly apply quantization to the untransformed residual signal. The encoder can bypass both the transform and quantization, i.e., the residual is directly coded without applying the transform or quantization process. The encoder decodes the coded block to provide a reference for further prediction. The quantized transform coefficients are dequantized (140) and inverse transformed (150) to decode the prediction residual. The decoded prediction residual is combined (155) with the predicted block to reconstruct an image block. An in-loop filter (165) is applied to the reconstructed picture to, for example, perform deblocking / sample adaptive offset (SAO) filtering to reduce coding artifacts. The filtered image is stored in a reference picture buffer (180).

[0025] Figure 2 shows a block diagram of an example video decoder 200. Variations of this decoder 200 are possible, and decoder 200 is described below for clarity without describing all anticipated variations. For example, the decoder of Figure 1 may be an HEVC decoder that incorporates improvements to the HEVC standard or a decoder that uses HEVC-like technology, such as the JEM decoder being developed by JVET.

[0026] In decoder 200, the bitstream is decoded by decoder elements as described below. Video decoder 200 generally performs a decoding path that is the inverse of the encoding path described in FIG. 1. Encoder 100 also generally performs video decoding as part of encoding video data. Specifically, the decoder's input includes a video bitstream, such as may be generated by video encoder 100, including syntax data elements that allow the video to be reconstructed. The bitstream is first entropy decoded (230) to obtain transform coefficients, motion vectors, and other coded information. Picture partition information indicates how the picture is partitioned. Thus, the decoder can partition the picture according to the decoded picture partition information (235). The transform coefficients are dequantized (240) and inverse transformed (250) to decode the prediction residual. The decoded prediction residual is combined (255) with the predicted block to reconstruct the image block. The predicted block (270) can result from intra prediction (260) or motion-compensated prediction (i.e., inter prediction) (275). An in-loop filter (265) is applied to the reconstructed image. The filtered image is stored in a reference picture buffer (280). The decoded picture can further undergo post-decoding processing (285), such as an inverse color transform (e.g., YCbCr 4:2:0 to RGB 4:4:4) or inverse remapping, which reverses the remapping process performed in the pre-encoding processing (101). The post-decoding processing can use metadata derived in the pre-encoding processing and signaled in the bitstream.

[0027] FIG. 3 illustrates a block diagram of an example system in which various aspects and embodiments may be implemented. System 1000 may be implemented 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, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected consumer electronics, and servers. Elements of system 1000 may be implemented singly or in combination within a single integrated circuit (IC), multiple ICs, and / or separate components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 1000 are distributed across multiple ICs and / or separate components. In various embodiments, system 1000 is communicatively coupled to one or more other systems or other electronic devices, for example, via a communication bus or by dedicated input and / or output ports. In various embodiments, system 1000 is configured to implement one or more of the aspects described herein.

[0028] The system 1000 includes at least one processor 1010 configured to execute instructions loaded therein to implement various aspects described herein, for example. The processor 1010 may include embedded memory, input / output interfaces, and various other circuits known in the art. The system 1000 includes at least one memory 1020 (e.g., a volatile memory device and / or a nonvolatile memory device). The system 1000 includes storage 1040, which may include nonvolatile and / or volatile memory including, but not limited to, electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), programmable read-only memory (PROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash, magnetic disk drives, and / or optical disk drives. The storage 1040 may include, by way of non-limiting example, internal storage, additional storage (including removable and non-removable storage), and / or network-accessible storage.

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

[0030] Program code loaded onto the processor 1010 or the encoder / decoder 1030 to perform various aspects described herein may be stored in storage 1040 and then loaded onto the memory 1020 for execution by the processor 1010. According to various embodiments, one or more of the processor 1010, memory 1020, storage 1040, and encoder / decoder module 1030 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 of processing of equations, formulas, operations, and computational logic.

[0031] In some embodiments, memory internal to the processor 1010 and / or encoder / decoder module 1030 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 unit (e.g., the processing unit may be the processor 1010 or the encoder / decoder module 1030) is used for one or more of these functions. The external memory may be memory 1020 and / or storage 1040, such as dynamic volatile memory and / or non-volatile flash memory. In some embodiments, external non-volatile flash memory is used, for example, to store the television's operating system. In at least one embodiment, high-speed external dynamic volatile memory, such as RAM, is used as working memory for video coding and decoding operations, such as MPEG-2 (MPEG refers to the Moving Picture Experts Group; MPEG-2 is also known as ISO / IEC 13818, 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC, or VVC.

[0032] Input to the elements of system 1000 may be provided by various input devices, as shown in block 1130. Such input devices include, but are not limited to, (i) an RF section that receives RF (radio frequency) signals transmitted wirelessly, for example, by a broadcaster, (ii) a component (COMP) input terminal (or set of COMP input terminals), (iii) a universal serial bus (USB) input terminal, and / or (iv) a high-definition multimedia interface (HDMI) input terminal. Other examples not shown in FIG. 3 include composite video.

[0033] In various embodiments, the input devices of block 1130 have associated individual input processing elements 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 bandlimiting a signal to a frequency band), (ii) downconverting the selected signal, (iii) bandlimiting again to a narrower frequency band to select a signal frequency band, which may be referred to as a channel in a particular embodiment (for example), (iv) demodulating the downconverted and bandlimited signal, (v) performing error correction, and (vi) demultiplexing to select a desired stream of data packets. The RF section of various embodiments includes one or more elements for performing these functions, such as a frequency selector, a signal selector, a bandlimiter, a channel selector, a filter, a downconverter, a demodulator, an error corrector, and a demultiplexer. The RF section may include, for example, a tuner that performs various of these functions, including downconverting a received signal to a lower frequency (e.g., an intermediate frequency or a frequency close to baseband) or to baseband. In some set-top box embodiments, the RF section and its associated input processing elements receive RF signals transmitted over a wired (e.g., cable) medium, filter them to a desired frequency band, downconvert them, and filter them again to perform frequency selection. Various embodiments rearrange the order of the above-described (and other) elements, remove some of them, and / or add other elements that perform similar or different functions. Adding elements may include inserting elements between existing elements, such as inserting amplifiers and analog-to-digital converters. In various embodiments, the RF section includes an antenna. Additionally, the USB and / or HDMI terminals may include individual interface processors for connecting system 1000 to other electronic devices across the USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, may be implemented as needed, for example, in separate input processing ICs or within processor 1010.Similarly, aspects of the USB or HDMI interface processing may be implemented in a separate interface IC or within the processor 1010. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements including, for example, the processor 1010 and an encoder / decoder 1030 operating in combination with memory and storage elements to process the data stream as needed for presentation on an output device.

[0034] The various elements of system 1000 may be provided within a unitary housing in which the various elements may be interconnected and data may be transmitted therebetween using any suitable connection arrangement, such as an internal bus known in the art, including an Inter-IC (I2C) bus, wiring, and printed circuit boards.

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

[0036] In various embodiments, data is streamed or provided to system 1000 using a wireless network such as a Wi-Fi network, e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). The Wi-Fi signal in these embodiments is received over communication channel 1060 and communication interface 1050, which are adapted for Wi-Fi communication. Communication channel 1060 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 system 1000 using a set-top box that delivers data over the HDMI connection of input block 1130. Still other embodiments provide streamed data to system 1000 using the RF connection of input block 1130. As indicated above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, such as a cellular network or a Bluetooth network.

[0037] System 1000 can provide output signals to various output devices, including a display 1100, speakers 1110, and other peripherals 1120. Display 1100 in various embodiments includes, for example, one or more of a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. Display 1100 can be, for example, a television, a laptop, a cell phone, or other device. Display 1100 can be integrated with other components (e.g., as in a smartphone) or can be separate (e.g., an external monitor for a laptop). In various example embodiments, other peripherals 1120 include one or more of a stand-alone digital video disc (or digital versatile disc) (DVR in both terms), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripherals 1120 to provide functionality based on the output of system 1000. For example, a disc player performs the function of playing the output of system 1000.

[0038] In various embodiments, control signals are communicated between system 1000 and display 1100, speakers 1110, or other peripheral devices 1120 using signaling such as AV.Link, Consumer Electronics Control (CEC), or other communication protocols that allow inter-device control with or without user intervention. Output devices may be communicatively coupled to system 1000 via dedicated connections through individual interfaces 1070, 1080, and 1090. Alternatively, output devices may be connected to system 1000 using communication channel 1060 via communication interface 1050. Display 1100 and speakers 1110 may be integrated into a single unit with other components of system 1000 within an electronic device such as, for example, a television. In various embodiments, display interface 1070 includes a display driver, such as, for example, a timing controller (T Con) chip.

[0039] For example, if the RF portion of input 1130 is part of a separate set-top box, display 1100 and speakers 1110 can alternatively be separate from one or more of the other components. In various embodiments where display 1100 and speakers 1110 are external components, the output signal can be provided by a dedicated output connection including, for example, an HDMI port, a USB port, or a COMP output.

[0040] The embodiments may be performed by computer software or hardware implemented by the processor 1010, or a combination of hardware and software. As a non-limiting example, the embodiments may be implemented by one or more integrated circuits. The memory 1020 may be of any type suitable for the technical environment and may be implemented using any suitable data storage technology, including, by way of non-limiting examples, optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and removable memory. The processor 1010 may be of any type suitable for the technical environment and may include, by way of non-limiting examples, one or more of a microprocessor, a general-purpose computer, a special-purpose computer, and a processor based on a multi-core architecture.

[0041] Figure 4 shows an example of a coding tree unit and a coding tree in the compressed domain. In the HEVC video compression standard, a picture is divided into so-called coding tree units (CTUs), and the size of a CTU is, for example, 64x64, 128x128, or 256x256 pixels. Each CTU is represented by a coding tree in the compressed domain. This is a quadtree division of the CTU, and each leaf is called a coding unit (CU).

[0042] 5 shows an example of dividing a CTU into coding units, prediction units, and transform units. Some intra prediction parameters or inter prediction parameters (prediction information) are assigned to each CU. To this end, the CU is spatially divided into one or more prediction units (PUs), and some prediction information is assigned to each PU. The intra coding mode or inter coding mode is specified at the CU level.

[0043] Video codecs divide a picture into square or rectangular blocks, traditionally named coding units (CUs) or transform units. The division can be recursive. Thus, the division depth of a current block refers to the number of recursive divisions to obtain the current block. These blocks can then be predicted, and the residual (the difference between the original and the prediction) is transformed to calculate frequency coefficients. On the encoder side, quantization typically involves dividing the resulting transformed coefficients by a specific quantization scale, also named the quantization step size (Qstep). The decoder then multiplies the result by the same Qstep to restore an approximation of the original coefficients.

[0044] Typically, a quantization parameter (QP) is used to determine the quantization step size Qstep. In the example of HEVC, QP can take 52 values ​​from 0 to 51 (QP range). An increase of 1 in QP means that the quantization step size Qstep increases by about 12% (i.e., 2 1 / 6 ) means to increase. In the HEVC example, the relationship between the resulting QP and the equivalent quantization step size is given by the following equation (the "equal" sign means integer equality): Qstep(QP)=(2 1 / 6 ) QP-4 (Formula 1)

[0045] In the embodiments described below, functions and QP ranges other than those defined in the above (Equation 1) can be used. For example, in VVC, the QP range is extended to 63.

[0046] In the following, the term "block" is used, which can be equally replaced by the term "CU" which groups several blocks, for example a luma block and / or a chroma block or three RGB blocks.

[0047] Local adjustment of the quantization step is typically possible by specifying an offset (QP delta) from the QP of the current picture (or a portion thereof, such as a slice). In the HEVC example, a QP delta can be specified for each group of blocks, called a "quantization group" (QG), defined by a given maximum partition depth (the diff_cu_qp_delta_depth syntax element allowed in a picture parameter set); that is, all blocks resulting from further partitioning belong to the same quantization group and share the same QP (more precisely, share the same QP prediction and specify at most one QP delta). In the HEVC example, all blocks at a given partition depth have the same size because all partitions are quad partitions (Q-partitions), thus resulting in uniform QP values ​​for blocks of the same size.

[0048] FIG. 6 illustrates various types of partitioning, such as those found in VVC. In an example codec such as VVC, in addition to Q partitioning, other types of partitioning may exist, including binary partitioning (B partitioning), ternary partitioning (T partitioning), and asymmetric binary partitioning (AB partitioning). In this diagram, Q partitioning is indicated by dashed lines, and other types of partitioning are indicated by chain lines. The top-level Q partitioning defines four blocks of the same size. In the second-level partitioning, each of the blocks resulting from Q partitioning is partitioned using a different type of partitioning: the top-left block is partitioned using AB partitioning, the top-right block is partitioned using T partitioning, the bottom-left block is partitioned using Q partitioning, and the bottom-right block is partitioned using B partitioning. These partitions result in blocks that may have different sizes at the same partitioning depth (second level). In fact, block 61 of the AB partitioning block is larger than block 62 of the T partitioning, or block 63 of the Q partitioning, or block 64 of the B partitioning block. Although all of these blocks are at the same level, the sizes of these blocks are not identical and may be very different after multiple partitionings. Thus, the visual importance of blocks, which is at least partly related to the size of the blocks, is not uniform.

[0049] 7A and 7B show the effect of repeated partitioning on block size. FIG. 7B shows repeated horizontal and vertical ternary partitioning. In this case, the central block (74) is much larger than the corner blocks (73) while having the same partitioning depth. Therefore, using partitioning depth information to define quantization groups may result in quantization groups with uneven sizes, which may lead to undesirable results compared to the HEVC principle where the QP granularity (quantization group size) is the same throughout the entire picture or slice. FIG. 7A shows repeated horizontal and vertical AB partitioning, which causes the same problem in blocks 71 and 72.

[0050] Figure 8 shows various blocks of the same size at different division levels. In fact, the same block size can be obtained at different division depths according to the type of division, as shown in Figure 7, and the numbers in the blocks indicate the division depth for each block. In these examples, blocks with 1 / 16th the surface of the parent block have a division depth of 2 (bottom-left block 81) or 3 (bottom-right block 82).

[0051] Figure 9 illustrates the use of quantization groups in the HEVC specification. The HEVC specification includes QP delta parsing that is separate from QP prediction. Detecting a QG start enables a new prediction and a new QP delta. To do this, if the partition depth is less than or equal to a given threshold, depthLimit, signaled in the stream, a flag (IsCuQpDeltaCoded) is set to false. Then, in a transform unit (TU), if the block residual is non-empty (and QP offset signaling is enabled at a high level) and IsCuQpDeltaCoded remains false, this flag is set to true and the QP offset is coded / decoded. In the decoding process, the derivation of the QP for each block involves QP prediction using the neighboring blocks above and to the left of the upper-left corner of the quantization group. The position of this upper-left corner is determined using a simple alignment of the current block position on the QG grid, as shown in Figure 9. This approach works and is consistent with the previous point, because all partitions are quad partitions, and therefore the QGs have the same (minimum) size and are aligned on a grid that matches the partition depth constraint. However, when using video coding with a different partition type than the Q partition introduced above, such as that used in VVC, such a simple derivation of the QG's location is no longer correct, since different partition types result in partitions of various sizes. The blocks at a given partition depth no longer form a regular grid.

[0052] The embodiments described below are devised with the above in mind.

[0053] Subdivision Level Counter 10 illustrates at least one embodiment of the use of a subdivision level counter. Such a counter (hereinafter referred to as "subdiv") is closely related to the surface of a block or at least represents the size of the block, and thus represents the surface of the block or also the number of samples of the block. When an image is divided into multiple blocks of various sizes, a subdivision level counter (hereinafter referred to as "subdiv") is associated with each partition and block. The subdiv value for a block is determined according to at least the type of division. The subdiv value can be used to determine the quantization parameter of the block and the quantization group to which the block belongs. As a result, the same quantization parameter is used for blocks of similar sizes, thus providing consistent encoding / decoding.

[0054] In at least one embodiment, when a partition is split, an analysis is performed according to the subdivision level counter subdiv, the maximum subdivision level, and the type of split to determine the start of a new quantization group, and if applicable, the current position of the partition is propagated to further split partitions to be stored with those partitions and to aid in the prediction process during decoding.

[0055] In at least one embodiment, a recursive process assigns each block a subdivision level counter subdiv (a positive integer value). To do so, the process first initializes subdiv to zero at the root of the partitioning tree. Then, for each partition, the process propagates the subdiv value to each created partition (conventionally called a subblock) after incrementing it from the previous subdiv value, where the increment value depends on the type of partition and the partition's position within the partition. During the partitioning of a block or subblock, a subdivision level is added to each subpartition in addition to the partition depth. The subdivision level is incremented from 1 at the parent node depending on the type of partition and the number of partitions.

[0056] Such a recursive partitioning function is shown by S1 in Figure 10. After performing other functions related to the conventional partitioning function in S11, a subdiv value is determined in S12 based on the type of partition, and the partition is recursively divided in S13 while adding the subdiv value to each sub-partition. Hereinafter, this overall process will be referred to as the subdiv process.

[0057] The encoder 100 of FIG. 1, the decoder 200 of FIG. 2 and the system 1000 of FIG. 3 are adapted to implement at least one of the embodiments described herein and are therefore configured to handle the subdiv counter with the subdiv process.

[0058] 11A, 11B, and 11C show examples of the relationship between division type and subdiv increments according to one embodiment. In at least one embodiment, the division types considered are Q-division, B-division, and T-division, with the corresponding increments as follows: - For Q-partition: incQ=+2 for all partitions in the quad-partition (Figure 11A) - for B division: incB=+1 for all partitions of the binary division, which can be horizontal or vertical (Fig. 11B) - for T division: incTS=+2 for the side partitions of the ternary division, which can be horizontal or vertical, incTC=+1 for the central partition (Fig. 11C)

[0059] FIG. 12 shows an example block diagram of a subdiv process according to one embodiment. In this diagram, the increments of the subdiv parameters are generally indicated by incQ for Q-partition, incB for B-partition, and incTS and incTC for T-partition, and their values ​​are determined as introduced above. If the type of partition is determined to be Q-partition in step 401, the subdiv values ​​of all four sub-partitions are incremented by incQ=+2 in step 403. If the type of partition is determined to be B-partition in step 402, the subdiv values ​​of both sub-partitions are incremented by incB=+1 in step 405. If the type of partition is determined to be T-partition in step 404, the subdiv values ​​of the horizontal partitions are incremented by incTS=+2 and the subdiv values ​​of the horizontal partitions are incremented by incTC=+1 in step 407.

[0060] Figures 13A, 13B and 13C show example values ​​of the subdiv counter when applying the process to the examples of Figures 6 and 7. However, in this figure, the AB split of the top left block is replaced with no split, because the embodiment of Figure 11 does not handle AB split partitions. It is recognized that the subdiv value is much more related to the actual block size than the split depth parameter.

[0061] One application of this principle is used during quantization: blocks with the same subdiv value have the same plane, and therefore are assigned the same number of samples. Thus, in at least one embodiment, the specification of the quantization group is related to the subdiv value of the coding group under consideration. In one embodiment, the determination of the quantization group may be based on comparing the subdiv value to a maximum subdiv value (referred to herein as diff_cu_qp_delta_subdiv) signaled at a higher level (e.g., in the PPS, slice header, tile group header, or tile header). For example, a quantization group is specified as the set of blocks resulting from dividing a parent block with subdiv >= diff_cu_qp_delta_subdiv. Such a set of blocks forms the same quantization group. The above subdiv derivation process results in quantization groups having the same number of samples (=same plane), or even larger if the subdiv limit has not been reached (insufficient division). For example, in Figure 13A, the bottom left block and the top right block do not have the same shape, but they have similar surfaces and share the same subdiv value. Furthermore, this gives similar behavior to HEVC. In fact, if there is only Q partition, this method results in the same quantization groups as HEVC.

[0062] In at least one embodiment, the number of samples (=faces) in a block is easily calculated from the subdiv value as follows: block_surface=CTB_surface>>subdiv

[0063] In another embodiment, subdiv may be useful for other purposes as well, one example being to derive some CABAC context ids (e.g., for split modes) based on the subdiv value.

[0064] First variant of AB division At least one embodiment relates to coding video using all the partition types shown in FIG. 6, and thus using AB partitions in addition to the previous Q, B and T partitions.

[0065] 14A and 14B show different types of asymmetric binary partitioning, in which the number of samples on both sides is not divided by a power of 2, i.e., the ratio is 3 / 4 and 1 / 4, or 2 / 3 and 1 / 3 when a 3 / 4 partition is further divided into AB in the same direction.

[0066] Furthermore, two successive asymmetric binary divisions corresponding to the ternary division shall give the same subdivision levels as the uniform ternary division shown in FIG. 14C.

[0067] In at least one embodiment, a method that conforms to the increments described above for Q-, B-, and T-decompositions and subsequently estimates the CTB / block face ratio by 2^subdiv applies the following subdiv increments for the AB-decomposition: - For AB division of 1 / 4: incAB1=+0 for the larger part, incAB2=+2 for the smaller part - For AB division of 1 / 3: incAB3=+1 for the larger part, incAB4=+2 for the smaller part

[0068] Figures 15A and 15B show an example of the relationship between the type of division and the subdiv increment according to a first variant embodiment for an AB division. Figures 16A, 16B and 16C show an example of the value of the subdiv counter when the process is applied to two consecutive asymmetric binary divisions corresponding to ternary divisions.

[0069] Second variant of AB division Figure 17 shows an example of the values ​​of the subdiv counter when applying the process to two successive asymmetric 1 / 4 binary divisions in opposite directions using the first variant for AB division. In this case, as shown in Figure 17, the successive 1 / 4 AB divisions in opposite directions result in a large portion of the subdiv not being incremented (top right block) despite a significant reduction in size (56% of the original surface).

[0070] 18A, 18B, 18C, 18D, and 18E show examples of the relationship between division type and subdiv increment according to a second variant embodiment for AB division. In this embodiment, the subdiv increment is modified for all division types as follows: incQ=+4 for all partitions of the quad division (Fig. 18A), incB=+2 for all partitions of horizontal binary division (FIG. 18B) or vertical (not shown), incTS=+4 for the side partitions of the ternary division (which can be vertical or horizontal as shown in FIG. 18C) and intT2=+2 for the central partition, - for a vertical AB division of 1 / 4, incAB1=+1 for the larger part of the AB division of 1 / 4, and incAB2=+4 for the smaller part (similarly for the horizontal), as shown in Figure 18D; - As shown in Figure 18E for a vertical 1 / 3 AB division, incAB3=+1 for the larger part of the 1 / 3 AB division and incAB4=+3 for the smaller part (similarly for the horizontal).

[0071] Using this variant, an equal AB partition and a ternary partition still get the same subdiv, and the ratio of CTB / block surface is close to 2^(subdiv / 2). Therefore, the following simple calculation can be used to calculate an estimate of the block surface: block_surface ≒ CTB_surface >> (subdiv / 2). In the presence of an asymmetric binary partition, partitions with the same subdiv are closer in size than in the first variant.

[0072] Influence on quantization group definition As already discussed with respect to Figure 9, a unified detection of the start of a quantization group (hereafter referred to as QG start) is required for QP delta parsing and for QP prediction. In at least one embodiment, the detection of the QG start is done as follows: Two high-level syntax elements are read from the bitstream (e.g., in the PPS, slice header, tile group header, tile header): cu_qp_delta_enabled_flag (a flag that allows activating or deactivating the use of delta QP coding) and cu_qp_delta_subdiv (a parameter that specifies the subdiv limit used to set the QG). When cu_qp_delta_enabled_flag is equal to true, the following applies:

[0073] During the division process, if subdiv<=cu_qp_delta_subdiv, set a flag (CuQpDeltaCoding) to true to indicate QG start and save the current position as the current QG origin. As soon as the QP delta is coded (or decoded), reset the CuQpDeltaCoding flag (to false).

[0074] However, by introducing a new type of partition, the definition of the QG becomes non-trivial due to the various sizes of partitions that result from T or AB partitions: the QG cannot be simply defined as the smallest partition with a subdiv value less than or equal to cu_qp_delta_subdiv.

[0075] Figure 19 shows an example of QG initiation for T-partitioning. In this example, the limit value of cu_qp_delta_subdiv is set to 1 to simplify the problem. Using the subdiv increments defined in Figure 11C and assuming the parent partition had subdiv=0, T-partitioning results in subdiv=2 for the side partitions and 1 for the center partition (left side of Figure 19). The center partition should be a QG (its subdiv is within the limit: subdiv<=cu_qp_delta_subdiv), but the side partition should not be a QG group (because its subdiv value exceeds cu_qp_delta_subdiv), implying that the QG to which the side partition belongs is (or is not) its parent partition. This would result in overlapping QGs (or holes in QGs), which is not possible (a block should have a single QP prediction, i.e., belong to only one QG). This problem can be corrected as explained below.

[0076] Figure 20 shows an example of the definition of QG for T-partition according to one embodiment that corrects for the QG problem. According to this embodiment, in T-partition: - The subdiv value of the first partition is greater than cu_qp_delta_subdiv, so the QG start flag is not modified, but with its position as the QG origin, the QG start flag is already set to true by the parent partition. - For the middle partition, its subdiv value is equal to cu_qp_delta_subdiv, so the start QG flag is set to true, which means we start a new QG at the middle position, which means the first partition (left side) is the completed QG. - The subdiv value of the last partition is greater than cu_qp_delta_subdiv, therefore the QG start flag is not set, which means that the last partition is an element of the previous QG, i.e. the middle partition and the last partition form a single QG.

[0077] Regarding the AB split, - If the smaller partition is first, there will be two QGs, - If the smaller partition is the last, there is a single QG, - Two consecutive AB splits are equivalent to a T split.

[0078] The following sections use the syntax described in the JVET-L1001 document as examples of these syntax functions in VVC (Section 7.3.4.2 specifying the function coding_tree_unit(), Section 7.3.4.3 specifying the function coding_quadtree(), and Section 7.3.4.4 specifying the function multi_type_tree()).

[0079] Figure 21 shows a block diagram of an example embodiment of the QG identification process. In this embodiment, the subdiv parameter is added to the coding_quadtree() and multi_type_tree() syntaxes (or equivalent syntaxes hereinafter collectively referred to as coding_tree). To minimize syntax changes, the QG detection flag is shown in HEVC style, i.e., by retaining the IsCuQpDeltaCoded flag instead of the CuQpDeltaCoding proposed above.

[0080] In step 501, the partitioning starts from CTU with the subdiv parameter set to 0. At the coding tree level, in step 502, if cu_qp_delta_enabled_flag is enabled and subdiv<=cu_qp_delta_subdiv, some values ​​are initialized in step 503, including IsCuQpDeltaCoded=0, CuQpDeltaVal=0, and the current position of the block is stored as the QG origin, i.e., (xQg, yQg)=(x0, y0). Step 504 checks whether a subdivision is appropriate. If so, in step 505, call child partition(coding_tree) with parameters according to the partition type. For the corresponding sub-partitions, the subdiv parameter for each sub-partition is incremented by a value incX corresponding to the sub-partition type according to one of the above embodiments (e.g., incX is +1 for B partition, +2 for Q partition, etc.). If no further splitting is applied in step 504 (meaning a leaf of the coding tree has been reached), the process moves to the CU and TU level. In step 506, if cu_qp_delta_enabled_flag is equal to 1, IsCuQpDeltaCoded is equal to 0, and the conditions for coding QP delta are met (e.g., non-zero coefficients are coded = cbf is non-zero), then in step 507, the QP delta is coded (or decoded), CuQpDeltaVal is updated accordingly, and IsCuQpDeltaCoded is set to 1. Otherwise, in step 508, no specific action is taken.

[0081] 22 shows a block diagram of another example embodiment of the QG identification process. In this embodiment, we propose to further suppress the creation of new QGs by adding an additional condition to the detection of QG onset. When a child node detects that the limit is exceeded, the parent node disables the detection of QG onset for all children. This results in giving more regular QGs.

[0082] To do this, the QG flag is passed as a parameter to the coding_tree() syntax. In step 601, the splitting starts from CTU with 0 as the subdiv parameter and 1 as the QG flag parameter. At the coding tree level, if QG flag is equal to true and subdiv<=cu_qp_delta_subdiv in step 602, some values ​​are initialized in step 603, including CuQpDeltaCoding=cu_qp_delta_enabled_flag, CuQpDeltaVal=0, and the current position of the block is stored as the QG origin, i.e., (xQg, yQg)=(x0, y0). Step 604 checks whether a subdivision is appropriate. If so, step 605 calls the child split(coding_tree) with parameters according to the type of splitting. For the corresponding sub-partition, increment the subdiv parameter for each sub-partition by a value incX according to one of the above embodiments, where X is the type of sub-partition (e.g., +1 for B partition). If the next partition cannot exceed the limit, and therefore subdiv+incMax<=cu_qp_delta_subdiv, set the QG flag parameter, where incMax is the maximum possible increment for the next partition considered. If no further partitions apply in step 604 (meaning a leaf of the coding tree has been reached), the process moves to the CU and TU level. In step 606, if CuQpDeltaCoding is equal to 1 and the conditions for coding the QP delta are met (e.g., non-zero coefficients are coded = cbf is non-zero), code (or decode) the QP delta in step 607, update CuQpDeltaVal accordingly, and set CuQpDeltaCoding to 0. Otherwise, step 608 takes no specific action.

[0083] Figure 23 shows the result of such an embodiment in the situation of Figure 19. There is no inconsistency between QGs at the level of ternary partitioning, thus leading to better results. In other words, we propose to prevent all subpartitions of a given node from starting a new QG if any of its subpartitions has a subdiv value that exceeds the subdiv limit. This is done by defining a new parameter called qgEnable, which is passed to the multi_type_tree() syntax function. qgEnable is initially equal to true, but is set to false for all children of a ternary partition if a horizontal partition has a subdiv value that exceeds the subdiv limit. qgEnable is used as an additional condition for starting a new QG (and consequently preserving the QG origin and enabling QP delta coding). To merge conditions and simplify the syntax, we also propose to invert the logic of IsCuQpDeltaCoded (renamed CuQpDeltaCoding).

[0084] Other coding and decoding processes that use quantization groups can use the same principle with the same advantages, for example in VVC where no coding_quadtree is found within the multi_type_tree, the use of QG parameters can be restricted to the multi_type_tree.

[0085] Furthermore, the derivation process of QP can be the same as HEVC (paragraph 8.6.1 of the HEVC specification described in JCTVC-W1005-v4), except that xQg and yQg are given rather than derived from the current block position.

[0086] At least one embodiment uses on-the-fly CU QP derivation enabled by adding an internal flag CuQpPredict that is set to 1 upon detection of QG onset (e.g., if CuQpDeltaCoding is equal to 1, then the xQg, yQg and CuQpDeltaVal variables are unnecessary and can be removed); if CuQpPredict is set in a CU, predict the QP, assign it to the QpY variable and reset the CuQpPredict flag. If CuQpDeltaCoding is 1 in a TU and a QP delta is present, QpY is incremented by the value of the decoded delta and CuQpDeltaCoding is reset.

[0087] Syntax Elements and Semantics In at least one embodiment, the subdiv process is implemented by using a specific syntax to signal the value of the subdiv level counter. The coded syntax elements described below are based on HEVC or VVC (see [JVET_K1001]), with changes highlighted with a gray background.

[0088] The first change is to rename diff_cu_qp_delta_depth to cu_qp_delta_subdiv and change the semantics description accordingly. The derived variable Log2MinCuQpDeltaSize is removed.

[0089] Figure 24 shows a table representing an example of the syntax of a picture parameter set (PPS) according to an embodiment that uses a subdivision level counter. In this table, cu_qp_delta_enabled_flag equal to 1 specifies that the cu_qp_delta_subdiv syntax element is present in the PPS and that cu_qp_delta_abs may be present in the syntax of the transform unit. cu_qp_delta_enabled_flag equal to 0 specifies that the cu_qp_delta_subdiv syntax element is not present in the PPS and that cu_qp_delta_abs is not present in the syntax of the transform unit. cu_qp_delta_subdiv specifies the maximum cbSubdiv value for coded units that carry cu_qp_delta_abs and cu_qp_delta_sign_flag. If not present, the value of cu_qp_delta_subdiv is inferred to be equal to 0.

[0090] Syntax Elements and Semantics for the Main Embodiment Figures 25-28 show tables representing example syntax for implementing the main embodiments. The syntax is illustrated with respect to VVC syntax, with modifications highlighted with a gray background. To be consistent with the notation with other parameters, the subdiv level counter is represented by the cbSubdiv parameter. SPLIT_BT_HOR, SPLIT_BT_VER, SPLIT_TT_HOR, and SPLIT_TT_VER correspond to horizontal B-split, vertical B-split, horizontal T-split, and vertical T-split, respectively. The condition used in the coding tree syntax to reset IsCuQpDeltaCoded and CuQpDeltaVal has been modified from (cu_qp_delta_enabled_flag && log2CbSize >= Log2MinCuQpDeltaSize) to (cu_qp_delta_enabled_flag && cbSubdiv <= cu_qp_delta_subdiv). Under this condition, in addition to resetting IsCuQpDeltaCoded and CuQpDeltaVal, x0 and y0 are saved to xQg and yQg (step 503 in Figure 21 and step 603 in Figure 22). As described in the main embodiment or a variant of the main embodiment (if an AB split is required), syntax or semantics are added to coding_quadtree() and multi_type_tree() (and also dual_tree_implicit_qt_split) to increment the newly created cbSubdiv parameter according to the split type and partition index.

[0091] In the paragraph "derivation process for quantization parameters" of VVC, the position of the QG origin (xQg, yQg) as described in HEVC cannot be derived because it is based on Log2MinCuQpDeltaSize, but (xQg, yQg) is exactly what is stored in coding_quadtree() and multi_type_tree().

[0092] Syntax elements and semantics for the main embodiment with restricted detection of QG onsets In at least one embodiment, the subdiv process is implemented by using specific syntax to signal the value of the subdiv level counter and at least parameters related to detecting the start of a quantization group. Thus, detection of the QG start is performed by adding a QG flag parameter (renamed "QG" in the tables below) in the coding tree syntax and modifying the detection conditions for the QG start. The modifications are highlighted with a gray background.

[0093] 29-31 show tables illustrating example syntax for implementing the main embodiment and handling QG start detection. The syntax is illustrated with respect to the VVC syntax, with modifications highlighted with a gray background. The same syntax as in coding_quadtree() is used for dual_tree_implicit_qt_split() and is not shown here.

[0094] 32-35 show tables illustrating examples of syntax for implementing the main embodiment and for handling QG start detection for chroma-related elements (shown in bold italics in the tables). Indeed, although the above description was made in relation to luma quantization parameters, the same principles apply mutatis mutandis to chroma quantization.

[0095] Those skilled in the art will understand that syntax structures and element names may exist in multiple variations depending on the version of the standard. Syntax elements may be replaced by variables that represent the same information. For example, previous versions of VVC used the cu_qp_delta_subdiv syntax element in the PPS, while later versions of VVC use the CuQpDeltaSubdiv variable defined in the semantics of the slice header, which represents the same information but selects the appropriate value for the current slice type based on syntax elements in the picture header. In addition, there are some changes in the syntax structure of the coding tree in various versions of VVC. These changes do not affect the principles of the above embodiments. In addition, syntax related to these embodiments may be included in different positions in different structures.

[0096] Various implementations include decoding. As used herein, "decoding" may encompass all or some of the processes performed on a received encoded sequence to produce a final output suitable for display, for example. In various embodiments, such processes include one or more of the processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. In various embodiments, such processes also or instead include processes performed by decoders of various implementations described herein, such as the processes illustrated in Figures 12, 21, and 22.

[0097] As a further example, in one embodiment "decoding" refers to entropy decoding only, in another embodiment "decoding" refers to differential decoding only, and in another embodiment "decoding" refers to a combination of entropy decoding and differential decoding. Whether the phrase "decoding process" is intended to refer specifically to a subset of operations or to a broader decoding process generally will be clear based on the context of the specific description and will be well understood by one of ordinary skill in the art.

[0098] Various implementations include encoding. Similar to the discussion above regarding "decoding," as used herein, "encoding" may encompass, for example, all or part of the processes performed on an input video sequence to result in a coded bitstream. In various embodiments, such processes include one or more of the processes typically performed by an encoder, such as segmentation, differential coding, transform, quantization, and entropy coding. In various embodiments, such processes also or instead include processes performed by the encoders of various implementations described herein, such as the processes of Figures 12, 21, and 22.

[0099] As a further example, in one embodiment "encoding" refers only to entropy encoding, in another embodiment "encoding" refers only to differential encoding, and in another embodiment "encoding" refers to a combination of differential and entropy encoding. Whether the phrase "encoding process" is intended to refer specifically to a subset of operations or to a broader encoding process generally will be clear based on the context of the specific description and is believed to be well understood by one of ordinary skill in the art.

[0100] It should be noted that the syntax elements used herein are descriptive terms, so they do not preclude the use of other syntax element names.

[0101] Where a drawing is shown as a flow diagram, it should be understood that it also provides a block diagram of the corresponding device. Similarly, where a drawing is shown as a block diagram, it should be understood that it also provides a flow diagram of the corresponding method / process.

[0102] Implementations and aspects described herein may be implemented by, for example, a method or process, an apparatus, a software program, a data stream, or a signal. Even if discussed in connection with only one type of 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 by, for example, appropriate hardware, software, and firmware. A method may be implemented by, for example, a processor, where a processor refers generally to processing devices including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices such as, for example, computers, mobile phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end-users.

[0103] References to "one embodiment," or "an embodiment," or "one implementation," or "an implementation," and 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, appearances of the phrases "in one embodiment," or "in an embodiment," or "in one implementation," or "in an implementation," and any other variations thereof, in various places throughout this application do not necessarily all refer to the same embodiment.

[0104] Additionally, this application may refer to "determining" various pieces of information. Determining information may include, for example, one or more of estimating information, calculating information, predicting information, or retrieving information from memory.

[0105] Additionally, this application may refer to "accessing" various pieces of information. Accessing information may include, for example, one or more of receiving information, retrieving information (e.g., from memory), storing information, moving information, replicating information, calculating information, determining information, predicting information, or estimating information.

[0106] Additionally, this application may refer to "receiving" various pieces of information. Receiving is intended to be broad, similar to "accessing." Receiving information may include, for example, one or more of accessing information or retrieving information (e.g., from a memory). Furthermore, "receiving" typically involves some form of operation, such as, for example, storing information, processing information, transmitting information, moving information, duplicating information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0107] For example, the use of " / ", "and / or" and "at least one of" in the cases of "A / B", "A and / or B" and "at least one of A and B" is intended to encompass selecting only the first listed (A) option, or selecting only the second listed (B) option, or selecting both (A and B) options. As a further example, in the cases of "A, B and / or C" and "at least one of A, B and C", such phraseology is intended to encompass selecting only the first listed (A) option, or selecting only the second listed (B) option, or selecting only the third listed (C) option, or selecting only the first and second listed options (A and B), or selecting only the first and third listed options (A and C), or selecting only the second and third listed options (B and C), or selecting all three options (A, B and C). As will be apparent to one skilled in the art, this representation can be extended to include as many items as are listed.

[0108] Further, as used herein, the term "signaling" refers to indicating something to a corresponding decoder, among other things. For example, in certain embodiments, an encoder signals a particular mode. In this manner, in one embodiment, the same parameters are used at both the encoder and decoder sides. Thus, for example, an encoder can transmit a particular parameter to a decoder (explicit signaling), allowing the decoder to use the same particular parameter. Conversely, if the decoder already has that particular parameter along with other parameters, signaling can be used without transmission simply to allow the decoder to know and select that particular parameter (implicit signaling). By avoiding transmitting any actual functionality, bit savings are realized in various embodiments. It should be understood that signaling can be realized in various ways. For example, in various embodiments, one or more syntax elements, flags, etc. are used to signal information to a corresponding decoder. While the above content relates to the verb form of the word "signal," the word "signal" may also be used herein as a noun.

[0109] As will be apparent to those skilled in the art, implementations can result in various signals formatted to carry information that can be, for example, stored or transmitted. Information can include, for example, instructions for performing a method or data produced by one of the described implementations. For example, a signal can be formatted to carry a bitstream of the described embodiments. Such a signal can be formatted, for example, as an electromagnetic wave (e.g., using the radio frequency portion of the spectrum) or as a baseband signal. Formatting can include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information carried by the signal can be, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

[0110] Several embodiments have been described. The features of these embodiments may be provided alone or in any combination. Furthermore, the embodiments may include one or more of the following features, devices, or aspects, alone or in any combination, across various claim categories and types:

Claims

1. 1. A method comprising: Dividing a block of an image into sub-blocks; for a sub-block, associating a sub-division level counter with the sub-block, the sub-division level counter having a value based on a type of division for the division into sub-blocks, the sub-blocks being associated with a quantization group based on the sub-division level counter, a quantization group being a group of blocks sharing the same quantization parameter, the sub-division level counter being incremented when a block is divided into sub-blocks, the incremented value being equal to 2 for all sub-blocks in a quad division, 1 for all sub-blocks in a binary division, 2 for side sub-blocks in a ternary division, and 1 for a center sub-block in a ternary division; Enabling a new quantization group on the condition that the sub-division level counter of the sub-block is less than or equal to a maximum sub-division value; determining a quantization parameter for the sub-block based on the quantization group; decoding the sub-block based on the determined quantization parameter; A method comprising:

2. Disabling a new quantization group when a block of an image is divided into sub-blocks of different sizes and the sub-division level counter of the smallest sub-block exceeds the maximum sub-division level. The method of claim 1 further comprising:

3. storing the position of the block when the new quantization group is enabled; The method of claim 1 further comprising:

4. The method of claim 1 , wherein the subdivision level counter represents a size of the sub-block.

5. The method of claim 1 , wherein the decoding comprises performing inverse quantization on a luma component or a color component.

6. 1. An apparatus comprising a processor, the processor comprising: Dividing a block of an image into sub-blocks; for a sub-block, associating a sub-division level counter with the sub-block, the sub-division level counter having a value based on a type of division for the division into sub-blocks, the sub-blocks being associated with a quantization group based on the sub-division level counter, a quantization group being a group of blocks sharing the same quantization parameter, the sub-division level counter being incremented when a block is divided into sub-blocks, the incremented value being equal to 2 for all sub-blocks in a quad division, 1 for all sub-blocks in a binary division, 2 for side sub-blocks in a ternary division, and 1 for a center sub-block in a ternary division; Enabling a new quantization group on the condition that the sub-division level counter of the sub-block is less than or equal to a maximum sub-division value; determining a quantization parameter for the sub-block based on the quantization group; decoding the sub-block based on the determined quantization parameter. Device.

7. Disabling a new quantization group when a block of an image is divided into sub-blocks of different sizes and the sub-division level counter of the smallest sub-block exceeds the maximum sub-division level. The apparatus of claim 6 further comprising:

8. storing the position of the block when the new quantization group is enabled; The apparatus of claim 6 further comprising:

9. The apparatus of claim 6 , wherein the subdivision level counter represents a size of the sub-block.

10. The apparatus of claim 6 , wherein the decoding comprises performing inverse quantization on a luma component or a color component.

Citation Information

Patent Citations

  • Video decoding device

    JP2014530557A

  • Encoding of pictures in a video

    WO2017093189A1