History-based RICE parameter derivation for video coding

Abstract

In some embodiments, a video decoder decodes video from a bitstream of video using history-based Rice parameter derivation. A video decoder accesses a binary string representing a partition of the video and processes each coding tree unit (CTU) in the partition to generate a decoding coefficient value in the CTU. The process includes decoding each transform unit (TU) in the CTU by updating a history counter for calculating a color component of the Rice parameter based on a first non-zero quantization level in the TU. Before the next Rice parameter is calculated, the replacement variable is updated based on the updated historical counter. Decoding the TU also includes calculating a Rice parameter of the TU based on the value of the replacement variable, and decoding a binary string corresponding to the TU in the CTU into a coefficient value of the TU based on the calculated Rice parameter.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 253,068, filed on October 6, 2021, and entitled “History-Based Rice Parameter Derivation for Video Coding,” the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure generally relates to computer-implemented methods and systems for video processing. In particular, the present disclosure relates to history-based derivation of Rice parameters for video encoding. Background Art

[0003] The ubiquitous camera-enabled devices such as smartphones, tablets, and computers make it easier than ever to capture videos or images. In addition, there is non-camera captured content (e.g., screen content) generated every day. However, even for short videos, the amount of data can be very large. Video coding technology (including video encoding and video decoding) can compress video data to be smaller, so that various videos can be stored and transmitted. Video coding has been widely used in applications such as digital television broadcasting, video transmission over the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing), DVDs and Blu-ray discs, etc. In order to reduce the storage space used to store videos and / or the network bandwidth consumption used to transmit videos, it is necessary to improve the efficiency of video coding schemes. Summary of the invention

[0004] Some embodiments relate to history-based Rice parameter derivation for video encoding. In one example, a method for decoding a video includes accessing a binary string representing a partition of the video, the partition including a plurality of coding tree units (CTUs); decoding each CTU in the plurality of CTUs in the partition, the decoding of the CTU including decoding a transform unit (TU) of the CTU by: updating a history counter StatCoeff for a color component used to calculate Rice parameters based on a first non-zero quantization level in the TU; updating a substitution variable HistValue based on the updated history counter StatCoeff before calculating the next Rice parameter; calculating the Rice parameter of the TU based on the updated substitution variable HistValue; decoding the binary string corresponding to the TU into a coefficient value of the TU based on the calculated Rice parameter; and determining a pixel value of the TU in the CTU from the coefficient value; and outputting a decoded partition of the video, the decoded partition including the decoded plurality of CTUs in the partition.

[0005] In another example, a non-transitory computer-readable medium having program code stored thereon. The program code can be executed by one or more processing devices to perform operations including: accessing a binary string representing a partition of a video, the partition including multiple CTUs; decoding each CTU in the multiple CTUs in the partition, decoding the CTU including decoding a TU of the CTU by: updating a history counter StatCoeff for a color component used to calculate a Rice parameter based on a first non-zero quantization level in the TU; updating a replacement variable HistValue based on the updated history counter StatCoeff before calculating the next Rice parameter; calculating the Rice parameter of the TU based on the updated replacement variable HistValue; decoding the binary string corresponding to the TU into a coefficient value of the TU based on the calculated Rice parameter; and determining a pixel value of the TU in the CTU from the coefficient value; and outputting a decoded partition of the video, the decoded partition including the decoded multiple CTUs in the partition.

[0006] In another example, a method for encoding a video includes: accessing a partition of a video, the partition including multiple CTUs; processing the partition of the video to generate a binary representation of the partition, the processing including: encoding each CTU of the multiple CTUs in the partition, encoding the CTU including encoding the TU of the CTU by: updating a history counter StatCoeff of a color component used to calculate a Rice parameter of the TU based on a first non-zero quantization level in the TU; updating a replacement variable HistValue based on the updated history counter StatCoeff before calculating the next Rice parameter; calculating the Rice parameter of the TU based on the updated replacement variable HistValue; and encoding the coefficient value of the TU into a binary representation corresponding to the TU in the CTU based on the calculated Rice parameter; and encoding the binary representation of the partition into a bitstream of the video.

[0007] In another example, a non-transitory computer-readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations including: accessing a partition of a video, the partition including a plurality of CTUs; processing the partition of the video to generate a binary representation of the partition, the processing including: encoding each CTU of a plurality of CTUs in the partition, decoding the CTU including encoding a TU of the CTU by: updating a history counter StatCoeff for a color component used to calculate a Rice parameter of the TU based on a first non-zero quantization level in the TU; updating a replacement variable HistValue based on the updated history counter StatCoeff before calculating a next Rice parameter; calculating the Rice parameter of the TU based on the updated replacement variable HistValue; and encoding coefficient values ​​of the TU into a binary representation corresponding to the TU in the CTU based on the calculated Rice parameters; and encoding the binary representation of the partition into a bitstream of the video.

[0008] These illustrative embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid understanding of the present disclosure. Other embodiments are discussed in the detailed description, and further description is provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The features, embodiments, and advantages of the present disclosure may be better understood by reading the following detailed description with reference to the accompanying drawings.

[0010] Figure 1 is a block diagram illustrating an example of a video encoder for implementing the embodiments presented herein.

[0011] Figure 2 is a block diagram illustrating an example of a video decoder for implementing the embodiments presented herein.

[0012] Figure 3 Depicting an example of coding tree unit partitioning of an image in a video according to some embodiments of the present disclosure.

[0013] Figure 4 Depicting an example of coding unit partitioning of a coding tree unit according to some embodiments of the present disclosure.

[0014] Figure 5 Depicted is an example of a coding block having a predetermined order for processing elements of the coding block.

[0015] Figure 6 Depicts an example of a template mode for computing local and variable values ​​for coefficients located near transform unit boundaries.

[0016] Figure 7An example of a process for encoding partitions of a video is depicted in accordance with some embodiments of the present disclosure.

[0017] Figure 8 An example of a process for decoding partitions of a video is depicted in accordance with some embodiments of the present disclosure.

[0018] Fig. 9 Depicts an example of a computing system that can be used to implement some embodiments of the present disclosure. DETAILED DESCRIPTION

[0019] Various embodiments provide for the derivation of history-based Rice parameters for video coding. As described above, more and more video data is being generated, stored, and transmitted. It is beneficial to improve the efficiency of video coding techniques so that less data is used to represent the video without compromising the visual quality of the decoded video. One method of improving coding efficiency is to compress the processed video samples into a binary code stream using as few bits as possible through entropy coding.

