Signaling quantization parameters in video processing

Abstract

This disclosure provides a method for processing video content. One exemplary method includes receiving a bitstream including coded video data, determining a first parameter for the coded block, determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameter, and determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This disclosure claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 903,251, filed Sep. 20, 2019, which is incorporated by reference in its entirety herein.

[0002] Technical Field The present disclosure relates generally to video processing, and more particularly, to methods and systems for processing video content with quantization parameters. [Background technology]

[0003] background

[0003] A video is a set of static pictures (or "frames") that capture visual information. To reduce storage memory and transmission bandwidth, a video can be compressed before storage or transmission and decompressed before display. The compression process is usually called encoding, and the decompression process is usually called decoding. There are various video coding formats that use standardized video coding techniques, most commonly based on prediction, transformation, quantization, entropy coding, and in-loop filtering. Video coding standards, such as the High Efficiency Video Coding (HEVC / H.265) standard, the Versatile Video Coding (VVC / H.266) standard, and the AVS standard, that specify specific video coding formats, are developed by standardization organizations. As more advanced video coding techniques are adopted into video standards, the coding efficiency of the new video coding standards becomes higher. Summary of the Invention [Means for solving the problem]

[0004] Summary of the Disclosure

[0004] An embodiment of the present disclosure provides a computer-implemented method for processing video content, including receiving a bitstream including coded video data, determining a first parameter for the coded block, determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value in accordance with the first parameter, and determining at least one of the delta QP value or the chroma QP offset value in accordance with the one or more second parameters.

[0005]

[0005] An embodiment of the present disclosure also provides a system for processing video content including a memory storing a set of instructions and at least one processor, where the at least one processor is configured to execute the set of instructions to cause the system to receive a bitstream including coded video data, determine a first parameter of the coded block, determine one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value in accordance with the first parameter, and determine at least one of the delta QP values ​​or the chroma QP offset values ​​in accordance with the one or more second parameters.

[0006]

[0006] An embodiment of the present disclosure also provides a non-transitory computer-readable medium storing instructions executable by at least one processor of a computer system, where executing the instructions causes the computer system to perform a method including receiving a bitstream including coded video data, determining a first parameter for the coded block, determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value in accordance with the first parameter, and determining at least one of the delta QP values ​​or the chroma QP offset values ​​in accordance with the one or more second parameters.

[0007] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments and various aspects of the present disclosure are illustrated in the following detailed description and the accompanying drawings, in which various features are not drawn to scale. [Brief description of the drawings]

[0008] [Figure 1] 1 illustrates an exemplary video sequence structure consistent with embodiments of the present disclosure. [Figure 2A]

[0009] 1 shows a schematic diagram of an exemplary encoding process for a hybrid video coding system consistent with embodiments of the present disclosure. [Figure 2B]

[0010] 1 shows a schematic diagram of another exemplary encoding process of a hybrid video coding system consistent with embodiments of the present disclosure. [Figure 3A]

[0011] 1 shows a schematic diagram of an exemplary decoding process for a hybrid video coding system consistent with embodiments of the present disclosure. [Figure 3B]

[0012] 1 shows a schematic diagram of another example decoding process for a hybrid video coding system consistent with embodiments of the present disclosure. [Figure 4]

[0013] 1 is a block diagram of an exemplary device for encoding or decoding video consistent with embodiments of this disclosure. [Diagram 5]

[0014] 1 illustrates an example of a picture parameter set (PPS) for a coded unit (CU) delta quantization parameter (QP), consistent with embodiments of this disclosure. [Figure 6A]

[0015] 1 illustrates an example of a coding tree-level syntax for CU delta QP, consistent with embodiments of this disclosure. [Figure 6B] 1 illustrates an example of a coding tree-level syntax for CU-delta QP consistent with embodiments of this disclosure. [Figure 6C] 1 illustrates an example of a coding tree-level syntax for CU-delta QP consistent with embodiments of this disclosure. [Figure 7A]

[0016] 1 illustrates an example of a transform unit level syntax for CU delta QP, consistent with embodiments of this disclosure. [Figure 7B] 1 illustrates an example of a transform unit level syntax for CU delta QP consistent with embodiments of this disclosure. [Figure 7C] 1 illustrates an example of a transform unit level syntax for CU delta QP consistent with embodiments of this disclosure. [Figure 8]

[0017] 1 illustrates an example of slice header syntax consistent with embodiments of the present disclosure. [Figure 9]

[0018] 1 illustrates another example of slice header syntax consistent with embodiments of the present disclosure. [Figure 10]

[0019] 1 illustrates yet another example of slice header syntax, consistent with embodiments of the present disclosure. [Figure 11]

[0020] 1 illustrates another example of a picture header syntax consistent with embodiments of this disclosure. [Figure 12]

[0021] 13 shows an example of PPS syntax for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv, consistent with embodiments of the present disclosure. [Figure 13]

[0022] 13 shows an example of slice header syntax for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv consistent with embodiments of the present disclosure. [Figure 14]

[0023] 13 shows an example of syntax for sps_max_mtt_depth_luma consistent with embodiments of the present disclosure. [Figure 15]

[0024] 13 illustrates an example of syntax for pps_max_mtt_depth_luma consistent with embodiments of the present disclosure. [Figure 16]

[0025] 13 shows an example of SPS syntax for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv, consistent with embodiments of the present disclosure. [Figure 17]

[0026] 13 shows an example of slice header syntax for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv consistent with embodiments of the present disclosure. [Figure 18]

[0027] 13 shows an example of syntax for sps_max_mtt_depth_luma consistent with embodiments of the present disclosure. [Figure 19]

[0028] 13 illustrates another example of syntax for sps_max_mtt_depth_luma, consistent with embodiments of the present disclosure. [Figure 20]

[0029] 13 shows an example of syntax for pps_max_mtt_depth_luma consistent with embodiments of the present disclosure. [Figure 21]

[0030] 1 is a flow diagram of an exemplary computer-implemented method for processing video content consistent with embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009]

[0031] Video coding systems are often used to compress digital video signals, for example to reduce the storage space consumed or to reduce the transmission bandwidth consumption associated with such signals. With the increasing popularity of high definition (HD) video (e.g., having a resolution of 1920x1080 pixels) in various applications of video compression, such as online video streaming, video conferencing or video surveillance, there is a continuous need to develop video coding tools that can increase the efficiency of compressing video data.

[0010]

[0032] For example, video surveillance applications are more and more widely used in many application scenarios (e.g., security, traffic, environmental monitoring, etc.), and the number and resolution of surveillance devices are rapidly increasing. Many video surveillance application scenarios choose to provide users with HD video to capture more information, and HD video has more pixels per frame to capture such information. However, HD video bitstreams may have high bitrates that require high bandwidth for transmission and large space for storage. For example, a surveillance video stream with an average resolution of 1920x1080 may require as much as 4Mbps bandwidth for real-time transmission. Furthermore, video surveillance generally involves constant monitoring, which may be a big challenge for storage systems when storing video data. Therefore, the high bandwidth and large storage space demands of HD video have become the main limitations to the large-scale deployment of HD video in video surveillance.

[0011]

[0033] A video is a set of still pictures (or "frames") arranged in chronological order to store visual information. A video capture device (e.g., a camera) can be used to capture and store those pictures in chronological order, and a video playback device (e.g., a television, a computer, a smartphone, a tablet computer, a video player, or any end-user terminal with display capabilities) can be used to display such pictures in chronological order. Furthermore, in some applications, a video capture device can transmit captured videos in real time to a video playback device (e.g., a computer with a monitor) for surveillance, conferencing, live broadcast, etc.

[0012]

[0034] To reduce the storage space and transmission bandwidth required by such applications, the video may be compressed before storage and transmission, and decompressed before display. This compression and decompression may be implemented by software executed by a processor (e.g., a processor of a general-purpose computer) or dedicated hardware. A module for compression is generally called an "encoder," and a module for decompression is generally called a "decoder." The encoder and decoder may be collectively referred to as a "codec." The encoder and decoder may be implemented as various suitable hardware, software, or combinations thereof. For example, hardware implementations of the encoder and decoder may include circuitry such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, or any combination thereof. Software implementations of the encoder and decoder may include program code, computer executable instructions, firmware, or any suitable computer-implemented algorithm or process fixed in a computer-readable medium. Video compression and decompression may be implemented by various algorithms or standards, such as MPEG-1, MPEG-2, MPEG-4, H.26x series, etc. In some applications, a codec may decompress video from a first coding standard and recompress the decompressed video using a second coding standard, in which case the codec may be referred to as a "transcoder."

[0013]

[0035] A video coding process can identify and keep useful information that can be used to reconstruct a picture and ignore information that is not important for the reconstruction. If the ignored, unimportant information cannot be perfectly reconstructed, then such a coding process can be called "lossy". Otherwise, such a coding process can be called "lossless". Most coding processes are lossy, which is a tradeoff to reduce the required storage space and transmission bandwidth.

[0014]

[0036] Useful information of the picture being coded (called the "current picture") includes changes with respect to a reference picture (e.g. a previously coded and reconstructed picture). Such changes may include pixel position changes, luminance changes or color changes, of which position changes are the most important. Position changes of pixels representing an object may reflect the object's motion between the reference picture and the current picture.

[0015]

[0037] A picture that is coded without reference to another picture (i.e., such a picture is its own reference picture) is called an "I-picture". A picture that is coded using a past picture as a reference picture is called a "P-picture". A picture that is coded using both past and future pictures as reference pictures (i.e., the references are "bidirectional") is called a "B-picture".

[0016]

[0038] As mentioned above, video surveillance using HD video faces the challenge of high bandwidth and large storage demands. To address this challenge, the bit rate of the encoded video can be reduced. Among I-pictures, P-pictures, and B-pictures, I-pictures have the highest bit rate. Since the background of most surveillance videos is mostly static, one way to reduce the overall bit rate of the encoded video can be to use fewer I-pictures for video encoding.

[0017]

[0039] However, since I-pictures are generally not predominant in coded video, the improvement of using fewer I-pictures may be trivial. For example, in a typical video bitstream, the ratio of I-pictures, B-pictures, and P-pictures may be 1:20:9, and I-pictures may account for less than 10% of the total bitrate. In other words, in such an example, removing all I-pictures may only reduce the bitrate by 10%.

[0018]

[0040] The present disclosure provides a method, apparatus, and system for processing video content using Adaptive Resolution Transformation (ARC). Unlike the inaccurate phase caused by phase rounding, embodiments of the present disclosure provide a pixel refinement process based on fixed phase interpolation to reduce algorithm and hardware complexity while maintaining accuracy.

[0019]

[0041] 1 illustrates the structure of an example video sequence 100 consistent with embodiments of the present disclosure. Video sequence 100 may be live video or captured and archived video. Video 100 may be real video, computer-generated video (e.g., computer game video), or a combination thereof (e.g., real video with augmented reality effects). Video sequence 100 may be input from a video capture device (e.g., a camera), a video archive containing previously captured video (e.g., a video file stored in a storage device), or a video feed interface for receiving video from a video content provider (e.g., a video broadcast transceiver).

[0020]

[0042] As shown in FIG. 1, a video sequence 100 may include a series of pictures arranged temporally along a timeline, including pictures 102, 104, 106, and 108. Pictures 102-106 are consecutive, with more pictures between pictures 106 and 108. In FIG. 1, picture 102 is an I-picture whose reference picture is picture 102 itself. Picture 104 is a P-picture whose reference picture is picture 102, as indicated by the arrow. Picture 106 is a B-picture whose reference pictures are pictures 104 and 108, as indicated by the arrow. In some embodiments, the reference picture of a picture (e.g., picture 104) may not be immediately preceding or following that picture. For example, the reference picture of picture 104 may be a picture preceding picture 102. It should be noted that the reference pictures of pictures 102-106 are merely examples, and this disclosure does not limit the embodiments of the reference pictures to the examples shown in FIG.

[0021]

[0043] Typically, a video codec does not encode or decode an entire picture at once because such a task is computationally complex. Rather, a video codec may divide a picture into elementary segments and encode or decode a picture segment by segment. In this disclosure, such elementary segments are referred to as basic processing units ("BPUs"). For example, structure 110 in FIG. 1 illustrates an example structure of a picture (e.g., any of pictures 102-108) of video sequence 100. In structure 110, the picture is divided into 4x4 basic processing units, the boundaries of which are indicated by dashed lines. In some embodiments, the basic processing units may be referred to as "macroblocks" in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC) and as "coding tree units" ("CTUs") in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC). Basic processing units can have variable sizes within a picture, such as 128x128, 64x64, 32x32, 16x16, 4x8, 16x32, or any arbitrary shape and size of pixels. The size and shape of the basic processing unit can be selected for a picture based on a balance between efficiency of coding and the level of detail one wishes to preserve within the basic processing unit.

[0022]

[0044] A basic processing unit may be a logical unit that may include various types of video data stored in a computer memory (e.g., in a video frame buffer). For example, a basic processing unit for a color picture may include a luma component (Y) representing achromatic luminance information, one or more chroma components (e.g., Cb and Cr) representing color information, and associated syntax elements of the basic processing unit, where the luma and chroma components may have the same size. In some video coding standards (e.g., H.265 / HEVC or H.266 / VVC), the luma and chroma components may be referred to as "coding tree blocks" ("CTBs"). Any operation performed on a basic processing unit may be repeated on each of its luma and chroma components.

[0023]

[0045] Video coding has multiple operation stages, examples of which are detailed in Figures 2A-2B and 3A-3B. For each stage, the size of the basic processing unit may still be too large to process, and therefore may be further divided into segments referred to as "basic processing sub-units" in this disclosure. In some embodiments, the basic processing sub-units may be referred to as "blocks" in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC), or as "coding units" ("CUs") in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC). The basic processing sub-units may have the same or smaller size than the basic processing units. Similar to the basic processing units, the basic processing sub-units are also logical units that may include various types of video data (e.g., Y, Cb, Cr, and related syntax elements) stored in computer memory (e.g., in a video frame buffer). Any operation performed on a basic processing sub-unit can be repeated on each of its luma and chroma components. It should be noted that such division can be performed on further levels, depending on the processing needs. It should also be noted that different stages can use different schemes to divide the basic processing unit.

[0024]

[0046] For example, in a mode decision stage (one example of which is detailed in FIG. 2B), the encoder may decide which prediction mode (e.g., intra-picture prediction or inter-picture prediction) to use for a basic processing unit, which may be too large to make such a decision. The encoder may split the basic processing unit into multiple basic processing sub-units (e.g., CUs in H.265 / HEVC or H.266 / VVC) and decide the type of prediction for each individual basic processing sub-unit.

[0025]

[0047] In another example, in the prediction stage (one example of which is detailed in FIG. 2A), the encoder can perform prediction operations at the level of elementary processing sub-units (e.g., CUs). However, in some cases, elementary processing sub-units may still be too large to process. The encoder can further divide the elementary processing sub-units into smaller segments (e.g., called "prediction blocks" or "PBs" in H.265 / HEVC or H.266 / VVC) and perform prediction operations at that level.

[0026]

[0048] In another example, in the transform stage (one example of which is detailed in FIG. 2A), the encoder can perform a transform operation on the residual elementary processing sub-unit (e.g., CU). However, in some cases, the elementary processing sub-unit may still be too large to process. The encoder can further divide the elementary processing sub-unit into smaller segments (e.g., called "transform blocks" or "TBs" in H.265 / HEVC or H.266 / VVC) and perform the transform operation at that level. It should be noted that the division scheme of the same elementary processing sub-unit may be different between the prediction stage and the transform stage. For example, in H.265 / HEVC or H.266 / VVC, the prediction blocks and transform blocks of the same CU may have different sizes and numbers.

[0027]

[0049] In structure 110 of Figure 1, basic processing units 112 are further divided into 3x3 basic processing sub-units, the boundaries of which are shown by dotted lines. Different basic processing units of the same picture can be divided into basic processing sub-units in different ways.

[0028]

[0050] In some implementations, to provide video encoding and decoding with parallel processing and error resilience, a picture can be divided into regions for processing, so that for a region of a picture, the encoding or decoding process does not depend on information of any other region of the picture. In other words, each region of a picture can be processed independently. In this way, a codec can process different regions of a picture in parallel, thus increasing the efficiency of coding. Furthermore, if data of a region is corrupted in processing or lost in network transmission, the codec can correctly encode or decode other regions of the same picture without relying on the corrupted or lost data, thus providing error resilience. In some video coding standards, a picture can be divided into different types of regions. For example, H.265 / HEVC and H.266 / VVC provide two types of regions: "slices" and "tiles". It should also be noted that various pictures of the video sequence 100 may have different partitioning schemes for dividing the picture into regions.

[0029]

[0051] For example, in Figure 1, structure 110 is divided into three regions 114, 116, and 118, whose boundaries are shown as solid lines within structure 110. Region 114 includes four basic processing units. Regions 116 and 118 each include six basic processing units. It should be noted that the basic processing units, basic processing sub-units, and regions of structure 110 in Figure 1 are merely examples, and the present disclosure is not limited to such embodiments.

[0030]

[0052] FIG. 2A illustrates a schematic diagram of an example of an encoding process 200A consistent with embodiments of the present disclosure. An encoder may encode a video sequence 202 into a video bitstream 228 according to the process 200A. Similar to the video sequence 100 of FIG. 1, the video sequence 202 may include a set of pictures (referred to as "original pictures") arranged in a chronological order. Similar to the structure 110 of FIG. 1, each original picture of the video sequence 202 may be divided by the encoder into basic processing units, basic processing sub-units, or regions for processing. In some embodiments, the encoder may perform the process 200A at the level of the basic processing units for each original picture of the video sequence 202. For example, the encoder may perform the process 200A in an iterative manner, where the encoder may encode a basic processing unit in one iteration of the process 200A. In some embodiments, the encoder may perform the process 200A in parallel for regions (e.g., regions 114-118) of each original picture of the video sequence 202.

[0031]

[0053] In FIG. 2A , an encoder may feed a basic processing unit (referred to as an “original BPU”) of an original picture of a video sequence 202 to a prediction stage 204 to generate prediction data 206 and a predicted BPU 208. The encoder may subtract the predicted BPU 208 from the original BPU to generate a residual BPU 210. The encoder may feed the residual BPU 210 to a transform stage 212 and a quantization stage 214 to generate quantized transform coefficients 216. The encoder may feed the prediction data 206 and the quantized transform coefficients 216 to a binary coding stage 226 to generate a video bitstream 228. The components 202, 204, 206, 208, 210, 212, 214, 216, 226, and 228 may be referred to as a “forward path.” During process 200A, the encoder may feed quantized transform coefficients 216, after quantization stage 214, to an inverse quantization stage 218 and an inverse transform stage 220 to generate a reconstructed residual BPU 222. The encoder may add the reconstructed residual BPU 222 to a predicted BPU 208 to generate a prediction reference 224 that is used in the prediction stage 204 of the next iteration of process 200A. The components 218, 220, 222, and 224 of process 200A may be referred to as a "reconstruction path." The reconstruction path may be used to ensure that both the encoder and decoder use the same reference data for prediction.

[0032]

[0054] The encoder may iteratively perform process 200A to encode each original BPU of the original picture (in the forward path) and generate a predicted reference 224 for encoding the next original BPU of the original picture (in the reconstruction path). After encoding all the original BPUs of the original picture, the encoder may proceed to encode the next picture in the video sequence 202.

[0033]

[0055] Referring to process 200A, an encoder may receive a video sequence 202 generated by a video capture device (e.g., a camera). As used herein, the term "receive" may refer to any action of receiving, inputting, obtaining, retrieving, acquiring, reading, accessing, or any manner of inputting data.

[0034]

[0056] In the prediction step 204, in the current iteration, the encoder may receive the original BPU and a prediction reference 224 and perform a prediction operation to generate prediction data 206 and a predicted BPU 208. The prediction reference 224 may be generated from a reconstruction path of a previous iteration of the process 200A. The purpose of the prediction step 204 is to reduce information redundancy by extracting the prediction data 206, which may be used to reconstruct the original BPU from the prediction data 206 and the prediction reference 224 as a predicted BPU 208.

[0035]

[0057] Ideally, the predicted BPU 208 may be identical to the original BPU. However, due to non-ideal prediction and reconstruction operations, the predicted BPU 208 generally differs slightly from the original BPU. To record such differences, the encoder may generate the predicted BPU 208 and then subtract it from the original BPU to generate the residual BPU 210. For example, the encoder may subtract the values ​​(e.g., grayscale values ​​or RGB values) of pixels of the predicted BPU 208 from the values ​​of corresponding pixels of the original BPU. As a result of such subtraction between the corresponding pixels of the original BPU and the predicted BPU 208, each pixel of the residual BPU 210 may have a residual value. Compared to the original BPU, the prediction data 206 and the residual BPU 210 may have fewer bits, but they can be used to reconstruct the original BPU without significant loss of quality.

[0036]

[0058] To further compress the residual BPU 210, in the transform stage 212, the encoder can reduce spatial redundancy in the residual BPU 210 by decomposing the residual BPU 210 into a set of two-dimensional "basis patterns," where each basis pattern is associated with a "transform coefficient." The basis patterns can have the same size (e.g., the size of the residual BPU 210). Each basis pattern can represent a variation frequency (e.g., luminance variation frequency) component of the residual BPU 210. None of the basis patterns can be reconstructed from any combination (e.g., a linear combination) of any other basis patterns. In other words, the decomposition can decompose the variation of the residual BPU 210 into the frequency domain. Such a decomposition is similar to a discrete Fourier transform of a function, the basis patterns are similar to basis functions (e.g., trigonometric functions) of the discrete Fourier transform, and the transform coefficients are similar to the coefficients associated with the basis functions.

[0037]