[0020] In entropy coding, transform coefficient data is binarized into binary bins, and coding algorithms such as context-adaptive binary arithmetic coding (CABAC) can further compress the bins into bits. Binarization requires calculation of binarization parameters, such as the Rice parameters used in the combination of truncated Rice (TR) binarization and k-th order Ep-Golomb (EGk) binarization processes specified in the universal video coding (VVC) specification. In order to improve coding efficiency, a history-based Rice parameter derivation method is used. In this method, the Rice parameters of the TU in the current CTU of a partition (e.g., an image, a slice, or a tile) are derived based on a history counter (denoted as StatCoeff), which is calculated based on the coefficients in the previous TU in the current CTU and the previous CTU of the partition. Then, the history counter is used to derive a replacement variable (denoted as HistValue), which is used to derive the Rice parameter. The history counter can be updated when processing a TU. In existing video coding standards, even if the history counter StatCoeff has been updated, the replacement variable HistValue of the TU remains unchanged. In other words, the replacement variable HistValue is only updated according to the updated history counter StatCoeff until the next TU. Therefore, using the unupdated replacement variable HistValue and the updated history counter StatCoeff to calculate the Rice parameters of the remaining positions within the current TU may result in reduced coding efficiency.

[0021] Various embodiments described herein solve these problems by updating the replacement variable HistValue whenever the history counter StatCoeff is updated, so that the updates of the replacement variable HistValue and the history counter StatCoeff are synchronized, thereby improving coding efficiency. The following non-limiting examples are provided to introduce some embodiments.

[0022] In an embodiment, once the history counter StatCoeff is updated, the replacement variable HistValue is updated. In this way, the remaining positions within the current TU are encoded using the updated history counter StatCoeff and the corresponding updated replacement variable HistValue until the replacement variable HistValue and the history counter StatCoeff are updated again. In another embodiment, the history counter StatCoeff is updated based on the first non-zero quantization level of each TU. Therefore, the operation of determining whether to update the history counter StatCoeff based on the first non-zero Golomb-Rice encoded transform coefficient (Abs_Remainment[cIdx] or dec_abs_level[cIdx]) can be omitted, thereby saving the computing power of the video encoder and decoder. In another embodiment, because the replacement variable HistValue is updated as the history counter StatCoeff is updated, the step of initializing the replacement variable HistValue at the beginning of processing each TU can be omitted to further save computing power.

[0023] Using the Rice parameters determined as described above, the video encoder can binarize the prediction residual data (e.g., the quantized transform coefficients of the residual) into binary bins and further compress the bins into bits to be included in the video bitstream using an entropy coding algorithm. On the decoder side, the decoder can decode the bitstream back into binary bins and determine the Rice parameters using any of the above methods or any combination of methods, and then determine the coefficients from the binary bins. The coefficients can be further dequantized and inversely transformed to reconstruct the video blocks for display.

[0024] As described herein, some embodiments improve video coding efficiency and computational efficiency by synchronizing the update of the replacement variable HistValue with the update of the history counter StatCoeff based on the first non-zero quantization level in the TU. In this way, the replacement variable HistValue corresponding to the updated history counter StatCoeff can be used to derive the Rice parameter of the TU, and the update operation can be simplified to speed up the processing. The above technology can become an effective coding tool in future video coding standards.

[0025] Now referring to the accompanying drawings, Figure 1 1 is a block diagram illustrating an example of a video encoder 100 for implementing the embodiments presented herein. Figure 1In the example shown, the video encoder 100 includes a partition module 112, a transform module 114, a quantization module 115, an inverse quantization module 118, an inverse transform module 119, a loop filter module 120, an intra-frame prediction module 126, an inter-frame prediction module 124, a motion estimation module 122, a decoded image buffer 130, and an entropy encoding module 116.

[0026] The input of the video encoder 100 is an input video 102 containing a sequence of images (also referred to as frames or pictures). In a block-based video encoder, for each image, the video encoder 100 uses a partitioning module 112 to divide the image into blocks 104, and each block contains a plurality of pixels. These blocks can be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. An image can include blocks of different sizes, and the block partitioning of different images of the video can also be different. Each block can be encoded using different predictions (such as intra-frame prediction, or inter-frame prediction, or mixed intra-frame and inter-frame prediction).

[0027] Typically, the first picture of a video signal is an intra-predicted picture, which is encoded using only intra-prediction. In intra-prediction mode, blocks of a picture are predicted using only data from the same picture. An intra-predicted picture can be decoded without information from other pictures. To perform intra-prediction, Figure 1 The illustrated video encoder 100 may employ an intra prediction module 126. The intra prediction module 126 is used to generate an intra prediction block (prediction block 134) using reconstructed samples in a reconstruction block 136 of a neighboring block of the same image. Intra prediction is performed according to an intra prediction mode selected for the block. The video encoder 100 then calculates the difference between the block 104 and the intra prediction block 134. The difference is referred to as a residual block 106.

[0028] To further remove redundancy from the block, the transform module 114 transforms the residual block 106 into a transform domain by applying a transform to the samples in the block. Examples of transforms may include, but are not limited to, discrete cosine transforms (DCT) or discrete sine transforms (DST). The transform values ​​may be referred to as transform coefficients, representing the residual block in the transform domain. In some examples, the residual block may be quantized directly without being transformed by the transform module 114. This is referred to as a transform skip mode.

[0029] The video encoder 100 may further quantize the transform coefficients using the quantization module 115 to obtain quantized coefficients. Quantization includes dividing the samples by the quantization step size and then rounding, while inverse quantization includes multiplying the quantized value by the quantization step size. This quantization process is called scalar quantization. Quantization is used to reduce the dynamic range of (transformed or untransformed) video samples so that fewer bits are used to represent the video samples.

[0030] Quantization of coefficients / samples within a block can be done independently, and this quantization method is used in some existing video compression standards such as H.264 and HEVC. For an N×M block, the 2D coefficients of the block can be converted into a 1-D array using a specific scan order for coefficient quantization and encoding. Quantization of coefficients within a block can utilize scan order information. For example, the quantization of a given coefficient in a block can depend on the state of previous quantized values ​​along the scan order. To further improve coding efficiency, more than one quantizer can be used. Which quantizer is used to quantize the current coefficient depends on information that is earlier than the current coefficient in the encoding / decoding scan order. This quantization method is called correlated quantization.

[0031] The degree of quantization can be adjusted using the quantization step size. For example, for scalar quantization, different quantization step sizes can be applied to achieve finer or coarser quantization. A smaller quantization step size corresponds to a finer quantization, while a larger quantization step size corresponds to a coarser quantization. The quantization step size can be indicated by a quantization parameter (QP). The quantization parameter is provided in the encoded bitstream of the video so that the video decoder can apply the same quantization parameter for decoding.