[0059] Different transform algorithms may use different basis patterns. Different transform algorithms may be used in transform stage 212, for example, discrete cosine transform, discrete sine transform, etc. The transform in transform stage 212 is reversible. That is, the encoder may reconstruct residual BPU 210 by the inverse operation of the transform (referred to as "inverse transform"). For example, to reconstruct pixels of residual BPU 210, the inverse transform may be to multiply the values ​​of corresponding pixels of the basis pattern by the associated respective coefficients and add the products to result in a weighted sum. In a video coding standard, both the encoder and the decoder may use the same transform algorithm (and thus the same basis pattern). Thus, the encoder may record only the transform coefficients, and the decoder may reconstruct residual BPU 210 from the transform coefficients without receiving the basis pattern from the encoder. Although the transform coefficients may have fewer bits compared to residual BPU 210, they may be used to reconstruct residual BPU 210 without significant loss of quality. Therefore, the residual BPU 210 is further compressed.

[0038]

[0060] The encoder can further compress the transform coefficients in the quantization stage 214. In the transform process, different basis patterns can represent different fluctuation frequencies (e.g., luminance fluctuation frequencies). Since the human eye is generally good at recognizing low-frequency fluctuations, the encoder can ignore the information of high-frequency fluctuations without causing significant quality degradation during decoding. For example, in the quantization stage 214, the encoder can generate quantized transform coefficients 216 by dividing each transform coefficient by an integer value (called a "quantization parameter") and rounding the quotient to its nearest neighbor. After such an operation, some transform coefficients of the high-frequency basis patterns can be converted to zero, and the transform coefficients of the low-frequency basis patterns can be converted to smaller integers. The encoder can ignore the zero-valued quantized transform coefficients 216, which further compresses the transform coefficients. The quantization process is also reversible, and the quantized transform coefficients 216 can be reconstructed into transform coefficients in the inverse operation of quantization (called "dequantization").

[0039]

[0061] The quantization stage 214 may be lossy because the encoder ignores the remainder of such a division in a rounding operation. Typically, the quantization stage 214 may contribute the greatest information loss in the process 200A. The greater the information loss, the fewer bits the quantized transform coefficients 216 may require. To obtain different levels of information loss, the encoder may use different values ​​of the quantization parameter or any other parameter of the quantization process.

[0040]

[0062] In the binary coding stage 226, the encoder may use a binary coding technique, such as, for example, entropy coding, variable length coding, arithmetic coding, Huffman coding, context-adaptive binary arithmetic coding, or any other lossless or lossy compression algorithm, to encode the prediction data 206 and the quantized transform coefficients 216. In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the encoder may encode other information in the binary coding stage 226, such as, for example, a prediction mode used in the prediction stage 204, parameters of the prediction operation, the type of transformation in the transformation stage 212, parameters of the quantization process (e.g., quantization parameters), encoder control parameters (e.g., bitrate control parameters), etc. The encoder may use the output data of the binary coding stage 226 to generate a video bitstream 228. In some embodiments, the video bitstream 228 may be further packetized for network transmission.

[0041]

[0063] Referring to the reconstruction path of process 200A, in an inverse quantization stage 218, the encoder may perform inverse quantization on the quantized transform coefficients 216 to generate reconstructed transform coefficients. In an inverse transform stage 220, the encoder may generate a reconstructed residual BPU 222 based on the reconstructed transform coefficients. The encoder may add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a prediction reference 224 to be used in the next iteration of process 200A.

[0042]

[0064] It should be noted that other variations of the process 200A can be used to encode the video sequence 202. In some embodiments, an encoder can perform the stages of the process 200A in a different order. In some embodiments, one or more stages of the process 200A can be combined into a single stage. In some embodiments, a single stage of the process 200A can be separated into multiple stages. For example, the transform stage 212 and the quantization stage 214 can be combined into a single stage. In some embodiments, the process 200A can include additional stages. In some embodiments, the process 200A can omit one or more stages in FIG. 2A.

[0043]

[0065] 2B shows a schematic diagram of another example encoding process 200B consistent with an embodiment of the present disclosure. Process 200B may be modified from process 200A. For example, process 200B may be used by an encoder conforming to a hybrid video coding standard (e.g., H.26x series). Compared to process 200A, the forward path of process 200B further includes a mode decision stage 230 and separates prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044. The reconstruction path of process 200B additionally includes a loop filter stage 232 and a buffer 234.

[0044]

[0066] Generally, prediction techniques can be classified into two types: spatial prediction and temporal prediction. Spatial prediction (e.g., intra-picture prediction or "intra prediction") can use pixels of one or more neighboring BPUs already coded in the same picture to predict the current BPU. That is, the prediction reference 224 in spatial prediction can include neighboring BPUs. Spatial prediction can reduce the inherent spatial redundancy of a picture. Temporal prediction (e.g., inter-picture prediction or "inter prediction") can use regions of one or more already coded pictures to predict the current BPU. That is, the prediction reference 224 in temporal prediction can include coded pictures. Temporal prediction can reduce the inherent temporal redundancy of a picture.

[0045]

[0067] Referring to process 200B, in the forward path, the encoder performs prediction operations in a spatial prediction stage 2042 and a temporal prediction stage 2044. For example, in the spatial prediction stage 2042, the encoder may perform intra prediction. With respect to an original BPU of a picture being encoded, the prediction reference 224 may include one or more neighboring BPUs that are encoded (in the forward path) and reconstructed (in the reconstruction path) in the same picture. The encoder may generate the predicted BPU 208 by extrapolating the neighboring BPUs. Extrapolation techniques may include, for example, linear extrapolation or linear interpolation, polynomial extrapolation or polynomial interpolation, etc. In some embodiments, the encoder may perform extrapolation at a pixel level, such as by extrapolating the value of the corresponding pixel for each pixel of the predicted BPU 208. The neighboring BPUs used for extrapolation may be located relative to the original BPU from various directions, such as vertically (e.g., above the original BPU), horizontally (e.g., to the left of the original BPU), diagonally (e.g., bottom-left, bottom-right, top-left, or top-right of the original BPU), or any direction specified within the video coding standard used. In intra prediction, the prediction data 206 may include, for example, the positions (e.g., coordinates) of the neighboring BPUs used, the size of the neighboring BPUs used, parameters of the extrapolation, the orientation of the neighboring BPUs used relative to the original BPU, etc.

[0046]

[0068] In another example, in the temporal prediction stage 2044, the encoder may perform inter prediction. With respect to the original BPU of the current picture, the prediction reference 224 may include one or more pictures (called "reference pictures") that have been coded (in the forward path) and reconstructed (in the reconstruction path). In some embodiments, the reference pictures may be coded and reconstructed for each BPU. For example, the encoder may add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a reconstructed BPU. Once all the reconstructed BPUs of the same picture are generated, the encoder may generate the reconstructed picture as the reference picture. The encoder may perform an operation of "motion estimation" to look for a matching region within the range of the reference picture (called a "search window"). The position of the search window in the reference picture may be determined based on the position of the original BPU in the current picture. For example, the search window may be centered in the reference picture at a location having the same coordinates as the original BPU in the current picture and may extend over a predetermined distance. When the encoder identifies a region within the search window that is similar to the original BPU (e.g., by using a pel recursion algorithm, a block matching algorithm, etc.), the encoder can determine the region as a match region. The match region may have different (e.g., smaller, equal, larger, or differently shaped) dimensions than the original BPU. Because the reference picture and the current picture are separated in time in a timeline (e.g., as shown in FIG. 1), the match region can be considered to "move" to the position of the original BPU over time. The encoder can record the direction and distance of such movement as a "motion vector." If multiple reference pictures are used (e.g., like picture 106 in FIG. 1), the encoder can look for a match region for each reference picture and determine its associated motion vector. In some embodiments, the encoder can assign weights to the pixel values ​​of the match region of each matching reference picture.

[0047]

[0069] Motion estimation can be used to identify various types of motion, such as, for example, translation, rotation, scaling, etc. In inter prediction, the prediction data 206 may include, for example, the location (e.g., coordinates) of the match region, a motion vector associated with the match region, a number of reference pictures, weights associated with the reference pictures, etc.

[0048]

[0070] To generate the predicted BPU 208, the encoder may perform an operation of "motion compensation." Motion compensation may be used to reconstruct the predicted BPU 208 based on the prediction data 206 (e.g., motion vectors) and the prediction reference 224. For example, the encoder may move the matching regions of the reference picture according to the motion vectors, in which the encoder may predict the original BPU of the current picture. If multiple reference pictures are used (e.g., such as picture 106 in FIG. 1), the encoder may move the matching regions of the reference pictures according to their respective motion vectors and average the pixel values ​​of the matching regions. In some embodiments, if the encoder assigns weights to the pixel values ​​of the matching regions of the respective matching reference pictures, the encoder may add a weighted sum of the pixel values ​​of the moved matching regions.

[0049]

[0071] In some embodiments, inter prediction can be unidirectional or bidirectional. Unidirectional inter prediction can use one or more reference pictures in the same temporal direction relative to the current picture. For example, picture 104 in FIG. 1 is a unidirectional inter predicted picture in which the reference picture (i.e., picture 102) precedes picture 104. Bidirectional inter prediction can use one or more reference pictures in both temporal directions relative to the current picture. For example, picture 106 in FIG. 1 is a bidirectional inter predicted picture in which the reference pictures (i.e., pictures 104 and 108) are in both temporal directions relative to picture 104.

[0050]

[0072] Continuing to refer to the forward path of the process 200B, after the spatial prediction step 2042 and the temporal prediction step 2044, in a mode decision step 230, the encoder may select a prediction mode (e.g., one of intra prediction or inter prediction) for the current iteration of the process 200B. For example, the encoder may perform a rate distortion optimization technique, in which the encoder may select a prediction mode to minimize the value of a cost function depending on the bit rate of the candidate prediction mode and the distortion of the reconstructed reference picture under the candidate prediction mode. Depending on the prediction mode selected, the encoder may generate a corresponding predicted BPU 208 and predicted data 206.

[0051]

[0073] In the reconstruction path of the process 200B, if an intra prediction mode is selected in the forward path, after generating the prediction reference 224 (e.g., the current BPU being coded and reconstructed in the current picture), the encoder can feed the prediction reference 224 directly to the spatial prediction stage 2042 for later use (e.g., to extrapolate the next BPU of the current picture). If an inter prediction mode is selected in the forward path, after generating the prediction reference 224 (e.g., the current picture in which all BPUs are coded and reconstructed), the encoder can feed the prediction reference 224 to the loop filter stage 232, where the encoder can apply a loop filter to the prediction reference 224 to reduce or eliminate distortions (e.g., blocking artifacts) caused by inter prediction. The encoder can apply various loop filter techniques in the loop filter stage 232, such as, for example, deblocking, sample adaptive offset, adaptive loop filter, etc. The loop filtered reference picture may be stored in a buffer 234 (or a "decoded picture buffer") for later use (e.g., for use as an inter-predicted reference picture for future pictures of the video sequence 202). The encoder may store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the encoder may encode loop filter parameters (e.g., loop filter strength) in a binary coding stage 226 along with the quantized transform coefficients 216, the prediction data 206, and other information.

[0052]

[0074] FIG. 3A shows a schematic diagram of an example of a decoding process 300A consistent with an embodiment of the present disclosure. The process 300A may be a decompression process corresponding to the compression process 200A of FIG. 2A. In some embodiments, the process 300A may be similar to the reconstruction path of the process 200A. A decoder may decode the video bitstream 228 into a video stream 304 according to the process 300A. The video stream 304 may be very similar to the video sequence 202. However, due to information loss in the compression and decompression process (e.g., the quantization stage 214 of FIGS. 2A-2B), the video stream 304 is generally not identical to the video sequence 202. Similar to the processes 200A and 200B of FIGS. 2A-2B, the decoder may perform the process 300A at the level of a basic processing unit (BPU) for each picture encoded in the video bitstream 228. For example, the decoder may perform process 300A in an iterative manner, where the decoder may decode a basic processing unit in one iteration of process 300A. In some embodiments, the decoder may perform process 300A in parallel for a region (e.g., regions 114-118) of each picture encoded in video bitstream 228.

[0053]

[0075] In FIG. 3A, the decoder may feed a portion of the video bitstream 228 associated with a basic processing unit of a coded picture (referred to as a "coded BPU") to a binary decoding stage 302. In the binary decoding stage 302, the decoder may decode the portion into prediction data 206 and quantized transform coefficients 216. The decoder may feed the quantized transform coefficients 216 to an inverse quantization stage 218 and an inverse transform stage 220 to generate a reconstructed residual BPU 222. The decoder may feed the prediction data 206 to a prediction stage 204 to generate a predicted BPU 208. The decoder may add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a predicted reference 224. In some embodiments, the predicted reference 224 may be stored in a buffer (e.g., a decoded picture buffer in a computer memory). The decoder may feed the predicted reference 224 to the prediction stage 204 for performing a prediction operation in a next iteration of the process 300A.

[0054]

[0076] The decoder may iteratively perform the process 300A to decode each coded BPU of the coded picture and generate a predicted reference 224 for coding the next coded BPU of the coded picture. After decoding all coded BPUs of the coded picture, the decoder may output the picture to the video stream 304 for display and proceed to decode the next coded picture in the video bitstream 228.

[0055]

[0077] In the binary decoding stage 302, the decoder may perform an inverse operation of the binary coding technique used by the encoder (e.g., entropy coding, variable length coding, arithmetic coding, Huffman coding, context-adaptive binary arithmetic coding, or any other lossless compression algorithm). In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the decoder may decode other information in the binary decoding stage 302, such as, for example, the prediction mode, parameters of the prediction operation, the type of transform, parameters of the quantization process (e.g., quantization parameters), encoder control parameters (e.g., bitrate control parameters), etc. In some embodiments, if the video bitstream 228 is transmitted in packets over the network, the decoder may depacketize the video bitstream 228 before feeding it to the binary decoding stage 302.

[0056]

[0078] 3B shows a schematic diagram of another example of a decoding process 300B consistent with an embodiment of the present disclosure. The process 300B may be modified from the process 300A. For example, the process 300B may be used by a decoder that complies with a hybrid video coding standard (e.g., H.26x series). Compared to the process 300A, the process 300B further divides the prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044, and additionally includes a loop filter stage 232 and a buffer 234.

[0057]

[0079] In the process 300B, for a coded elementary processing unit (referred to as a "current BPU") of a coded picture being decoded (referred to as a "current picture"), the prediction data 206 decoded by the decoder from the binary decoding stage 302 may include various types of data depending on which prediction mode was used by the encoder to code the current BPU. For example, if intra prediction was used by the encoder to code the current BPU, the prediction data 206 may include a prediction mode indicator (e.g., a flag value) indicating intra prediction, parameters of the intra prediction operation, etc. The parameters of the intra prediction operation may include, for example, the location (e.g., coordinates) of one or more neighboring BPUs used as a reference, the size of the neighboring BPU, parameters of extrapolation, the direction of the neighboring BPU relative to the original BPU, etc. In another example, if inter prediction was used by the encoder to code the current BPU, the prediction data 206 may include a prediction mode indicator (e.g., a flag value) indicating inter prediction, parameters of the inter prediction operation, etc. Parameters for inter-prediction operations may include, for example, the number of reference pictures associated with the current BPU, weights respectively associated with the reference pictures, positions (e.g., coordinates) of one or more matching regions within each reference picture, one or more motion vectors respectively associated with the matching regions, etc.

[0058]

[0080] Based on the prediction mode indicator, the decoder may decide whether to perform spatial prediction (e.g., intra prediction) in the spatial prediction stage 2042 or temporal prediction (e.g., inter prediction) in the temporal prediction stage 2044. Details of performing such spatial or temporal prediction are shown in FIG. 2B and will not be repeated below. After performing such spatial or temporal prediction, the decoder may generate a predicted BPU 208. As described in FIG. 3A, the decoder may add the predicted BPU 208 and the reconstructed residual BPU 222 to generate a prediction reference 224.

[0059]

[0081] In the process 300B, the decoder can feed the predicted reference 224 to the spatial prediction stage 2042 or the temporal prediction stage 2044 for performing a prediction operation in the next iteration of the process 300B. For example, if the current BPU is decoded using intra prediction in the spatial prediction stage 2042, after generating the prediction reference 224 (e.g., the decoded current BPU), the decoder can directly feed the prediction reference 224 to the spatial prediction stage 2042 for later use (e.g., to extrapolate the next BPU of the current picture). If the current BPU is decoded using inter prediction in the temporal prediction stage 2044, after generating the prediction reference 224 (e.g., the reference picture to which all BPUs are decoded), the encoder can feed the prediction reference 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., blocking artifacts). The decoder can apply a loop filter to the prediction reference 224 in the manner described in FIG. 2B. The loop filtered reference pictures may be stored in a buffer 234 (e.g., a decoded picture buffer in a computer memory) for later use (e.g., for use as inter-prediction reference pictures for future encoded pictures of the video bitstream 228). The decoder may store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, if the prediction mode indicator in the prediction data 206 indicates that inter prediction was used to encode the current BPU, the prediction data may further include loop filter parameters (e.g., loop filter strength).

[0060]

[0082] FIG. 4 is a block diagram of an example of a device 400 for encoding or decoding video consistent with an embodiment of the present disclosure. As shown in FIG. 4, the device 400 may include a processor 402. When the processor 402 executes instructions described herein, the device 400 may become a dedicated machine for encoding or decoding video. The processor 402 may be any type of circuitry capable of manipulating or processing information. For example, the processor 402 may include any combination of any number of central processing units ("CPUs"), graphics processing units ("GPUs"), neural processing units ("NPUs"), microcontroller units ("MCUs"), optical processors, programmable logic controllers, microcontrollers, microprocessors, digital signal processors, intellectual property (IP) cores, programmable logic arrays (PLAs), programmable array logic (PALs), general purpose array logic (GALs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), systems on chips (SoCs), application specific integrated circuits (ASICs), and the like. In some embodiments, processor 402 may be a set of processors grouped together as a single logical entity. For example, as shown in FIG. 4, processor 402 may include multiple processors including processor 402a, processor 402b, and processor 402n.

[0061]

[0083] The device 400 may also include a memory 404 configured to store data (e.g., a set of instructions, computer code, intermediate data, etc.). For example, as shown in FIG. 4, the stored data may include program instructions (e.g., program instructions for implementing steps in a process 200A, 200B, 300A, or 300B) and data for processing (e.g., video sequence 202, video bitstream 228, or video stream 304). The processor 402 may access the program instructions and data for processing (e.g., via bus 410) and execute the program instructions to operate on or process the data for processing. The memory 404 may include high-speed random access storage or non-volatile storage. In some embodiments, the memory 404 may include any combination of any number of random access memories (RAMs), read-only memories (ROMs), optical disks, magnetic disks, hard drives, solid-state drives, flash drives, security digital (SD) cards, memory sticks, compact flash (CF) cards, and the like. Memory 404 may also be a collection of memories (not shown in FIG. 4) grouped together as a single logical entity.

[0062]

[0084] Bus 410 , such as an internal bus (eg, a CPU memory bus), an external bus (eg, a Universal Serial Bus port, a Peripheral Component Interconnect Express port), etc., may be a communication device that transfers data between components within device 400 .

[0063]

[0085] For ease of explanation and without ambiguity, the present disclosure refers to the processor 402 and other data processing circuitry collectively as the "data processing circuitry." The data processing circuitry may be implemented entirely as hardware or as a combination of software, hardware, or firmware. In addition, the data processing circuitry may be a single, independent module, or may be fully or partially combined within any other component of the device 400.

[0064]

[0086] The device 400 may further include a network interface 406 for providing wired or wireless communication with a network (e.g., the Internet, an intranet, a local area network, a mobile communications network, etc.) In some embodiments, the network interface 406 may include any combination of any number of network interface controllers (NICs), radio frequency (RF) modules, transponders, transceivers, modems, routers, gateways, wired network adapters, wireless network adapters, Bluetooth adapters, infrared adapters, near field communication ("NFC") adapters, cellular network chips, etc.

[0065]

[0087] In some embodiments, device 400 may further optionally include a peripheral interface 408 for providing connection to one or more peripheral devices. As shown in Figure 4, the peripheral devices may include, but are not limited to, a cursor control device (e.g., a mouse, a touchpad or a touch screen), a keyboard, a display (e.g., a cathode ray tube display, a liquid crystal display or a light emitting diode display), a video input device (e.g., a camera or an input interface coupled to a video archive), and the like.

[0066]

[0088] It should be noted that a video codec (e.g., a codec that executes processes 200A, 200B, 300A, or 300B) can be implemented as any combination of any software or hardware modules in device 400. For example, some or all of the stages of processes 200A, 200B, 300A, or 300B can be implemented as one or more software modules of device 400, such as program instructions loadable into memory 404. In another example, some or all of the stages of processes 200A, 200B, 300A, or 300B can be implemented as one or more hardware modules of device 400, such as dedicated data processing circuitry (e.g., FPGA, ASIC, NPU, etc.).

[0067]

[0089] In VVC, a picture is divided into one or more tile rows and one or more tile columns. A tile is a set of CTUs that cover a rectangular area of ​​the picture. The CTUs within a tile are scanned in raster scan order within that tile. A slice consists of an integer number of complete tiles or an integer number of consecutive complete CTU rows within a tile of a picture. As a result, each vertical slice boundary is also a vertical tile boundary. A horizontal boundary of a slice is not a tile boundary, but may consist of a horizontal CTU boundary within the tile. This occurs when a tile is divided into multiple rectangular slices, each consisting of an integer number of consecutive complete CTU rows within the tile.

[0068]

[0090] In VVC, a coded video bitstream or byte stream, which is a sequence of bits in the form of network abstraction layer (NAL) units, forms one or more coded video sequences (CVS), each of which is composed of one or more coded layer video sequences (CLVS). A CLVS is a sequence of picture units (PUs), where each PU contains exactly one coded picture.

[0069]

[0091] A PU consists of zero or one picture header (PH) NAL unit that contains as payload a picture header syntax structure, one coded picture that contains one or more video coding layer (VCL) NAL units, and zero or more other non-VCL NAL units. A VCL NAL unit contains a coded slice that consists of a slice header and slice data.

[0070]

[0092] VVC allows the quantization parameter (QP) to range from 0 to 63, and the signaling of the initial QP can be modified accordingly. If a non-zero value of slice_qp_delta is coded in the slice header, the initial value of SliceQpY is modified at the slice level. In particular, the value of init_qp_minus26 is modified to be in the range of (-26+QpBdOffsetY) to +37. If the size of the transform block is not a power of 4, the transform coefficients are processed with modifications to the QP or QP levelScale table, rather than by multiplication by 181 / 256 (or 181 / 128), to compensate for the implicit scaling due to the transform process. For transform skip blocks, the minimum allowed QP is defined as 4, because when QP equals 4, the quantization step size becomes 1.