[0032] The entropy coding module 116 then encodes the quantized samples to further reduce the size of the video signal. The entropy coding module 116 is used to apply an entropy coding algorithm to the quantized samples. In some examples, the quantized samples are binarized into binary bins, and the coding algorithm further compresses the binary bins into bits. Examples of binarization methods include, but are not limited to, truncated Rice (TR) binarization and k-th order Ep-Golomb (EGk) binarization. In order to improve coding efficiency, a history-based Rice parameter derivation is used, in which the Rice parameters for a TU are derived based on variables obtained or updated from a previous transform unit (TU). Examples of entropy coding algorithms include, but are not limited to, variable length coding (VLC) schemes, context adaptive VLC schemes (CAVLC), arithmetic coding schemes, binarization, CABAC, syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques. The entropy coded data is added to the bitstream of the output coded video 132.

[0033] As described above, a reconstructed block 136 from a neighboring block is used in intra prediction of a block of an image. Generating a reconstructed block 136 of a block involves calculating a reconstructed residual of the block. The reconstructed residual can be determined by applying inverse quantization and inverse transform to the quantized residual of the block. The inverse quantization module 118 is used to apply inverse quantization to quantized samples to obtain dequantized coefficients. The inverse quantization module 118 applies the inverse of the quantization scheme applied by the quantization module 115 by using the same quantization step size as the quantization module 115. The inverse transform module 119 is used to apply the inverse transform of the transform applied by the transform module 114 to the dequantized samples, such as an inverse DCT or an inverse DST. The output of the inverse transform module 119 is the reconstructed residual of the block in the pixel domain. The reconstructed residual can be added to the prediction block 134 of the block to obtain the reconstructed block 136 in the pixel domain. For blocks that skip transform, the inverse transform module 119 is not applied to those blocks. The dequantized samples are the reconstructed residual of the block.

[0034] Blocks in subsequent images following a first intra-predicted image may be encoded using either inter-prediction or intra-prediction. In inter-prediction, a prediction of a block in an image is derived from one or more previously encoded video images. To perform inter-prediction, the video encoder 100 uses an inter-prediction module 124. The inter-prediction module 124 is used to perform motion compensation for a block based on the motion estimate provided by the motion estimation module 122.

[0035] The motion estimation module 122 compares the current block 104 of the current image with the decoded reference image 108 for motion estimation. The decoded reference image 108 is stored in the decoded image buffer 130. The motion estimation module 122 selects a reference block from the decoded reference image 108 that best matches the current block. The motion estimation module 122 further identifies the offset between the position (e.g., x, y coordinates) of the reference block and the position of the current block. The offset is called a motion vector (MV) and is provided to the inter-frame prediction module 124. In some cases, multiple reference blocks are identified for the block in multiple decoded reference images 108. Therefore, multiple motion vectors are generated and provided to the inter-frame prediction module 124.

[0036] The inter prediction module 124 uses the motion vector and other inter prediction parameters to perform motion compensation to generate a prediction of the current block (i.e., the inter prediction block 134). For example, based on the motion vector, the inter prediction module 124 can locate the prediction block pointed to by the motion vector in the corresponding reference image. If there is more than one prediction block, these prediction blocks are combined with some weights to generate the prediction block 134 of the current block.

[0037] For an inter-frame prediction block, the video encoder 100 can subtract the inter-frame prediction block 134 from the block 104 to generate a residual block 106. The residual block 106 can be transformed, quantized, and entropy encoded in the same manner as the residual of the intra-frame prediction block discussed above. Similarly, the reconstructed block 136 of the inter-frame prediction block can be obtained by inverse quantizing, inverse transforming, and then combining the residual with the corresponding prediction block 134.

[0038] In order to obtain the decoded image 108 for motion estimation, the loop filter module 120 processes the reconstructed block 136. The loop filter module 120 is used to smooth pixel transitions, thereby improving video quality. The loop filter module 120 can be used to implement one or more loop filters, such as a de-blocking filter, a sample-adaptive offset (SAO) filter, or an adaptive loop filter (ALF).

[0039] Figure 2 An example of a video decoder 200 for implementing the embodiments presented herein is depicted. The video decoder 200 processes the encoded video 202 in the bitstream and generates a decoded image 208. Figure 2 In the example shown, the video decoder 200 includes an entropy decoding module 216 , an inverse quantization module 218 , an inverse transform module 219 , a loop filter module 220 , an intra prediction module 226 , an inter prediction module 224 , and a decoded picture buffer 230 .

[0040] The entropy decoding module 216 is used to perform entropy decoding of the encoded video 202. The entropy decoding module 216 decodes quantized coefficients, encoding parameters including intra-frame prediction parameters and inter-frame prediction parameters, and other information. In some examples, the entropy decoding module 216 decodes the bitstream of the encoded video 202 into a binary representation, and then converts the binary representation into the quantization level of the coefficients. The entropy decoded coefficients are then dequantized by the dequantization module 218 and then inversely transformed to the pixel domain by the inverse transform module 219. The functions of the dequantization module 218 and the inverse transform module 219 are respectively the same as those described above with reference to FIG. Figure 1 The described inverse quantization module 118 and inverse transform module 119 are similar. The inverse transformed residual block may be added to the corresponding prediction block 234 to generate a reconstructed block 236. For blocks that skipped the transform, the inverse transform module 219 is not applied to those blocks. The dequantized samples generated by the inverse quantization module 118 are used to generate the reconstructed block 236.

[0041] A prediction block 234 of a particular block is generated based on the prediction mode of the block. If the encoding parameters of the block indicate that the block is intra-predicted, a reconstructed block 236 of a reference block in the same image may be fed back to the intra-prediction module 226 to generate the prediction block 234 of the block. If the encoding parameters of the block indicate that the block is inter-predicted, the inter-prediction module 224 generates the prediction block 234. The functions of the intra-prediction module 226 and the inter-prediction module 224 are respectively similar to Figure 1 The intra-frame prediction module 126 is similar to the inter-frame prediction module 124 .

[0042] As mentioned above Figure 1 As discussed, inter-frame prediction involves one or more reference pictures. The video decoder 200 generates a decoded picture 208 of the reference picture by applying the loop filter module 220 to the reconstructed block of the reference picture. The decoded picture 208 is stored in a decoded picture buffer 230 for use by the inter-frame prediction module 224 and also for output.

[0043] Reference now Figure 3 , Figure 3 Describes an example of coding tree unit partitioning of an image in a video according to some embodiments of the present disclosure. Figure 1 and Figure 2 As discussed, in order to encode an image of a video, the image is divided into blocks, e.g. Figure 3 302 in a VVC. For example, CTU 302 may be a block of 128×128 pixels. Figure 3 In some examples, such as Figure 4 As shown, each CTU 302 in the image can be divided into one or more coding units (CUs) 402, and the above CU can be further divided into prediction units for prediction or transform units for transformation. Depending on the coding scheme, the CTU 302 can be divided into CUs 402 differently. For example, in VVC, the CU 402 can be rectangular or square, and the above CU can be encoded without further division into prediction units or transform units. Each CU 402 can be as large as the root CTU 302 of the CU, or a subdivision of the root CTU 302 as small as 4×4 blocks. Figure 4 As shown, the partition from CTU 302 to CU 402 in the VVC may be a quadtree partition, a binary tree partition, or a ternary tree partition. Figure 4 In , the solid line represents quadtree partitioning, and the dashed line represents binary tree or ternary tree partitioning.

[0044] As mentioned above Figure 1 and Figure 2 As discussed, quantization is used to reduce the dynamic range of elements of a block in a video signal so that fewer bits are used to represent the video signal. In some examples, before quantization, the elements at a specific position of a block are called coefficients. After quantization, the quantization value of the coefficient is called a quantization level or level. Quantization typically involves dividing by a quantization step size and then rounding, while inverse quantization involves multiplying by a quantization step size. This quantization process is also known as scalar quantization. The quantization of coefficients within a block can be performed independently, and this independent quantization method is used in some existing video compression standards such as H.264, HEVC, etc. In other examples, such as in VVC, dependent quantization is used.

[0045] For an N×M block, the 2-D coefficients of the block can be converted into a 1-D array using a specific scanning order for coefficient quantization and encoding, and the same scanning order is used for encoding and decoding. Figure 5 An example of a coding block (such as a TU) with a predetermined scanning order for processing coefficients of the coding block is shown. In this example, the coding block 500 is 8×8 in size, and the processing starts from the position L0 in the lower right corner to the upper left corner L 63End. If block 500 is a transformed block, then Figure 5 The predetermined order shown starts from the highest frequency to the lowest frequency. In some examples, processing (e.g., quantization and binarization) of a block starts from the first non-zero element of the block according to a predetermined scanning order. For example, if positions L0 to L 17 The coefficients of L are all zero and 18 The coefficient of is non-zero, then the process from L 18 The coefficients of L are scanned in order. 18 Each coefficient thereafter is executed.

[0046] Residual Coding

[0047] In video coding, residual coding is used to convert quantization levels into code streams. After quantization, the N×MTU coding block has N×M quantization levels. These N×M levels can be zero values ​​or non-zero values. If the non-zero level is not binary, the non-zero level is further binarized into a binary bin. CABAC can further compress the bin into bits. In addition, there are two coding methods based on context modeling. Specifically, one of the above methods is to adaptively update the context model based on adjacent coding information. This method is called a context coding method, and the bin encoded in this way is called a context coding bin. In contrast, another method assumes that the probability of 1 or 0 is always 50%, so a fixed context modeling is always used without adjustment. This method is called a bypass method, and the bin encoded in this way is called a bypass bin.

[0048] For the regular residual coding (RRC) block in VVC, the position of the last non-zero level is defined as the position of the last non-zero level along the coding scan order. The representation of the 2D coordinates of the last non-zero level (last_sig_coeff_x and last_sig_coeff_y) includes a total of 4 prefix and suffix syntax elements, which are last_sig_coeff_x_prefix, last_sig_coeff_y_prefix, last_sig_coeff_x_suffix, and last_sig_coeff_y_suffix. The syntax elements last_sig_coeff_x_prefix and last_sig_coeff_y_prefix are first encoded using the context coding method. If last_sig_coeff_x_suffix and last_sig_coeff_y_suffix exist, last_sig_coeff_x_suffix and last_sig_coeff_y_suffix are encoded using a bypass method. The RRC block can consist of multiple predefined sub-blocks. The syntax element sb_coded_flag is used to indicate whether all levels of the current sub-block are equal to zero. If sb_coded_flag is equal to 1, there is at least one non-zero coefficient in the current sub-block. If sb_coded_flag is equal to 0, all coefficients in the current sub-block will be zero. However, the sb_coded_flag of the last non-zero sub-block with the last non-zero level is derived from last_sig_coeff_x and last_sig_coeff_y as 1 according to the coding scan order, and is not encoded into the code stream. In addition, the sb_coded_flag of the upper left sub-block containing the DC position is also derived as 1 and is not encoded into the code stream. The context coding method is used to encode the syntax element of sb_coded_flag in the code stream. Figure 5 As discussed, RRC will start from the last non-zero sub-block and encode sub-block by sub-block in reverse coding scanning order.

[0049] To ensure the worst-case throughput, the maximum number of context coding bins is limited using a predefined value remBinsPass1. Within a subblock, RRC will encode the level of each position in a reverse coding scan order. If remBinsPass1 is greater than 4, when encoding the current level, a flag called sig_coeff_flag is first encoded into the bitstream to indicate whether the level is zero or non-zero. If the level is non-zero, abs_level_gtx_flag[n][0] is used to indicate that the absolute level is 1 or greater than 1, where n is the index of the current position within the subblock along the scan order. If the absolute level is greater than 1, par_level_flag will be encoded to indicate whether the level is odd or even in VVC, and then abs_level_gtx_flag[n][1] will exist. The flags par_level_flag and abs_level_gtx_flag[n][1] are also used together to indicate that the level is 2, 3, or greater than 3. After encoding each of the above syntax elements into a context-encoded bin, the value of remBinsPass1 will be reduced by 1.

[0050] If the absolute level is greater than 3 or the value of remBinsPass1 is not greater than 4, then after encoding the above bins using the context coding method, for the remaining level, two additional syntax elements abs_remainder and dec_abs_level can be encoded as bypass coded bins. In addition, the sign of each level in the block will also be encoded to indicate the quantization level, and the above signs are encoded as bypass coded bins.