[0071]

[0093] In addition, the QP value can vary per CU or per quantization group. The delta QP values ​​for the luma and chroma components can be signaled separately.

[0072]

[0094] For each luma coded block, the variable qP Y_PREV First, we derive it as follows: - If one or more of the following conditions are true: PY_PREV Set equal to SliceQpY: - The current quantization group is the first quantization group in the slice. - The current quantization group is the first quantization group in the tile. - Otherwise, qP Y_PREV is the luma quantization parameter Qp of the last luma coding unit in the previous quantization group in decoding order. Y Set it equal to

[0073]

[0095] Second, the variable qP Y_A is derived as follows: - qP if one or more of the following conditions are true: Y_A qP Y_PREVSet it equal to: - The left neighboring block of the current quantization group is not available. - The left neighboring block of the current quantization group and the current coding block are in different coding tree blocks (CTB). - Otherwise, qP Y_A Set LMT equal to the luma quantization parameter of the upper coded unit of the current quantization group.

[0074]

[0096] Third, the variable qP Y_B is derived as follows: - qP if one or more of the following conditions are true: Y_B qP Y_PREV Set it equal to: - The neighboring block above the current quantization group cannot be utilized. - The neighboring block above the current quantization group and the current coding block are in different coding tree blocks (CTBs). - Otherwise, qP Y_B Set LMT equal to the luma quantization parameter of the left coded unit of the current quantization group.

[0075]

[0097] Fourth, if the current quantization group is the first quantization group in a coding tree block (CTB) row in a block, and the neighboring block above the current quantization group can be utilized, Set qPY_PRED to qPY_B, Otherwise qPY_PRED=(qPY_A+qPY_B+1)>>1

[0076]

[0098] After deriving qPY_PRED, the quantization parameter Qp' of the current luma coded block is calculated using Equation 1 below: Y can be derived: Qp' Y =((qPY_PRED+CuQpDeltaVal+64+2*QpBdOffsetY)%(64+QpBdOffsetY)) (Equation 1) where QpBdOffsetY is equal to 6*sps_bitdepth_minus8, and the variable CuQpDeltaVal specifies the difference between the quantization parameter of a luma coded block and its predicted value.

[0077]

[0099] In VVC, CuQpDeltaVal is specified as cu_qp_delta_abs*(1-2*cu_qp_delta_sign_flag), where cu_qp_delta_abs and cu_qp_delta_sign_flag are syntax elements signaled in the bitstream at the CU level. If cu_qp_delta_abs and cu_qp_delta_sign_flag are not present in the bitstream, CuQpDeltaVal can be inferred to be 0.

[0078]

[0100] The quantization parameter for the chroma coding block is Qp Y The chroma quantization parameter (Qp Cb , Qp Cr , Qp CbCr ) and the luma quantization parameter Qp' can be signaled in the bitstream. In VVC, the offset between the chroma quantization parameter Qp' can be calculated using Equations 2-4 below. Cb and Qp' Cr , and Qp', the QP for joint Cb-Cr coding. CbCr can be derived: Qp' Cb =Clip3(-QpBdOffset c ,63,qP Cb +pps_cb_qp_offset+slice_cb_qp_offset+CuQpOffset Cb )+QpBdOffset C (Equation 2) Qp' Cr =Clip3(-QpBdOffset c ,63,qP Cr +pps_cr_qp_offset+slice_cr_qp_offset+CuQpOffset Cr)+QpBdOffset C (Equation 3) Qp' CbCr =Clip3(-QpBdOffset c ,63,qP CbCr +pps_cbcr_qp_offset+slice_cbcr_qp_offset+CuQpOffset CbCr )+QpBdOffset C (Equation 4) However, qP Cb , qP Cr , and qP CbCr Qp using equations 5-8 Y can be derived from a lookup table with the input of the clipped value: qPi Chroma =Clip3(-QpBdOffset,63,Qp Y -QpBdOffset) (Equation 5) qP Cb =ChromaQpTable[0][qP Chroma ] (Equation 6) qP Cr =ChromaQpTable[1][qP Chroma ] (Equation 7) qP CbCr =ChromaQpTable[2][qP Chroma ] (Equation 8)

[0079]

[0101] If cu_chroma_qp_offset_flag is equal to 0, CuQpOffset Cb , CuQpOffset Cr、 and CuQpOffset CbCr is set to 0 and can be derived using equations 9-11 when cu_chroma_qp_offset_flag is equal to 1: CuQpOffset Cb =cb_qp_offset_list[cu_chroma_qp_offset_idx] (Equation 9) CuQpOffset Cr=cr_qp_offset_list[cu_chroma_qp_offset_idx] (Equation 10) CuQpOffset CbCr =joint_cbcr_qp_offset_list[cu_chroma_qp_offset_idx] (Equation 11) where cu_chroma_qp_offset_flag and cu_chroma_qp_offset_idx are syntax elements that are signaled in the bitstream.

[0080]

[0102] As discussed above, cu_qp_delta_abs and cu_qp_delta_sign_flag are signaled to derive CuQpDeltaVal, which can be used to derive the QP. Cb , CuQpOffset Cr , and CuQpOffset CbCr To derive, cu_chroma_qp_offset_flag, cu_chroma_qp_offset_idx, cb_qp_offset_list[i], cr_qp_offset_list[i], and joint_cbcr_qp_offset_list[i] are signaled.

[0081]

[0103] The following is an introduction to the signaling process of the relevant syntax: First, cu_qp_delta_enabled_flag, cu_qp_delta_subdiv, cu_chroma_qp_offset_enabled_flag, and cu_chroma_qp_offset_subdiv can be signaled within a Picture Parameter Set (PPS), as shown in Figure 5, which shows an example PPS syntax for CU delta QP.

[0082]

[0104] The variables IsCuQpDeltaCoded and IsCuChromaQpOffsetCoded, the position of the quantization parameter group, and the variables qgOnY and qgOnC can then be derived at the coding tree level, as shown in FIG. 6 which illustrates an example coding tree syntax for CU delta QP.

[0083]

[0105] Further, as shown in FIG. 7, which illustrates an exemplary transform unit level syntax for CU delta QP, cu_qp_delta_abs / cu_qp_delta_sign_flag and cu_chroma_qp_offset_flag / cu_chroma_qp_offset_idx are signaled in the transform unit, provided that IsCuQpDeltaCoded and IsCuChromaQpOffsetCoded are derived at the coded unit level.

[0084]

[0106] In the example of Figure 5, cu_qp_delta_subdiv specifies the maximum cbSubdiv value for coded units that carry cu_qp_delta_abs and cu_qp_delta_sign_flag, and cu_chroma_qp_offset_subdiv specifies the maximum cbSubdiv value for coded units that carry cu_chroma_qp_offset_flag. cbSubdiv is a variable whose value is related to the size of the coded unit. Smaller coded units have larger cbSubdiv values. Splitting a coded unit into multiple sub-coded units increases the value of cbSubdiv. The range of values ​​for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv depends on a variable called MaxMttDepthY, which is derived based on the slice level and slice type. MaxMttDepthY=slice_max_mtt_hierarchy_depth_luma (Equation 12) However, slice_max_mtt_hierarchy_depth_luma is signaled in the slice header, as shown in FIG. 8, which shows an example slice header syntax.

[0085]

[0107] As explained above, two syntax elements cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are signaled within the PPS level to determine the maximum depth of a coded unit that can carry cu_qp_delta_abs / cu_qp_delta_sign_flag and cu_chroma_qp_offset_flag. However, the value range of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv depends on the variable MaxMttDepthY, which is derived based on the slice level and slice type. Thus, the PPS level syntax elements depend on the slice level syntax.

[0086]

[0108] In the bitstream syntax structure, the PPS is at a higher level than the slice level, and the syntax for the PPS comes before the slice syntax. In the decoder, when parsing the low-level syntax, it can refer to the values ​​of the high-level syntax. However, when parsing the high-level syntax, it cannot refer to the values ​​of the low-level syntax. Therefore, in the current VVC technique, the dependency of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv on the slice header syntax causes a logical problem that needs to be solved.

[0087]

[0109] To address the above problems, various embodiments of the present disclosure provide a solution. In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv can be moved to the slice header after slice_max_mtt_hierarchy_depth_luma is signaled. As a result, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are no longer PPS-level syntax elements. An example of slice header syntax is shown in FIG. 9 (e.g., element 901).

[0088]

[0110] In the example shown in Figure 9, the cu_qp_delta_enabled_flag and the cu_chroma_qp_offset_enabled_flag are signaled in the PPS. In some embodiments, the cu_qp_delta_enabled_flag and the cu_chroma_qp_offset_enabled_flag may be signaled in the slice header as shown in Figure 10 (e.g., element 1001).

[0089]

[0111] In the example shown in FIG. 10, the range of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv can be determined as follows. For example, the value range of cu_qp_delta_subdiv can be specified as follows: If slice_type is equal to I, the value of cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+MaxMttDepthY) inclusive. Otherwise (slice_type is not equal to I), the value of cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+MaxMttDepthY). If not present, it can be inferred that the value of cu_qp_delta_subdiv is equal to 0.

[0090]

[0112] The range of values ​​for cu_chroma_qp_offset_subdiv can be specified as follows: If slice_type is equal to I, the value of cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+MaxMttDepthY). Otherwise (slice_type is not equal to I), the value of cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+MaxMttDepthY). If not present, the value of cu_chroma_qp_offset_subdiv can be inferred to be equal to 0.

[0091]

[0113] In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are moved to the picture header, and at the same time the syntax elements used to derive MaxMttDepthY are also moved to the picture header, so that the ranges of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are independent of the slice-level syntax.

[0092]

[0114] Since one picture may contain multiple slices with different slice types, inter and intra. Therefore, in this embodiment, cu_qp_delta_subdiv is divided into two syntax elements, namely, ph_cu_qp_delta_subdiv_intra_slice and ph_cu_qp_delta_subdiv_inter_slice. cu_chroma_qp_offset_subdiv is divided into two syntax elements, namely, ph_cu_chroma_qp_offset_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice. ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice are for intra slices in the current picture, and ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice are for inter slices in the current picture. Similarly, two syntax elements, namely ph_max_mtt_hierarchy_depth_intra_slice_luma and ph_max_mtt_hierarchy_depth_inter_slice, are signaled for MaxMttDepthY of intra slices and inter slices.

[0093]

[0115] An example of a picture header syntax is shown in Table 11 of Figure 11. As shown in Table 11, ph_cu_qp_delta_subdiv_intra_slice (e.g., element 1101), ph_cu_chroma_qp_offset_subdiv_intra_slice (e.g., element 1102), ph_cu_qp_delta_subdiv_inter_slice (e.g., element 1103), and ph_cu_chroma_qp_offset_subdiv_inter_slice (e.g., element 1104) are shown in italics and gray.

[0094]