[0051] Another residual coding method uses abs_level_gtxX_flag and the remaining level to allow conditional parsing of the syntax elements for level coding of the residual block, and the corresponding binary of the absolute value of the level is shown in Table 1. Here, abs_level_gtxX_flag describes whether the absolute value of the level is greater than X, where X is an integer, for example, 0, 1, 2, or N. If abs_level_gtxY_flag is 0, where Y is an integer between 0 and N-1, the abs_level_gtx(Y+1) flag will not exist. If abs_level_gtxY_flag is 1, the abs_level_gtx(Y+1) flag will exist. In addition, if abs_level_gtxN_flag is 0, the remaining level will not exist. When abs_level_gtxN_flag is 1, the remaining level will exist, and the remaining level represents the value after removing (N+1) from the level. Typically, abs_level_gtxX_flag is encoded using a context coding method, and the remaining levels are encoded using a bypass method. Table 1 Residual coding based on abs_level_gtxX_flag and remainder abs(level) 0 1 2 3 4 5 6 7 8 9 10 11 12 … abs_level_gtx0_flag 0 1 1 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx1_flag 0 1 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx2_flag 0 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx3_flag 0 1 1 1 1 1 1 1 1 1 … Remainder 0 1 2 3 4 5 6 7 8 …

[0052] For blocks coded in transform skip residual coding (TSRC) mode, TSRC will be coded sub-block by sub-block along the coding scan order starting from the top left sub-block. Similarly, the syntax element sb_coded_flag is used to indicate whether all residuals of the current sub-block are equal to zero. When a specific condition occurs, all syntax elements sb_coded_flag of all sub-blocks except the last sub-block are encoded into the bitstream. If all sb_coded_flags of all sub-blocks before the last sub-block are not equal to 1, the sb_coded_flag of the last sub-block will be derived as 1 and the flag will not be encoded into the bitstream. In order to ensure the worst-case throughput, the maximum context coding bin is limited by a predefined value RemCcbs. If the current sub-block has a non-zero level, TSRC will encode the level of each position in the coding scan order. If RemCcbs is greater than 4, the following syntax elements will be encoded using the context coding method. For each level, sig_coeff_flag is first encoded into the bitstream to indicate whether the level is zero or non-zero. If the level is non-zero, coeff_sign_flag will be encoded to indicate whether the level is positive or negative. Then abs_level_gtx_flag[n][0] will be encoded to indicate whether the current absolute level of the current position is greater than 1, where n is the index of the current position within the sub-block along the scan order. If abs_level_gtx_flag[n][0] is not zero, par_level_flag will be encoded. After encoding each of the above syntax elements using the context coding method, the value of RemCcbs will be reduced by 1.

[0053] After encoding the above syntax elements for all positions within the current sub-block, if RemCcbs is still greater than 4, up to four more abs_level_gtx_flag[n][j] will be encoded using the context coding method, where n is the index of the current position within the sub-block along the scan order; j is 1 to 4. After encoding each abs_level_gtx_flag[n][j], the value of RemCcbs will be reduced by 1. If RemCcbs is not greater than 4, the syntax element abs_remainder of the current position within the sub-block will be encoded using the bypass method if necessary. For positions where the absolute level is fully encoded using the abs_remainder syntax element using the bypass method, coeff_sign_flags is also encoded using the bypass method. In summary, there is a predefined counter remBinsPass1 in RRC or a predefined counter RemCcbs in TSRC to limit the total number of context coding bins and ensure the worst-case throughput.

[0054] Rice parameter derivation

[0055] In the current RRC design in VVC, for the remaining level, there can be two syntax elements abs_remainder and dec_abs_level in the bitstream that are coded as bypass bins. Both abs_remainder and dec_abs_level are binarized by a combination of TR binarization and limited EGk binarization processes specified in the VVC specification, which requires Rice parameters to be binarized for a given level. In order to obtain the optimal Rice parameters, a local summation method as described below is used.

[0056] The array AbsLevel[xC][yC] represents the array of absolute values ​​of the transform coefficient levels of the current transform block for color component index cIdx. Given the array AbsLevel[x][y] of a transform block with color component index cIdx and top left luma position (x0, y0), derive the local sum variable locSumAbs as specified by the following pseudo-code procedure: where log2TbWidth is the base 2 logarithm of the width of the transform block, and log2TbHeight is the base 2 logarithm of the height of the transform block. For abs_remainder and dec_abs_level, the variable baseLevel is 4 and 0, respectively. Given the local and variable locSumAbs, derive the Rice parameter cRiceParam as specified in Table 2. Table 2 - cRiceParam specifications based on locSumAbs locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0057] Derivation of Rice parameters based on history

[0058] The template calculation used for Rice parameter derivation may produce inaccurate coefficient estimates if the coefficients are located at TU boundaries or decoded for the first time using the Rice method. Because some template positions may be located outside the TU and are interpreted or initialized to the value 0, the template calculation is biased towards 0 for these coefficients. Figure 6 An example of a template mode for calculating locSumAbs for coefficients located near TU boundaries is shown. Figure 6 A CTU 602 is shown divided into multiple CUs, and each CU includes multiple TUs. For TU 604, the position of the current coefficient is shown as a solid block, and the position of the neighboring samples of the current coefficient in the template mode is shown as a patterned block. The pattern block indicates a predetermined neighborhood of the current coefficient used to calculate the local sum variable locSumAbs.

[0059] exist Figure 6 In the example, because the current coefficient 606 is close to the boundary of TU 604, some neighboring samples of the current coefficient in the template mode, for example, neighboring samples 608B and 608E, are outside the TU boundary. In the above-mentioned Rice parameter derivation, when calculating the local sum variable locSumAbs, these neighboring samples outside the boundary are set to 0, resulting in inaccurate Rice parameter derivation. For high bit depth samples (e.g., more than 10 bits), the number of neighboring samples outside the TU boundary may be large. Setting these large number of neighboring samples to 0 will introduce more errors in the Rice parameter derivation.

[0060] To improve the accuracy of estimating Rice parameters from the computed template, it is recommended that for template positions outside the current TU, the local sum variable locSumAbs be updated with historically derived values ​​instead of being initialized to 0. This method is implemented as shown in the following excerpt from the VVC specification text in clause 9.3.3.2, with the recommended text underlined.