[0116] For intra slices, ph_cu_qp_delta_subdiv_intra_slice specifies the maximum cbSubdiv value of coded units in an intra slice that convey cu_qp_delta_abs and cu_qp_delta_sign_flag. The value of ph_cu_qp_delta_subdiv_intra_slice is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+ph_max_mtt_hierarchy_depth_intra_slice_luma). If not present, the value of ph_cu_qp_delta_subdiv_intra_slice can be inferred to be equal to 0.

[0095]

[0117] ph_cu_chroma_qp_offset_subdiv_intra_slice specifies the maximum cbSubdiv value of a coded unit in an intra slice that conveys cu_chroma_qp_offset_flag. The value of ph_cu_chroma_qp_offset_subdiv_intra_slice is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+ph_max_mtt_hierarchy_depth_intra_slice_luma). If not present, the value of ph_cu_chroma_qp_offset_subdiv_intra_slice can be inferred to be equal to 0.

[0096]

[0118] In the disclosed embodiment, ph_max_mtt_hierarchy_depth_intra_slice_luma is signaled in the picture header to specify the maximum hierarchical depth of a coding unit resulting from a multi-type tree partition of a quadtree leaf in a slice with sh_slice_type equal to "I" (i.e., an intra-predicted slice). CtbLog2SizeY and MinQtLog2SizeIntraY are derived using Equations 13-15 below, where CtbLog2SizY represents the size of a luma coding tree block of a coding tree unit in a slice with slice_type equal to "I" (i.e., an intra-predicted slice) and MinQtLog2SizeIntraY represents the minimum size in luma samples of a luma leaf block resulting from a quadtree partition of a coding tree unit in a slice with slice_type equal to "I". CtbLog2SizeY=sps_log2_ctu_size_minus5+5 (Equation 13) MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY (Equation 14) MinCbLog2SizeY=sps_log2_min_luma_coding_block_size_minus2+2 (Equation 15)

[0097]

[0119] sps_log2_ctu_size_minus5, sps_log2_diff_min_qt_min_cb_intra_slice_luma, and sps_log2_min_luma_coding_block_size_minus2 are syntax elements signaled within the SPS.

[0098]

[0120] The variable CuQpDeltaSubdiv is derived as the maximum cbSubdiv value of coded units that carry cu_qp_delta_abs and cu_qp_delta_sign_flag, and the variable CuChromaQpOffsetSubdiv is derived as the maximum cbSubdiv value of coded units that carry cu_chroma_qp_offset_flag. These two variables are derived as Equation 16 and Equation 17, respectively. CuQpDeltaSubdiv=ph_cu_qp_delta_subdiv_intra_slice (Equation 16) CuChromaQpOffsetSubdiv=ph_cu_chroma_qp_offset_subdiv_intra_slice (Equation 17)

[0099]

[0121] For inter slices, ph_cu_qp_delta_subdiv_inter_slice specifies the maximum cbSubdiv value of coded units within an inter slice that carry cu_qp_delta_abs and cu_qp_delta_sign_flag. The value of ph_cu_qp_delta_subdiv_inter_slice may be in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+ph_max_mtt_hierarchy_depth_inter_slice). If not present, the value of ph_cu_qp_delta_subdiv_inter_slice can be inferred to be equal to 0. ph_cu_chroma_qp_offset_subdiv_inter_slice specifies the maximum cbSubdiv value of coded units within an inter slice that carry cu_chroma_qp_offset_flag. The value of ph_cu_chroma_qp_offset_subdiv_inter_slice is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+ph_max_mtt_hierarchy_depth_inter_slice). If not present, the value of ph_cu_chroma_qp_offset_subdiv_inter_slice can be inferred to be equal to 0.

[0100]

[0122] ph_max_mtt_hierarchy_depth_inter_slice may be signaled in the picture header and specifies the maximum hierarchical depth of a coding unit resulting from a multi-type tree partition of quadtree leaves in slices with sh_slice_type not equal to "I" (i.e., inter-predicted slices with slice_type equal to "P" or "B"). CtbLog2SizY and MinQtLog2SizeInterY are derived using Equations 18-20 below, where CtbLog2SizY represents the size of a luma coding tree block of a coding tree unit in slices with slice_type not equal to "I" (i.e., inter-predicted slices with slice_type equal to "P" or "B") and MinQtLog2SizeInterY represents the minimum size in luma samples of a luma leaf block resulting from a quadtree partition of a coding tree unit in slices with slice_type not equal to "I". CtbLog2SizeY=sps_log2_ctu_size_minus5+5 (Equation 18) MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice_luma+MinCbLog2SizeY (Equation 19) MinCbLog2SizeY=sps_log2_min_luma_coding_block_size_minus2+2 (Equation 20)

[0101]

[0123] sps_log2_ctu_size_minus5, sps_log2_diff_min_qt_min_cb_inter_slice_luma, and sps_log2_min_luma_coding_block_size_minus2 are syntax elements signaled within the SPS.

[0102]

[0124] The variable CuQpDeltaSubdiv is derived as the maximum cbSubdiv value of coded units that carry cu_qp_delta_abs and cu_qp_delta_sign_flag, and the variable CuChromaQpOffsetSubdi is derived as the maximum cbSubdiv value of coded units that carry cu_chroma_qp_offset_flag. These two variables are derived as Equation 21 and Equation 22, respectively. CuQpDeltaSubdiv=ph_cu_qp_delta_subdiv_inter_slice (Equation 21) CuChromaQpOffsetSubdiv=ph_cu_chroma_qp_offset_subdiv_inter_slice (Equation 22)

[0103]

[0125] In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may both be signaled at the PPS level and in the slice header. For example, pps_cu_qp_delta_subdiv and pps_cu_chroma_qp_offset_subdiv are signaled in the PPS syntax as shown in Figure 12 (e.g., elements 1201 and 1202). slice_cu_qp_delta_subdiv and slice_cu_chroma_qp_offset_subdiv are also signaled in the slice header as shown in Figure 13 (e.g., element 1301).

[0104]

[0126] In some embodiments, the range of pps_cu_qp_delta_subdiv and pps_cu_chroma_qp_offset_subdiv depends on the syntax of the sequence parameter set (SPS), as shown in the following example. In this example, the value range of pps_cu_qp_delta_subdiv is specified as follows: The value of pps_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+SpsMaxMttDepthY). If not present, the value of pps_cu_qp_delta_subdiv can be inferred to be equal to 0. The value range of pps_cu_chroma_qp_offset_subdiv is specified as follows: The value of pps_cu_chroma_qp_offset_subdiv can be in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+SpsMaxMttDepthY). If not present, the value of pps_cu_chroma_qp_offset_subdiv can be inferred to be equal to 0.

[0105]

[0127] When ctbLog2SizeY is defined, MinQtLog2SizeY and SpsMaxMttDepthY can be derived as follows:

[0106]

[0128] In one way, MinQtLog2SizeY is: min(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) or max(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) It can be derived as:

[0107]

[0129] It will be appreciated that MinQtLog2SizeIntraY and MinQtLog2SizeIntraY can be derived using a variety of techniques, such as those defined in VVC Draft 6.

[0108]

[0130] Alternatively, the value of MinQtLog2SizeY can be derived based on the following equation 23: MinQtLog2SizeY=sps_log2_diff_min_qt_min_cb_luma+MinCbLog2SizeY (Equation 23)

[0109]

[0131] 14 (eg, element 1401). It will be appreciated that MinCbLog2SizeY can be derived using various techniques, such as those defined in VVC Draft 6.

[0110]

[0132] Regarding SpsMaxMttDepth, in one way SpsMaxMttDepthY can be derived as follows: min(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) or max(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) However, sps_max_mtt_hierarchy_depth_intra_slice_luma and sps_max_mtt_hierarchy_depth_inter_slice may be signaled within the SPS.

[0111]

[0133] In an alternative way, the value of SpsMaxMttDepthY can be derived as follows: SpsMaxMttDepthY=sps_max_mtt_depth_luma (Equation 24) However, sps_max_mtt_depth_luma may be signaled within the SPS as shown in FIG. 14 (eg, element 1402).

[0112]

[0134] In the above example, the PPS syntax elements pps_cu_qp_delta_subdiv and pps_cu_chroma_qp_offset_subdiv depend on the SPS syntax. Such a parsing dependency between the PPS and the SPS may be undesirable. To address this dependency issue, in some embodiments, the value range of pps_cu_qp_delta_subdiv may be specified as follows:

[0113]

[0135] The value of pps_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+ppsMaxMttDepthY). If it is not present, it can be inferred that the value of pps_cu_qp_delta_subdiv is equal to 0.

[0114]

[0136] The value range of pps_cu_chroma_qp_offset_subdiv can be specified as follows: The value of pps_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+ppsMaxMttDepthY). If not present, the value of pps_cu_chroma_qp_offset_subdiv can be inferred to be equal to 0.

[0115]

[0137] CtbLog2SizeY, MinQtLog2SizeY, and ppsMaxMttDepthY are derived as follows: CtbLog2SizeY=pps_log2_ctb_size (Equation 25) MinQtLog2SizeY=pps_log2_min_qt (Equation 26) ppsMaxMttDepthY=pps_max_mtt_depth_luma (Equation 27)

[0116]

[0138] The pps_log2_ctb_size, pps_log2_min_qt, and pps_max_mtt_depth_luma may be signaled within the PPS as shown in FIG. 15 (eg, element 1501).

[0117]

[0139] In the above example, the range of slice_cu_qp_delta_subdiv and slice_cu_chroma_qp_offset_subdiv depends on the slice header syntax. For example, the value range of slice_cu_qp_delta_subdiv can be specified as follows: If slice_type is equal to I, the value of slice_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+SliceMaxMttDepthY). Otherwise (slice_type is not equal to I), the value of slice_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+SliceMaxMttDepthY). If not present, the value of slice_cu_qp_delta_subdiv can be inferred to be equal to 0 or pps_cu_qp_delta_subdiv.

[0118]

[0140] The value range of slice_cu_chroma_qp_offset_subdiv can be specified as follows: If slice_type is equal to I, the value of slice_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+SliceMaxMttDepthY). Otherwise (slice_type is not equal to I), the value of slice_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+SliceMaxMttDepthY). If not present, the value of slice_cu_chroma_qp_offset_subdiv can be inferred to be equal to 0 or pps_cu_chroma_qp_offset_subdiv.

[0119]

[0141] If CtbLog2SizeY, MinQtLog2SizeIntraY, and MinQtLog2SizeInterY are defined, SliceMaxMttDepthY is SliceMaxMttDepthY=slice_max_mtt_hierarchy_depth_luma (Equation 28) It can be derived as:

[0120]

[0142] slice_max_mtt_hierarchy_depth_luma can be signaled in the slice header.

[0121]

[0143] In the above example, cu_qp_delta_subdiv can be inferred to be slice_cu_qp_delta_subdiv. Alternatively, cu_qp_delta_subdiv can be inferred to be pps_cu_qp_delta_subdiv first, and if slice_cu_qp_delta_subdiv exists, slice_cu_qp_delta_subdiv overrides it, and cu_qp_delta_subdiv can be inferred to be slice_cu_qp_delta_subdiv. The value of cu_qp_delta_subdiv is the Qp Y can be used to derive