[0061] In order to maintain the history of neighboring coefficient / sample values, a history counter StatCoeff[cIdx] for each color component is used, where cIdx=0, 1, and 2 represent the three color components Y, U, and V, respectively. If the CTU is the first CTU in a partition (e.g., a picture, a slice, or a tile), StatCoeff[cIdx] is initialized as follows: StatCoeff[ idx ] = 2 * Floor( Log2( BitDepth - 10 ) (1) Here, BitDepth specifies the bit depth of samples of the luma and chroma arrays of the video; Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x. Before decoding a TU and updating the history counter, the replacement variable HistValue is initialized to: HistValue[cIdx] = 1 << StatCoeff[cIdx] (2) The replacement variable HistValue is used as an estimate of neighboring samples outside the TU boundary (e.g., neighboring samples have horizontal or vertical coordinates outside the TU). The local sum variable locSumAbs is re-derived as specified in the following pseudo-code procedure, with changes underlined:

[0062] Before encoding each TU, the Rice parameters used to encode the first abs_remainder or dec_abs_level syntax element of each TU are derived using the history value HistValue calculated according to equation (2), if possible.

[0063] The history counter StatCoeff is updated once per TU from the first non-zero Golomb-Rice coded transform coefficient (abs_remaintment[cIdx] or dec_abs_level[cIdx]) by an exponential moving average process. When the first non-zero Golomb-Rice coded transform coefficient in a TU is encoded as abs_remainder, the history counter StatCoeff of the color component cIdx is updated as follows: StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor(Log2(abs_remainder[cIdx])) + 2 ) >> 1 (3) When the first non-zero Golomb-Rice coded transform coefficient in a TU is encoded as dec_abs_level, the history counter StatCoeff of the color component cIdx is updated as follows: StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor(Log2(dec_abs_level[cIdx])) ) >> 1 (4) Before decoding the next TU, the replacement variable HistValue of the next TU can be calculated using the updated StatCoeff according to equation (2).

[0064] According to the above, when the first non-zero Golomb-Rice coded transform coefficient in the current TU is encoded as abs_remainder or dec_abs_level, the history counter StatCoeff is updated, and the replacement variable HistValue is updated only according to the updated history counter StatCoeff until the next TU. Therefore, the HistValue used to calculate the Rice parameter may not be a suitable value for finding the optimal Rice parameter for the remaining position within the current TU. In the present disclosure, an improved history-based Rice parameter derivation is described to improve coding efficiency.

[0065] If the CTU is the first CTU in a slice or tile, the history counter of the color component cIdx denoted as StatCoeff[cIdx] has a predefined initial value. Before encoding the first TU of the first CTU in a slice or tile, the replacement variable HistValue is initialized with the initial value of StatCoeff[cIdx] as follows. HistValue=sps_persistent_rice_adaptation_enabled_flag? 1< <StatCoeff[cIdx]:0 (5) The coefficients in the TU are encoded using this initial substitution variable HistValue until the substitution variable HistValue is updated according to the following rules. For each TU in a slice or tile, the last significant coefficient in the TU (i.e., according to Figure 5 After encoding the first non-zero quantization level in the reverse scanning order shown, the history counter StatCoeff[cIdx] of the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs(level)))+2)>>1 (6) Alternatively, or additionally, the history counter StatCoeff[cIdx] may also be updated as: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs(level))))>>1 (7) Here, Floor(x) represents the largest integer less than or equal to x, Log2(x) is the base-2 logarithm of x, abs(x) represents the absolute value of x, and level represents the first non-zero quantization level in the TU.

[0066] Once the history counter StatCoeff[cIdx] is updated with the absolute value of the first non-zero quantization level in the TU, the substitution variable HistValue is immediately updated according to equation (8). The updated substitution variable HistValue will be used to derive Rice parameters for the remaining abs_remainder and dec_abs_level syntax elements in the TU until the history counter StatCoeff[cIdx] and the substitution variable HistValue are updated again. HistValue=1< <StatCoeff[cIdx](8)

[0067] In one example, a specification change based on the current VVC specification may be specified as follows: Added content is underlined, and deleted content is marked with a strikethrough. Clause 7.3.11.11 (Residual Coding Syntax) is changed as follows (additions are underlined):

[0068] In the example above, the history counter StatCoeff is updated using the first non-zero quantization level AbsLevel[xC][yC] of each TU. The replacement variable HistValue is immediately updated using the updated history counter StatCoeff. By updating the history counter StatCoeff and the replacement variable HistValue in this way, the update operations associated with abs_remainer and dec_abs_level can be omitted. Therefore, the computational complexity of Rice parameter derivation can be reduced. The values ​​of the replacement variable HistValue and the history counter StatCoeff are synchronized, and a more accurate Rice parameter derivation can be provided for the TU.

[0069] In the above example, the history counter StatCoeff is updated according to equation (6). Optionally, the history counter StatCoeff can be updated according to equation (7). The specification changes based on the current VVC specification and the update scheme in equation (7) are specified as follows. Additions are underlined and deletions are marked with strikethrough. Clause 7.3.11.11 (Residual Coding Syntax) is changed as follows (additions are underlined):

[0070] Based on the current VVC specification, other possible specification changes are specified as follows. Additions are underlined and deletions are marked with strikethrough. Clause 7.3.11.11 (Residual Coding Syntax) is changed as follows (additions are underlined):

[0071] For the first TU in the CTU, the initial value of the replacement variable HistValue obtained at the slice level as shown in equation (5) above can be used. For subsequent TUs, the replacement variable HistValue is updated each time the history counter StatCoeff is updated, and the value of the replacement variable HistValue from the previous TU is stored in the replacement variable HistValue. Therefore, there is no need to initialize the replacement variable HistValue at the beginning of processing each TU. Therefore, as shown above, the initialization step can be omitted to save additional computing power of the video encoder and decoder.

[0072] In the above example, the history counter StatCoeff is updated according to equation (6). Optionally, the history counter StatCoeff can be updated according to equation (7). The specification changes based on the current VVC specification based on the update scheme in equation (7) are specified as follows. Added content is underlined and deleted content is marked with a strikethrough. Clause 7.3.11.11 (Residual Coding Syntax) is changed as follows (additions are underlined):

[0073] Figure 7 An example of a process 700 for encoding a partition of a video according to some embodiments of the present disclosure is depicted. One or more computing devices (e.g., computing devices implementing the video encoder 100) implement the process 700 by executing appropriate program code (e.g., program code implementing the entropy coding module 116). Figure 7 For illustration, process 700 is described with reference to some examples depicted in the accompanying drawings. However, other implementations are possible.

[0074] At block 702, process 700 includes accessing a partition of a video signal. A partition may be a video frame, a slice, a tile, or any type of partition that is processed as a unit by a video encoder when performing encoding. A partition includes a group of CTUs. Figure 6As shown in the example of , each CTU includes one or more CUs, and each CU includes multiple TUs for encoding.