[0122]

[0144] Furthermore, cu_chroma_qp_offset_subdiv can be inferred to be slice_cu_chroma_qp_offset_subdiv. Alternatively, cu_chroma_qp_offset_subdiv can be inferred to be pps_cu_chroma_qp_offset_subdiv first, and if slice_cu_chroma_qp_offset_subdiv exists, slice_cu_chroma_qp_offset_subdiv overrides it, and cu_chroma_qp_offset_subdiv can be inferred to be slice_cu_chroma_qp_offset_subdiv. The value of cu_chroma_qp_offset_subdiv is the Qp Cb , Qp Cr , Q.P. CbCr can be used to derive

[0123]

[0145] In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may both be signaled at the SPS level and in the slice header. sps_cu_qp_delta_subdiv and sps_cu_chroma_qp_offset_subdiv may be signaled in the SPS as shown in Figure 16 (e.g., element 1601), and slice_cu_qp_delta_subdiv and slice_cu_chroma_qp_offset_subdiv are signaled in the slice header as shown in Figure 17 (e.g., element 1701).

[0124]

[0146] In some embodiments, the range of sps_cu_qp_delta_subdiv and sps_cu_chroma_qp_offset_subdiv depends on the syntax of the SPS. For example, the value range of sps_cu_qp_delta_subdiv can be specified as follows: The value of sps_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+SpsMaxMttDepthY). If not present, the value of sps_cu_qp_delta_subdiv can be inferred to be equal to 0. The value range of sps_cu_chroma_qp_offset_subdiv is specified as follows: The value of sps_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+SpsMaxMttDepthY). If not present, the value of sps_cu_chroma_qp_offset_subdiv can be inferred to be equal to 0.

[0125]

[0147] When ctbLog2SizeY is defined, MinQtLog2SizeY and SpsMaxMttDepthY can be derived as follows:

[0126]

[0148] In some ways, MinQtLog2SizeY is min(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) or max(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) It can be derived as:

[0127]

[0149] However, MinQtLog2SizeIntraY and MinQtLog2SizeIntraY can be derived using various techniques as specified in VVC Draft 6.

[0128]

[0150] In an alternative approach, the value of MinQtLog2SizeY can be derived using Equation 29 below. MinQtLog2SizeY=sps_log2_diff_min_qt_min_cb_luma+MinCbLog2SizeY (Equation 29)

[0129]

[0151] sps_log2_diff_min_qt_min_cb_luma may be signaled in the SPS as shown in Figure 18 (e.g., element 1801). It will be appreciated that MinCbLog2SizeY may be derived using various techniques such as those defined in VVC Draft 6.

[0130]

[0152] Regarding SpsMaxMttDepthY, in one way, SpsMaxMttDepthY is min(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) or max(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) It can be derived as:

[0131]

[0153] sps_max_mtt_hierarchy_depth_intra_slice_luma and sps_max_mtt_hierarchy_depth_inter_slice can be signaled within the SPS.

[0132]

[0154] Alternatively, SpsMaxMttDepthY can be SpsMaxMttDepthY=sps_max_mtt_depth_luma (Equation 30) It can be derived as:

[0133]

[0155] sps_max_mtt_depth_luma may be signaled within the SPS as shown in FIG. 18 (eg, element 1802).

[0134]

[0156] Moreover, in the above example, the range of slice_cu_qp_delta_subdiv and slice_cu_chroma_qp_offset_subdiv depends on the slice header syntax. For example, the value range of slice_cu_qp_delta_subdiv can be specified as follows: If slice_type is equal to I, the value of slice_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+SliceMaxMttDepthY). Otherwise (slice_type is not equal to I), the value of slice_cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+SliceMaxMttDepthY). If not present, the value of slice_cu_qp_delta_subdiv can be inferred to be equal to 0 or sps_cu_qp_delta_subdiv.

[0135]

[0157] The value of slice_cu_chroma_qp_offset_subdiv can be specified as follows: If slice_type is equal to I, the value of slice_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+SliceMaxMttDepthY). Otherwise (slice_type is not equal to I), the value of slice_cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+SliceMaxMttDepthY). If not present, the value of slice_cu_chroma_qp_offset_subdiv can be inferred to be equal to 0 or sps_cu_chroma_qp_offset_subdiv.

[0136]

[0158] If CtbLog2SizeY, MinQtLog2SizeIntraY, and MinQtLog2SizeInterY are defined, SliceMaxMttDepthY is SliceMaxMttDepthY=slice_max_mtt_hierarchy_depth_luma (Equation 31) It can be derived as:

[0137]

[0159] slice_max_mtt_hierarchy_depth_luma can be signaled in the slice header.

[0138]

[0160] In the above example, cu_qp_delta_subdiv can be inferred to be slice_cu_qp_delta_subdiv. Alternatively, cu_qp_delta_subdiv can be inferred to be sps_cu_qp_delta_subdiv first, and if slice_cu_qp_delta_subdiv exists, slice_cu_qp_delta_subdiv overrides it, and cu_qp_delta_subdiv can be inferred to be slice_cu_qp_delta_subdiv. Cu_qp_delta_subdiv is Qp Y can be used to derive

[0139]

[0161] Furthermore, in the above example, cu_chroma_qp_offset_subdiv can be inferred to be slice_cu_chroma_qp_offset_subdiv. Alternatively, cu_chroma_qp_offset_subdiv can be inferred to be sps_cu_chroma_qp_offset_subdiv first, and if slice_cu_chroma_qp_offset_subdiv exists, slice_cu_chroma_qp_offset_subdiv overrides it, and cu_chroma_qp_offset_subdiv can be inferred to be slice_cu_chroma_qp_offset_subdiv. Cu_chroma_qp_offset_subdiv is Qp Cb , Qp Cr , Q.P. CbCr can be used to derive

[0140]

[0162] In some embodiments, the syntax of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be signaled at the PPS level, but the range restrictions of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be modified such that they are independent of the slice syntax.

[0141]

[0163] As an example, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be signaled in the PPS as shown in FIG. 5. The value range of cu_qp_delta_subdiv may be specified as follows: The range of cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_qp_delta_subdiv may be inferred to be equal to 0. The value range of cu_chroma_qp_offset_subdiv may be specified as follows: The value of cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_chroma_qp_offset_subdiv may be inferred to be equal to 0.

[0142]

[0164] If ctbLog2SizeY is defined, MinQtLog2SizeY and MaxMttDepthY can be inferred on the SPS level. For example, MaxMttDepthY is min(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) or max(sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_inter_slice) It can be derived as:

[0143]

[0165] sps_max_mtt_hierarchy_depth_intra_slice_luma and sps_max_mtt_hierarchy_depth_inter_slice can be signaled within the SPS.

[0144]

[0166] Alternatively, MaxMttDepthY can be MaxMttDepthY=sps_max_mtt_depth_luma It can be derived as:

[0145]

[0167] sps_max_mtt_depth_luma may be signaled within the SPS as shown in FIG. 19 (eg, element 1901).

[0146]

[0168] In one way, MinQtLog2SizeY min(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) or max(MinQtLog2SizeIntraY, MinQtLog2SizeInterY) It can be derived as:

[0147]

[0169] It will be appreciated that MinQtLog2SizeIntraY and MinQtLog2SizeIntraY can be derived using a variety of techniques, such as those defined in VVC Draft 6.

[0148]

[0170] Alternatively, the value of MinQtLog2SizeY can be derived based on the following equation 32: MinQtLog2SizeY=sps_log2_diff_min_qt_min_cb_lima+MinCbLog2SizeY (Equation 32)

[0149]

[0171] sps_log2_diff_min_qt_min_cb_luma is signaled in the SPS as shown in Figure 13 (e.g., element 1301). It will be appreciated that MinCbLog2SizeY can be derived using various techniques as defined in VVC Draft 6.

[0150]

[0172] Based on the above example, the ranges of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are not overridden at the slice header level.

[0151]

[0173] In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be signaled at the PPS level, but the range limits for cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be fixed such that they are independent of slice syntax.

[0152]

[0174] For example, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be signaled in the PPS as shown in FIG. 5. The value range of cu_qp_delta_subdiv may be specified as follows: The value of cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_qp_delta_subdiv may be inferred to be equal to 0. The value range of cu_chroma_qp_offset_subdiv may be specified as follows: The value of cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_chroma_qp_offset_subdiv may be inferred to be equal to 0.

[0153]

[0175] However, CtbLog2SizeY, MinQtLog2SizeY, and MaxMttDepthY can be derived in the following manner: CtbLog2SizeY / MinQtLog2SizeY / MaxMttDepthY can be specified by a profile, or CtbLog2SizeY / MinQtLog2SizeY / MaxMttDepthY can be fixed numerical values.

[0154]

[0176] Based on the above example, the ranges of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are not overridden at the slice header level.

[0155]

[0177] In some embodiments, cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv may be signaled in the PPS as shown in FIG. 5. The value range of cu_qp_delta_subdiv may be specified as follows: The value of cu_qp_delta_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_qp_delta_subdiv may be inferred to be equal to 0. The value range of cu_chroma_qp_offset_subdiv is specified as follows: The value of cu_chroma_qp_offset_subdiv is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeY+MaxMttDepthY). If not present, the value of cu_chroma_qp_offset_subdiv may be inferred to be equal to 0.

[0156]

[0178] CtbLog2SizeY, MinQtLog2SizeY, and MaxMttDepthY can be inferred on the PPS level. For example, CtbLog2SizeY=pps_log2_ctb_size (Equation 33) MinQtLog2SizeY=pps_log2_min_qt (Equation 34) MaxMttDepthY=pps_max_mtt_depth_luma (Equation 35)

[0157]

[0179] The pps_log2_ctb_size, pps_log2_min_qt, and pps_max_mtt_depth_luma are signaled within the PPS as shown in FIG. 20 (eg, element 2001).

[0158]

[0180] Based on the above example, the ranges of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv are not overridden at the slice header level.

[0159]

[0181] FIG. 21 is a flow diagram of a computer-implemented method 2100 for processing video content consistent with embodiments of this disclosure.

[0160]

[0182] At step 2102, a depth parameter associated with the depth of the coded block may be received. The depth parameter may be, for example, a variable "MaxMttDepthY" derived from the maximum depth of the multi-type tree hierarchy of the luma block (e.g., "slice_max_mtt_hierarchy_depth_luma"). In some embodiments, "slice_max_mtt_hierarchy_depth_luma" may be signaled in a slice header associated with the coded block.

[0161]

[0183] The coded block may be associated with a slice. The slice may be associated with intra prediction or inter prediction. Depending on whether the slice is associated with intra prediction, a delta QP value or a chroma QP offset value may be determined for the slice associated with intra prediction. Depending on whether the slice is otherwise associated with inter prediction, a delta QP value or a chroma QP offset value may be determined for the slice associated with inter prediction. For example, if "slice_type" is equal to "I" (indicating that the slice is associated with intra prediction), the value of "cu_qp_delta_subdiv" is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+MaxMttDepthY). Otherwise, if "slice_type" is not equal to "I" (indicating that the slice is associated with inter prediction), the value of "cu_qp_delta_subdiv" is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+MaxMttDepthY). As a further example, if "slice_type" is equal to "I", then the value of "cu_chroma_qp_offset_subdiv" is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeIntraY+MaxMttDepthY). Otherwise, if "slice_type" is not equal to "I", then the value of "cu_chroma_qp_offset_subdiv" is in the range of 0 to 2*(CtbLog2SizeY-MinQtLog2SizeInterY+MaxMttDepthY).

[0162]

[0184] In some embodiments, the depth parameter may be signaled in the picture header. It will be understood that a picture may include multiple slices. For slices related to intra prediction, a corresponding delta QP value or chroma QP offset value may be determined for the slice related to intra prediction. For slices related to inter prediction, a corresponding delta QP value or chroma QP offset value may be determined for the slice related to inter prediction. For example, as discussed with respect to Table 11 of FIG. 11, ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice are signaled in the picture header to derive delta QP values ​​and chroma QP offset values ​​for slices related to inter prediction. ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice are signaled in the picture header to derive delta QP values ​​and chroma QP offset values ​​for slices related to inter prediction.

[0163]

[0185] At step 2104, at least one of a delta quantization parameter (QP) value or a chroma QP offset value may be determined based on the depth of the coded block. As discussed above, the delta QP value may be determined based on "cu_qp_delta_subdiv", and the chroma QP offset value may be determined based on "cu_chroma_qp_offset_subdiv", which may be determined based on the variable "MaxMttDepthY".

[0164]

[0186] In step 2106, a luma QP value may be derived based on the determined delta QP value, and a chroma QP value may be derived based on the determined chroma QP offset value.

[0165]

[0187] In step 2108, the coded block may be processed based on the derived luma QP value and the derived chroma QP value.

[0166]

[0188] In some embodiments, a non-transitory computer-readable storage medium is also provided that includes instructions, which may be executed by an apparatus (such as the disclosed encoder and decoder) to perform the above-described method. Typical non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROMs and EPROMs, flash EPROMs or any other flash memory, NVRAM, caches, registers, any other memory chips or cartridges, and networked versions of the same. An apparatus may include one or more processors (CPUs), input / output interfaces, network interfaces, and / or memory.

[0167]

[0189] The embodiments may be further described using the following clauses: 1. A computer-implemented method comprising: receiving a bitstream including coded video data; Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameter; and Determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters. A method comprising: 2. Determining a first parameter of the coding block includes: Determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with an intra-predicted slice, the first parameter to be a parameter associated with the intra-predicted slice; or determining, in response to the coded block being associated with an inter-predicted slice, the first parameter to be a parameter associated with the inter-predicted slice; 2. The method according to claim 1, comprising: 3. The method of claim 1, wherein the first parameter is signaled within a slice header associated with the coded block. 4. The method according to claim 1, wherein the first parameter is signaled within a picture header associated with the coded block. 5. Determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and Processing the coded block based on the luma QP value and the chroma QP value 2. The method of claim 1, further comprising: 6. A system for processing video content, comprising: a memory for storing a set of instructions; and at least one processor, the at least one processor comprising: receiving a bitstream including coded video data; Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameter; and Determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters. The system is configured to execute a set of instructions to cause the system to: 7. At least one processor: Determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with an intra-predicted slice, the first parameter to be a parameter associated with the intra-predicted slice; or determining, in response to the coded block being associated with an inter-predicted slice, the first parameter to be a parameter associated with the inter-predicted slice; 7. The system of claim 6, configured to execute a set of instructions to cause the system to further: 8. The system of claim 6, wherein the first parameter is signaled within a slice header associated with the coded block. 9. The system of claim 6, wherein the first parameter is signaled within a picture header associated with the coded block. 10. At least one processor: determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and Processing the coded block based on the luma QP value and the chroma QP value 7. The system of claim 6, configured to execute a set of instructions to cause the system to further: 11. A non-transitory computer-readable medium storing instructions executable by at least one processor of a computer system, the instructions being executed by: receiving a bitstream including coded video data; Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameter; and Determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters. A non-transitory computer-readable medium for causing a computer system to perform a method comprising: 12. Method Determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with an intra-predicted slice, the first parameter to be a parameter associated with the intra-predicted slice; or determining, in response to the coded block being associated with an inter-predicted slice, the first parameter to be a parameter associated with the inter-predicted slice; 12. The non-transitory computer-readable medium of claim 11, further comprising: 13. The non-transitory computer-readable medium of claim 11, wherein the first parameter is signaled in a slice header associated with the coded block. 14. The non-transitory computer-readable medium of claim 11, wherein the first parameter is signaled within a picture header associated with the coded block. 15. The method is determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and Processing the coded block based on the luma QP value and the chroma QP value 12. The non-transitory computer-readable medium of claim 11, further comprising:

[0168]

[0190] It should be noted that relative terms such as "first" and "second" herein are used merely to distinguish one entity or operation from another and do not require or imply any actual relationship or order between those entities or operations. Furthermore, the terms "comprise," "have," "contain," and "include," as well as other similar forms, are intended to be equivalent in meaning and are non-limiting in that the items following any one of these terms are not intended to be an exhaustive listing of such items or to be limited to only the items listed.

[0169]

[0191] As used herein, unless otherwise specified, the word "or" includes all possible combinations, unless impracticable. For example, if a database is stated to include A or B, the database can include A or B, or A and B, unless otherwise specified or impracticable. As a second example, if a database is stated to include A, B, or C, the database can include A, or B, or C, or A and B, or A and C, or B and C, or A and B and C, unless otherwise specified or impracticable.

[0170]

[0192] It will be understood that the above described embodiments can be implemented by hardware or software (program code), or a combination of hardware and software. If implemented by software, the software can be stored in the above computer readable medium. The software, when executed by a processor, can perform the disclosed method. The computational units and other functional units described in this disclosure can be implemented by hardware or software, or a combination of hardware and software. Those skilled in the art will also understand that multiple of the above modules / units can be combined into one module / unit, and each of the above modules / units can be further divided into multiple sub-modules / sub-units.

[0171]

[0193] In the above specification, the embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Certain adaptations and modifications to the described embodiments may be made. Other embodiments may become apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the present disclosure being indicated by the appended claims. The order of steps depicted in the figures is for illustrative purposes only and is not intended to be limited to the particular order of steps. As such, one skilled in the art can appreciate that the steps may be performed in different orders while implementing the same method.

[0172]

[0194] Although illustrative embodiments have been disclosed in the drawings and herein, many variations and modifications thereto may be made, and therefore, although specific terms have been employed, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. 1. A method of decoding a bitstream to output one or more pictures for a video stream, comprising: receiving a bitstream; and Decoding one or more pictures using the coded information of the bitstream. wherein said decoding comprises: Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameters; and determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters; Including, The maximum value of the first parameter is The size of the luma coding treeblock per coding tree; A minimum size of luma samples in a luma reef block resulting from the coding tree-based quadtree partitioning in an intra-prediction slice or an inter-prediction slice; and a maximum hierarchical depth of a coding unit resulting from a multi-type tree split of a leaf of a quadtree within the intra-predicted slice or the inter-predicted slice; The method is determined based on the

2. Determining the first parameter of the coded block comprises: determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with the intra-prediction slice, the first parameter to be a parameter associated with the intra-prediction slice; or In response to the coded block being associated with the inter-predicted slice, determining the first parameter to be a parameter associated with the inter-predicted slice. The method of claim 1 , comprising:

3. The method of claim 1 , wherein the first parameter is signaled in at least one of a slice header or a picture header associated with the coded block.

4. the coded block is associated with the intra prediction slice, the method comprising: The method of claim 3 , wherein the maximum value of the first parameter is determined based on within the intra prediction slice.

5. the coded block is associated with the inter-prediction slice, the method comprising: The method of claim 3 , wherein the maximum value of the first parameter is determined on an intra-prediction slice basis.

6. determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and processing the coded block based on the luma QP value and the chroma QP value. The method of claim 1 further comprising:

7. 1. A method for encoding a video sequence into a bitstream, the method comprising: receiving a video sequence; encoding one or more pictures of the video sequence; and Generating the bitstream and said encoding comprises: Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameters; and determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters; Including, The maximum value of the first parameter is The size of the luma coding treeblock per coding tree; A minimum size of luma samples in a luma reef block resulting from the coding tree-based quadtree partitioning in an intra-prediction slice or an inter-prediction slice; and a maximum hierarchical depth of a coding unit resulting from a multi-type tree split of a leaf of a quadtree within the intra-predicted slice or the inter-predicted slice; The method is determined based on the

8. Determining the first parameter of the coded block comprises: determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with the intra-prediction slice, the first parameter to be a parameter associated with the intra-prediction slice; or In response to the coded block being associated with the inter-predicted slice, determining the first parameter to be a parameter associated with the inter-predicted slice. The method of claim 7, comprising:

9. The method of claim 7 , wherein the first parameter is signaled in at least one of a slice header or a picture header associated with the coded block.

10. the coded block is associated with the intra prediction slice, the method comprising: The method of claim 9 , wherein the maximum value of the first parameter is determined based on within the intra prediction slice.

11. the coded block is associated with the inter-prediction slice, the method comprising: The method of claim 9 , wherein the maximum value of the first parameter is determined based on an intra-prediction slice.

12. determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and processing the coded block based on the luma QP value and the chroma QP value. The method of claim 7 further comprising:

13. A method for storing a bitstream of a video sequence, the method comprising: receiving a video sequence; encoding one or more pictures of the video sequence; generating a bitstream; and storing said bitstream on a non-transitory computer readable medium; and said encoding comprises: Determining a first parameter of the coded block; determining one or more second parameters related to a delta quantization parameter (QP) value or a chroma QP offset value according to the first parameters; and determining at least one of the delta QP value or the chroma QP offset value according to the one or more second parameters; Including, The maximum value of the first parameter is The size of the luma coding treeblock per coding tree; A minimum size of luma samples in a luma reef block resulting from the coding tree-based quadtree partitioning in an intra-prediction slice or an inter-prediction slice; and a maximum hierarchical depth of a coding unit resulting from a multi-type tree split of a leaf of a quadtree within the intra-predicted slice or the inter-predicted slice; The method is determined based on the

14. Determining the first parameter of the coded block comprises: determining whether the coded block is associated with an intra-predicted slice or an inter-predicted slice; and determining, in response to the coded block being associated with the intra-prediction slice, the first parameter to be a parameter associated with the intra-prediction slice; or In response to the coded block being associated with the inter-predicted slice, determining the first parameter to be a parameter associated with the inter-predicted slice. The method of claim 13, comprising:

15. The method of claim 13 , wherein the first parameter is signaled in at least one of a slice header or a picture header associated with the coded block.

16. the coded block is associated with the intra prediction slice, the method comprising: The method of claim 15 , wherein the maximum value of the first parameter is determined based on within the intra prediction slice.

17. the coded block is associated with the inter-prediction slice, the method comprising: The method of claim 15 , wherein the maximum value of the first parameter is determined on an intra-prediction slice basis.

18. The method further comprising: determining a luma QP value based on the delta QP value; determining a chroma QP value based on the chroma QP offset value; and processing the coded block based on the luma QP value and the chroma QP value. The method of claim 13 further comprising:

Images