[0075] At block 704, including blocks 706 to 712, process 700 includes processing each CTU in the group of CTUs in the partition to encode the partition into bits. At block 706, process 700 includes updating a history counter StatCoeff based on a first non-zero quantization level of the TU and updating a replacement variable HistValue in conjunction with the update of StatCoeff. As described above, in some embodiments, the history counter StatCoeff may be updated according to equation (6) or equation (7) based on a first non-zero quantization level of the TU. In either case, whenever the history counter StatCoeff is updated, the replacement variable HistValue is updated according to equation (8). In this way, both the history counter StatCoeff and the replacement variable HistValue are updated before calculating the next Rice parameter.

[0076] At block 708, the Rice parameters of the TUs in the CTU are calculated as described above based on the updated replacement variable HistValue. At block 710, process 700 includes encoding the TUs in the CTU into binary representations based on the calculated Rice parameters, for example, by a combination of TR and finite k-order EGK as specified in the VVC specification. At block 712, process 700 includes encoding the binary representation of the TU into bits included in a video bitstream. The encoding may be performed, for example, using CABAC as discussed above. Blocks 706 to 712 may be repeated for each TU in the CTU. At block 714, process 700 includes outputting the encoded video bitstream.

[0077] Figure 8 An example of a process 800 for decoding a partition of a video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the process 800 by executing appropriate program code. Figure 8 For example, a computing device implementing the video decoder 200 may implement the operations described in the embodiment of the present invention by executing the program code of the entropy decoding module 216, the inverse quantization module 218, and the inverse transformation module 219. Figure 8 For illustration, process 800 is described with reference to some examples depicted in the accompanying drawings. However, other implementations are possible.

[0078] At block 802, process 800 includes accessing a binary string or binary representation representing a partition of a video signal. A partition may be a video frame, a slice, or a tile, or any type of partition that is processed as a unit by a video encoder when performing encoding. A partition includes a group of CTUs. Figure 6As shown in the example of , each CTU includes one or more CUs, and each CU includes multiple TUs for encoding.

[0079] In box 804, including boxes 806 to 812, process 800 includes processing the binary string of each CTU in the group of CTUs in the partition to generate decoded samples of the partition. In box 806, process 800 includes updating the history counter StatCoeff based on the first non-zero quantization level of the TU in the CTU, and updating the replacement variable HistValue in conjunction with the update of StatCoeff. As described above, in some embodiments, the history counter StatCoeff can be updated according to equation (6) or equation (7) based on the first non-zero quantization level in the TU. In either case, the replacement variable HistValue is updated whenever the history counter StatCoeff is updated. For example, after updating the history counter StatCoeff according to equation (6) or equation (7), the replacement variable HistValue is updated according to equation (8) based on the updated value of the history counter StatCoeff. In this way, both the history counter StatCoeff and the replacement variable HistValue are updated before calculating the next Rice parameter.

[0080] At block 808, process 800 includes calculating Rice parameters for TUs in the CTU as described above based on the updated replacement variable HistValue. At block 810, process 800 includes decoding a binary string or binary representation of a TU in the CTU into coefficient values ​​based on the calculated Rice parameters, for example, by a combination of TR and finite k-order EGK as specified in the VVC specification. At block 812, process 800 includes decoding a binary string or binary representation of a TU in the CTU into coefficient values ​​as described above with reference to Figure 2 As discussed, pixel values ​​of the TUs in the CTU are reconstructed by, for example, inverse quantization and inverse transformation. Blocks 806 to 812 may be repeated for each TU in the CTU. At block 814, process 800 includes decoding partitions of the output video.

[0081] Although in the above description, in the figure (for example, Figure 6 ) is described and illustrated in the TU, but the same technology can be applied to the transform block (TB). In other words, in the embodiments (including the figures) presented above, TU can also represent TB.

[0082] Example of a computing system implementing quantization for video coding

[0083] Any suitable computing system may be used to perform the operations described herein. For example, Fig. 9 Describing can be achieved Figure 1 The video encoder 100 or Figure 2An example of a computing device 900 of a video decoder 200 is provided. In some embodiments, the computing device 900 may include a processor 912 that is communicatively coupled to a memory 914 and that executes computer executable program code and / or accesses information stored in the memory 914. The processor 912 may include a microprocessor, an application specific integrated circuit (“ASIC”), a state machine, or other processing device. The processor 912 may include any of a plurality of processing devices (including one). Such a processor may include or may communicate with a computer readable medium storing instructions that, when executed by the processor 912, cause the processor to perform the operations described herein.

[0084] Memory 914 may include any suitable non-transitory computer-readable medium. Computer-readable media may include any electronic, optical, magnetic, or other storage device capable of providing computer-readable instructions or other program codes to the processor. Non-limiting examples of computer-readable media include disks, memory chips, ROM, RAM, ASICs, configured processors, optical storage, tapes or other magnetic storage, or any other medium from which a computer processor can read instructions. Instructions may include processor-specific instructions generated by a compiler and / or interpreter from code written in any suitable computer programming language, including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

[0085] The computing device 900 may also include a bus 916. The bus 916 may communicatively couple one or more components of the computing device 900. The computing device 900 may also include a plurality of external or internal devices, such as input or output devices. For example, the computing device 900 shows an input / output ("I / O") interface 918, which may receive input from one or more input devices 920 or provide output to one or more output devices 922. One or more input devices 920 and one or more output devices 922 may be communicatively coupled to the I / O interface 918. The communicatively coupling may be achieved in any suitable manner (e.g., by connection of a printed circuit board, by connection of a cable, by communication of wireless transmission, etc.). Non-limiting examples of input devices 920 include a touch screen (e.g., one or more cameras for imaging a touch area or a pressure sensor for detecting pressure changes caused by a touch), a mouse, a keyboard, or any other device that may be used to generate input events in response to physical actions of a computing device user. Non-limiting examples of output device 922 include an LCD screen, an external monitor, speakers, or any other device that can be used to display or otherwise present output generated by the computing device.

[0086] The computing device 900 may execute the processor 912 to perform the above Figures 1 to 8 The program code may include one or more of the described operations. The program code may include the video encoder 100 or the video decoder 200. The program code may reside in the memory 914 or any suitable computer-readable medium and may be executed by the processor 912 or any other suitable processor.

[0087] The computing device 900 may also include at least one network interface device 924. The network interface device 924 may include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 928. Non-limiting examples of the network interface device 924 include an Ethernet network adapter, a modem, etc. The computing device 900 may send messages as electrical or optical signals via the network interface device 924.

[0088] General Notes

[0089] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will appreciate that the claimed subject matter may be practiced without these specific details. In other cases, methods, devices, or systems known to those of ordinary skill in the art are not described in detail in order to avoid obscuring the claimed subject matter.

[0090] Unless otherwise specifically noted, it should be understood that terms such as "process," "compute," "calculate," "determine," and "identify" are used throughout the discussion of this specification to refer to the actions or processes of a computing device (e.g., one or more computers or similar electronic computing devices or devices) that manipulates or transforms data represented as physical electronic or magnetic quantities within a memory, register, or other information storage device, transmission device, or display device of a computing platform.

[0091] The one or more systems discussed herein are not limited to any specific hardware architecture or configuration. Computing devices may include any suitable component arrangement that provides results based on one or more inputs. Suitable computing devices include a computer system based on a multi-purpose microprocessor that accesses stored software, which accesses the storage software of a computing system from a general-purpose computing device that implements one or more embodiments of the present theme to a special-purpose computing device programming or configuration computing system. Any suitable programming, scripting, or other types of languages ​​or language combinations may be used to implement the teachings contained herein in the software used when programming or configuring computing devices.

[0092] Embodiments of the methods disclosed herein may be performed in the operation of such a computing device. The order of the boxes presented in the above examples may be changed—for example, the boxes may be reordered, combined, and / or divided into sub-boxes. Some boxes or processes may be performed in parallel.

[0093] As used herein, "suitable for" or "for" is intended to be open and inclusive language and does not exclude devices suitable for or used to perform additional tasks or steps. In addition, the use of "based on" is intended to be open and inclusive, because a process, step, calculation, or other action "based on" one or more of the listed conditions or values ​​may actually be based on additional conditions or values ​​other than those listed above. The headings, lists, and numbers included herein are for ease of explanation only and are not intended to be limiting.

[0094] Although the subject matter has been described in detail with respect to the specific embodiments herein, it should be understood that those skilled in the art can easily make changes, variations and equivalents to these embodiments after understanding the foregoing. Therefore, it should be understood that the present disclosure is provided for the purpose of illustration rather than limitation, and does not exclude changes, variations and / or additions to the subject matter that are obvious to those of ordinary skill in the art.

Claims

1. A method for decoding a video, the method comprising: accessing a binary string representing a partition of the video, the partition comprising a plurality of coding tree units (CTUs); and decoding a CTU among the plurality of CTUs in the partition, the decoding the CTU comprising decoding a transform unit (TU) of the CTU by: Update a history counter StatCoeff of a color component used to calculate Rice parameters based on a first non-zero quantization level in the TU; Before calculating the next Rice parameter, updating the replacement variable HistValue based on the updated history counter StatCoeff; Calculate the Rice parameter of the TU based on the updated replacement variable HistValue; decoding the binary string corresponding to the TU into coefficient values ​​of the TU based on the calculated Rice parameters; as well as determining a pixel value of the TU in the CTU from the coefficient value; as well as A decoded partition of the video is output, the decoded partition comprising the decoded plurality of CTUs in the partition.

2. The method according to claim 1, wherein: Update the history counter StatCoeff of the color component cIdx to: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs(level)))+2)>>1, Wherein, Floor(x) represents the largest integer less than or equal to x, log2(x) is the logarithm of x with base 2, abs(x) represents the absolute value of x, and level represents the first non-zero quantization level in the TU.

3. The method according to claim 1, wherein: Update the history counter StatCoeff of the color component cIdx to: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs(level))))>>1, Wherein, Floor(x) represents the largest integer less than or equal to x, Log2(x) is the logarithm of x with base 2, abs(x) represents the absolute value of x, and level represents the first non-zero quantization level in the TU.

4. The method according to claim 1, wherein: The partitions are frames, slices, or tiles.

5. The method according to claim 1 further comprises, for the first CTU in the partition, setting the replacement variable HistValue to an initial value as follows based on the initial value of the history counter StatCoeff HistValue=sps_persistent_rice_adaptation_enabled_flag? 1< <StatCoeff[cIdx]:0 in, sps_persistent_rice_adaptation_enabled_flag indicates whether history-based Rice parameter derivation is enabled.

6. The method according to claim 1, wherein: Updating the substitution variable HistValue based on the history counter StatCoeff includes updating the substitution variable HistValue of the color component cIdx by the following calculation: HistValue[cIdx]=1< <StatCoeff[cIdx]。 7. The method according to claim 1, wherein: Calculating the Rice parameter of the TU in the CTU based on the replacement variable HistValue includes: Calculating a local sum variable locSumAbs of the coefficient using values ​​of neighboring coefficients in a predetermined neighborhood of the coefficient in the TU of the CTU and the replacement variable HistValue; and The Rice parameters of the TU are derived based on the local sum variable locSumAbs.

8. The method according to claim 1, wherein: If the CTU is the first CTU in the partition, the history counter StatCoeff[cIdx] of the color component cIdx is initialized to: StatCoeff[idx]=2*Floor(Log2(BitDepth-10) Wherein, BitDepth specifies the bit depth of samples of the luma and chroma arrays of the video; Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

9. A method for encoding a video, the method comprising: Accessing a partition of the video, the partition comprising a plurality of coding tree units (CTUs); processing the partitions of the video to generate binary representations of the partitions, the processing comprising: and encoding a CTU among the plurality of CTUs in the partition, the encoding the CTU comprising encoding a transform unit (TU) of the CTU by: Update a history counter StatCoeff of a color component used to calculate a Rice parameter of the TU based on a first non-zero quantization level in the TU; Before calculating the next Rice parameter, updating the replacement variable HistValue based on the updated history counter StatCoeff; Calculating the Rice parameter of the TU based on the updated replacement variable HistValue; and encoding the coefficient values ​​of the TU into a binary representation corresponding to the TU in the CTU based on the calculated Rice parameters; and The binary representation of the partitions is encoded into a code stream of the video.

10. A non-transitory computer readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations comprising: Accessing a partition of a video, the partition comprising a plurality of coding tree units (CTUs); processing the partitions of the video to generate binary representations of the partitions, the processing comprising: and encoding a CTU among the plurality of CTUs in the partition, the encoding the CTU comprising encoding a transform unit (TU) of the CTU by: Update a history counter StatCoeff of a color component used to calculate a Rice parameter of the TU based on a first non-zero quantization level in the TU; Before calculating the next Rice parameter, updating the replacement variable HistValue based on the updated history counter StatCoeff; Calculating the Rice parameter of the TU based on the updated replacement variable HistValue; and encoding the coefficient values ​​of the TU into a binary representation corresponding to the TU in the CTU based on the calculated Rice parameters; and The binary representation of the partitions is encoded into a code stream of the video.

Images