History-based rice coding parameter derivation for video coding

Abstract

In some embodiments, a video decoder decodes a video from a bitstream of the video using a history-based Rice coding parameter derivation. The video decoder accesses a bin string representing a partition of the video and processes each coding tree unit (CTU) in the partition to generate decoded coefficient values in the CTU. The processing includes updating a history counter for color components used to calculate a Rice coding parameter and updating a substitution variable based on the updated history counter before calculating a next Rice coding parameter. The processing also includes calculating a Rice coding parameter for a transform unit (TU) in the CTU based on a value of the substitution variable and decoding a bin string corresponding to the TU in the CTU into coefficient values of the TU based on the calculated Rice coding parameter.

Description

[0001] This application is a divisional application of Chinese patent application No. 202280056225.1, entitled "History-based Derivation of Rice Encoding Parameters for Video Encoding and Decoding", which entered the Chinese national phase of PCT international patent application PCT / US2022 / 075157 filed on August 18, 2022.

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Provisional Application No. 63 / 234,634, filed August 18, 2021, entitled “History-based Derivation of Rice Coding Parameters for Video Coding and Decoding”, and U.S. Provisional Application No. 63 / 250,969, filed September 30, 2021, entitled “History-based Derivation of Rice Coding Parameters for Video Coding and Decoding”, which are incorporated herein by reference in their entirety. Technical Field

[0004] This disclosure generally relates to computer-implemented methods and systems for video processing. Specifically, this disclosure relates to history-based Rice parameter derivation for video encoding and decoding. Background Technology

[0005] The ubiquitous presence of camera-equipped devices, such as smartphones, tablets, and computers, makes capturing video or images easier than ever before. However, even short videos can generate a significant amount of data. Video codec technologies (including video encoding and decoding) allow video data to be compressed into smaller sizes, enabling the storage and transmission of a wide variety of videos. Video codecs are already 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, and more. To reduce the storage space used to store video and / or the network bandwidth consumed for transmitting video, it is desirable to improve the efficiency of video codec solutions. Summary of the Invention

[0006] Some embodiments relate to history-based derivation of Rice coding parameters for video encoding and decoding. In one example, a method for decoding video includes: accessing a binary string representing a partition of the video, the partition comprising a plurality of coding tree units (CTUs); decoding each of the plurality of CTUs in the partition, the decoding of a CTU comprising: updating a history counter StatCoeff used to compute color components of the Rice coding parameters; updating a substitution variable HistValue based on the updated history counter before computed the next Rice coding parameter; computed Rice coding parameters for transform units (TUs) in the CTU based on the updated substitution variable HistValue; decoding the binary string corresponding to the TU in the CTU into coefficient values ​​of the TU based on the computed Rice coding parameters; determining the pixel values ​​of the TUs in the CTU based on the coefficient values; and outputting a decoded partition of the video, the decoded partition of the video comprising a plurality of decoded CTUs in the partition.

[0007] In another example, a non-transitory computer-readable medium is provided on which program code is stored, which is executed by one or more processing devices to perform the following operations: accessing binary strings representing partitions of a video, the partition including a plurality of CTUs; decoding each of the plurality of CTUs in the partition, the decoding of a CTU including: updating a history counter StatCoeff used to calculate color components of Rice encoding parameters; updating a replacement variable HistValue based on the updated history counter before calculating the next Rice encoding parameter; calculating the Rice encoding parameters of the TUs in the CTU based on the updated replacement variable HistValue; decoding the binary strings corresponding to the TUs in the CTU to coefficient values ​​of the TUs based on the calculated Rice encoding parameters; determining the pixel values ​​of the TUs in the CTU based on the coefficient values; and outputting a decoded partition of the video, the decoded partition of the video including a plurality of decoded CTUs in the partition.

[0008] In another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium and thereby perform the following operations: accessing binary strings representing partitions of a video, each partition comprising a plurality of CTUs; decoding each of the plurality of CTUs in the partition, the decoding of a CTU comprising: updating a history counter StatCoeff used to calculate color components of Rice encoding parameters; updating a replacement variable HistValue based on the updated history counter before calculating the next Rice encoding parameter; calculating Rice encoding parameters for the TUs in the CTU based on the updated replacement variable HistValue; decoding the binary strings corresponding to the TUs in the CTU to coefficient values ​​of the TUs based on the calculated Rice encoding parameters; determining pixel values ​​of the TUs in the CTU based on the coefficient values; and outputting a decoded partition of the video comprising a plurality of decoded CTUs in the partition.

[0009] In another example, a method for encoding video includes accessing a partition of the video, which comprises multiple color units (CTUs); processing the partition of the video to generate a binary representation of the partition, the processing including: encoding each of the multiple CTUs in the partition, the encoding of the CTU including: updating the history counter StatCoeff used to calculate the color components of the Rice encoding parameters; updating the replacement variable HistValue based on the updated history counter before calculating the next Rice encoding parameter; calculating the Rice encoding parameters of the TUs in the CTUs based on the updated replacement variable HistValue; and encoding the coefficient values ​​of the TUs into the binary representation of the TUs in the CTUs based on the calculated Rice encoding parameters; and encoding the binary representation of the partition into a bitstream of the video.

[0010] In another example, a non-transitory computer-readable medium is provided on which program code is stored, which is executed by one or more processing devices for performing the following operations: accessing a partition of video, the partition comprising a plurality of CTUs; processing the partition of video to generate a binary representation of the partition, the processing comprising: encoding each of the plurality of CTUs in the partition, the encoding of the CTU comprising: updating the history counter StatCoeff used to calculate the color components of the Rice encoding parameters; updating the replacement variable HistValue based on the updated history counter before calculating the next Rice encoding parameter; calculating the Rice encoding parameters of the TUs in the CTUs based on the updated replacement variable HistValue; encoding the coefficient values ​​of the TUs into the binary representations of the TUs in the CTUs based on the calculated Rice encoding parameters; and encoding the binary representations of the partitions into a video bitstream.

[0011] In yet another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium and thereby perform the following operations: accessing a partition of video, the partition comprising a plurality of CTUs; processing the partition of video to generate a binary representation of the partition, the processing comprising: encoding each of the plurality of CTUs in the partition, the encoding of the CTU comprising: updating a history counter StatCoeff used to calculate color components of Rice encoding parameters; updating a replacement variable HistValue based on the updated history counter before calculating the next Rice encoding parameter; calculating the Rice encoding parameters of the TUs in the CTUs based on the updated replacement variable HistValue; and encoding the coefficient values ​​of the TUs into a binary representation of the TUs in the CTUs based on the calculated Rice encoding parameters; and encoding the binary representation of the partition into a bitstream of video.

[0012] The illustrative embodiments mentioned are not intended to limit or define this disclosure, but rather to provide examples that aid in understanding it. Additional embodiments are discussed in the detailed description, and further description is provided. Attached Figure Description

[0013] The features, implementation methods and advantages of this disclosure can be better understood by referring to the following detailed description with reference to the accompanying drawings.

[0014] Figure 1 This is a block diagram illustrating an example of a video encoder used to implement the embodiments presented herein.

[0015] Figure 2This is a block diagram illustrating an example of a video decoder used to implement the embodiments presented herein.

[0016] Figure 3 Examples of CTU partitioning of images in a video according to some embodiments of the present disclosure are depicted.

[0017] Figure 4 Examples of CTU coding unit partitioning according to some embodiments of the present disclosure are depicted.

[0018] Figure 5 An example of coded blocks with a predetermined order is depicted, which is used to process multiple elements of the coded block.

[0019] Figure 6 An example of a template pattern for calculating local and variable coefficients located near the TU boundary is depicted.

[0020] Figure 7 Examples of a process for encoding video partitions according to some embodiments of the present disclosure are described.

[0021] Figure 8 Examples of processes for decoding video segments according to some embodiments of the present disclosure are described.

[0022] Figure 9 Examples of computing systems that can be used to implement some embodiments of this disclosure are described. Detailed Implementation

[0023] Various embodiments provide history-based Rice coding parameter derivations for video encoding and decoding. As mentioned above, an increasing amount of video data is being generated, stored, and transmitted. This is beneficial for improving the efficiency of video encoding and decoding techniques, thereby representing video with less data without compromising the visual quality of the decoded video. One way to improve encoding and decoding efficiency is through entropy encoding and decoding, which compresses processed video samples into a binary bitstream using as few bits as possible.

[0024] In entropy coding, transform coefficient data is binarized into binary bits, and coding algorithms such as context-adaptive binary arithmetic coding (CABAC) can further compress these binary bits into bits. Binarization requires the computation of binarization parameters, such as the Rice coding parameters used in the combination of truncated Rice (TR) and finite k-order Exp-Golomb (EGk) binarization processes specified in the Versatile Video Coding (VVC) specification. To improve coding efficiency, a history-based Rice coding parameter derivation method is employed. In this method, the Rice coding parameters of the TUs in the current CTU of a partition (e.g., a picture, slice, or tile) are derived based on a history counter (denoted as StatCoeff) calculated from the coefficients in previous TUs in the current CTU and the coefficients in one (or more) previous CTUs in the partition. The history counter is then used to derive a replacement variable (denoted as HistValue) which is used to derive the Rice coding parameters. The history counter can be updated when processing a TU. In existing video codec standards, the replacement variable HistValue of a TU remains unchanged even after the history counter has been updated. In other words, the replacement variable HistValue is only updated based on 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 coding parameters for the remaining positions within the current TU may reduce codec efficiency.

[0025] The various embodiments described herein address these issues by updating the replacement variable HistValue whenever the history counter StatCoeff is updated, thus synchronizing the updates of the replacement variable HistValue and the history counter StatCoeff and improving encoding / decoding efficiency. The following non-limiting examples illustrate some embodiments.

[0026] In one embodiment, once the history counter StatCoeff is updated, the replacement variable HistValue is also updated. Thus, the remaining positions within the current TU are encoded using the updated history counter StatCoeff and the corresponding updated replacement variable HistValue until both HistValue and the history counter StatCoeff are updated again. In another embodiment, the history counter StatCoeff is updated independently of previous history counter values, except for synchronous updates of the history counter StatCoeff and the replacement variable HistValue. By eliminating dependencies between history counters, video encoding and decoding can be implemented more efficiently, for example, through parallel processing. In another embodiment, since the update of the replacement variable HistValue is performed together with the update of the history counter StatCoeff, the step of initializing the replacement variable HistValue at the beginning of processing each TU can be eliminated, saving computational resources.

[0027] Using the Rice coding parameters determined as described above, the video encoder can binarize the prediction residual data (e.g., the quantization transform coefficients of the residuals) into binary bits and further compress the binary bits 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 to binary bits and determine the Rice coding parameters using any of the methods described above or any combination thereof, and then determine the coefficients based on the binary bits. The coefficients can be further dequantized and inversely transformed to reconstruct the video blocks used for display.

[0028] As described in this disclosure, some embodiments improve video encoding / decoding efficiency and computational efficiency by synchronizing the updates of the replacement variable HistValue and the history counter StatCoeff and eliminating dependencies between history counters of different TUs. By doing so, the replacement variable HistValue corresponding to the updated history counter StatCoeff can be used to derive the Rice coding parameters of the TU, and parallel processing can be implemented to accelerate this process. These techniques can become effective encoding / decoding tools in future video encoding / decoding standards.

[0029] Now refer to the attached diagram, Figure 1 This is a block diagram illustrating an example of a video encoder 100 for implementing the embodiments presented herein. Figure 1 In the example shown, the video encoder 100 includes a partitioning module 112, a transform module 114, a quantization module 115, an inverse quantization module 118, an inverse transform module 119, an in-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 coding module 116.

[0030] The input to the video encoder 100 is an input video 102 containing a sequence of pictures (also called frames or images). In a block-based video encoder, for each picture, the video encoder 100 uses a partitioning module 112 to divide the picture into blocks 104, and each block contains multiple pixels. These blocks can be macroblocks, CTUs, coding units, prediction units, and / or prediction blocks. A picture can include blocks of different sizes, and the block partitioning for different pictures in the video can also be different. Each block can be encoded using different prediction methods, such as intra-frame prediction, inter-frame prediction, or a mixture of intra-frame and inter-frame prediction.

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

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

[0033] The video encoder 100 can further use the quantization module 115 to quantize the transform coefficients to obtain quantized coefficients. Quantization involves dividing the sample by the quantization step size and then rounding it, while inverse quantization involves 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 video samples (transformed or untransformed), allowing fewer bits to be used to represent the video samples.

[0034] Intra-block coefficient / sample quantization can be performed independently; this method is used in some existing video compression standards such as H.264 and HEVC. For an N x M block, the two-dimensional coefficients of the block can be converted into a one-dimensional array using a specific scan order for coefficient quantization and encoding / decoding. Intra-block coefficient quantization can utilize scan order information. For example, the quantization of a given coefficient in a block may depend on the state of previous quantized values ​​along the scan order. To further improve encoding / decoding efficiency, more than one quantizer can be used. Which quantizer is used to quantize the current coefficient depends on information preceding the current coefficient in the encoding / decoding scan order. This quantization method is called correlated quantization.

[0035] 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. Smaller quantization step sizes correspond to finer quantization, while larger quantization step sizes correspond to coarser quantization. The quantization step size can be indicated by the quantization parameter (QP). Providing the quantization parameter in the encoded bitstream of the video allows the video decoder to apply the same quantization parameter for decoding.

[0036] The quantized samples are then encoded by the entropy coding module 116 to further reduce the size of the video signal. The entropy coding module 116 is configured to apply an entropy coding algorithm to the quantized samples. In some examples, the quantized samples are binary-coded into bits, and the encoding algorithm further compresses the bits into bits. Examples of binarization methods include, but are not limited to, truncated Rice (TR) and finite k-order Exp-Golomb (EGk) binarization. To improve encoding and decoding efficiency, a history-based Rice coding parameter derivation method is used, where the Rice coding parameters derived for a TU are based on variables obtained from or updated from previous TUs. 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, context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques. Entropy-coded data is added to the output encoded video 132 bitstream.

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

[0038] Blocks in subsequent images following the first intra-predicted image can be encoded using either inter-frame prediction or intra-frame prediction. In inter-frame prediction, the prediction of a block in an image comes from one or more previously encoded video images. To perform inter-frame prediction, the video encoder 100 uses an inter-frame prediction module 124. The inter-frame prediction module 124 is configured to perform motion compensation on the blocks based on motion estimates provided by the motion estimation module 122.

[0039] 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 the 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 of the reference block (e.g., x, y coordinates) and the position of the current block. This 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 this block in multiple decoded reference images 108. Therefore, multiple motion vectors are generated and provided to the inter-frame prediction module 124.

[0040] Inter-frame prediction module 124 uses one or more motion vectors and other inter-frame prediction parameters to perform motion compensation to generate a prediction for the current block (i.e., inter-frame prediction block 134). For example, based on one or more motion vectors, inter-frame prediction module 124 can locate one or more prediction blocks pointed to by one or more motion vectors in corresponding reference images. If there are more than one prediction block, these prediction blocks are combined with some weights to generate prediction block 134 for the current block.

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

[0042] To obtain the decoded image 108 for motion estimation, the reconstructed block 136 is processed by the in-loop filter module 120. The in-loop filter module 120 is configured to smooth pixel transitions, thereby improving video quality. The in-loop filter module 120 can be configured to implement one or more in-loop filters, such as a deblocking filter, a sample-adaptive offset (SAO) filter, or an adaptive loop filter (ALF), etc.

[0043] Figure 2 An example of a video decoder 200 for implementing the embodiments presented herein is depicted. The video decoder 200 processes encoded video 202 in a bitstream and generates decoded images 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, an in-loop filter module 220, an intra-frame prediction module 226, an inter-frame prediction module 224, and a decoded image buffer 230.

[0044] Entropy decoding module 216 is configured to perform entropy decoding of the encoded video 202. Entropy decoding module 216 decodes quantization coefficients, encoded parameters including intra-frame prediction parameters and inter-frame prediction parameters, and other information. In some examples, entropy decoding module 216 decodes the bitstream of the encoded video 202 into a binary representation, and then converts the binary representation into quantization levels of coefficients. The entropy-decoded coefficients are then inverse-quantized by inverse quantization module 218, and subsequently inverse-transformed to the pixel domain by inverse transform module 219. The functions of inverse quantization module 218 and inverse transform module 219 are similar to those described above. Figure 1 The inverse quantization module 118 and inverse transform module 119 are described above. The residual blocks from the inverse transform can be added to the corresponding prediction block 234 to generate the reconstruction block 236. For blocks that skip the transform, the inverse transform module 219 is not applied to those blocks. The dequantized samples generated by the inverse quantization module 218 are used to generate the reconstruction block 236.

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

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

[0047] Now for reference Figure 3 , Figure 3 Examples of CTU partitioning of images in a video according to some embodiments of this disclosure are depicted. (See above regarding...) Figure 1 and Figure 2 In order to encode images for video, the images are divided into blocks, for example... Figure 3 The image shows a Coding Tree Unit (CTU) 302 in a VVC. For example, a CTU 302 can be a 128×128 pixel block. CTUs are defined according to... Figure 3 Processed in the order shown. In some examples, such as... Figure 4 As shown, each CTU 302 in the image can be divided into one or more CUs (Coding Units) 402, which can be further divided into prediction units or transform units (TUs) for prediction and transformation. Depending on the coding scheme, the CTU 302 can be divided into multiple CUs 402. For example, in VVC, the CU 402 can be rectangular or square and can be encoded without further division into prediction units or TUs. Each CU 402 can be as large as its root CTU 302, or as small as a sub-part of the root CTU 302 (4×4 block). Figure 4 As shown, in VVC, the partitioning from CTU 302 to CU 402 can be a quadtree split, a binary tree split, or a ternary tree split. Figure 4 In the diagram, solid lines represent quadtree splits, while dashed lines represent binary or ternary tree splits.

[0048] As mentioned above Figure 1 and Figure 2 The quantization discussed here is used to reduce the dynamic range of elements in a block of video signal, thus using fewer bits to represent the video signal. In some examples, before quantization, the element at a specific location in the block is called a coefficient. After quantization, the quantized value of the coefficient is called the quantization level or grade. Quantization typically involves dividing by the quantization step size and subsequent rounding, while inverse quantization involves multiplying by the quantization step size. This quantization process is also known as scalar quantization. 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 VVC, correlated quantization is used.

[0049] For an N x M block, a specific scan order can be used to convert the block's two-dimensional coefficients into a one-dimensional array for coefficient quantization and encoding, and the same scan order can be used for encoding and decoding. Figure 5 An example of a coded block (e.g., a transform unit (TU)) with a predetermined scan order for processing coded block coefficients is shown. In this example, the coded block 500 is 8×8 in size, and processing begins at the lower right corner at position L0 and continues to the upper left corner at position L1. 63 End at this point. If block 500 is the transformed block, then Figure 5The predetermined order shown starts from the highest frequency and proceeds to the lowest frequency. In some examples, block processing, such as quantization and binarization, starts from the first non-zero element of the block according to a predetermined scan order. For example, if position L0-L 17 The coefficients at all points are zero, while L 18 If the coefficient at point L is non-zero, then the processing starts from L. 18 Starting with the coefficients at the specified location, and following the scan order for L... 18 Perform this for each subsequent coefficient.

[0050] Residual coding

[0051] In video encoding and decoding, residual coding is used to convert quantization levels into a bitstream. After quantization, there are N×M quantization levels for N×M transform unit (TU) coding blocks. These N×M levels can be zero or non-zero values. If a non-zero level is not binary, it is further binaryized into bits. Context-Adaptive Binary Arithmetic Coding (CABAC) can further compress these bits into bits. Furthermore, there are two context-based coding methods. Specifically, one method adaptively updates the context model based on adjacent coding information. This method is called context coding, and bits encoded in this way are called context-coded bits. Conversely, the other method assumes that the probability of 1 or 0 is always 50%, and therefore always uses a fixed context model without adjustment. This method is called bypass coding, and bits encoded in this way are called bypass bits.

[0052] For regular residual coding (RRC) blocks 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 two-dimensional coordinates (last_sig_coeff_x and last_sig_coeff_y) of the last non-zero level includes a total of four prefix and suffix syntax elements: last_sig_coeff_x_prefix, last_sig_coeff_y_prefix, last_sig_coeff_x_suffix, and last_sig_coeff_y_suffix. First, the syntax elements last_sig_coeff_x_prefix and last_sig_coeff_y_prefix are encoded using a contextual encoding method. If last_sig_coeff_x_suffix and last_sig_coeff_y_suffix appear, they are encoded using a bypass method. An RRC block can consist of several predefined sub-blocks. The syntax element sb_coded_flag is used to indicate whether the current sub-block has all levels equal to zero. If `sb_coded_flag` equals 1, there is at least one non-zero coefficient in the current sub-block. If `sb_coded_flag` equals 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 to 1 from `last_sig_coeff_x` and `last_sig_coeff_y` according to the encoding scan order, and is not encoded into the bitstream. Furthermore, the `sb_coded_flag` of the top-left sub-block containing the DC position is also derived to 1 and is not encoded into the bitstream. The syntax elements of `sb_coded_flag` in the bitstream are encoded using the context encoding method. RRC will start from the last non-zero sub-block, as described above regarding... Figure 5 The reverse encoding scan order discussed encodes sub-blocks one by one.

[0053] To guarantee worst-case throughput, a predefined value `remBinsPass1` is used to limit the maximum number of context-coded bits. Within a sub-block, RRC encodes the level at each position in reverse encoding scan order. If `remBinsPass1` is greater than 4, when encoding the current level, a flag named `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]`, where `n` is the index along the scan order of the current position within the sub-block, indicates whether the absolute level is 1 or greater than 1. If the absolute level is greater than 1, `par_level_flag` is encoded to indicate whether the level in the VVC is odd or even, and then `abs_level_gtx_flag[n][1]` is present. The flags `par_level_flag` and `abs_level_gtx_flag[n][1]` are also used together to indicate whether the level is 2, 3, or greater than 3. After encoding each of the above syntax elements into context-encoded binary bits, the value of remBinsPass1 will decrease by 1.

[0054] If the absolute level is greater than 3 or the value of remBinsPass1 is not greater than 4, then after encoding the aforementioned binary bits using the context encoding method, the other two syntax elements, abs_remainder and dec_abs_level, can be encoded as the binary bits of the remaining levels' bypass encoding. Furthermore, the symbols for each level within the block will also be encoded to represent the quantization level, and they will be encoded as binary bits of bypass encoding.

[0055] Another residual coding method uses `abs_level_gtxX_flag` and the remaining level to allow conditional parsing of the syntax elements for level encoding used in residual blocks, and the corresponding binary representations of the absolute values ​​of the levels are 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, such as 0, 1, 2, or N. If `abs_level_gtxY_flag` is 0, where Y is an integer between 0 and N-1, then 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. Furthermore, 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, representing the value after removing (N+1) from the level. Typically, abs_level_gtxX_flag is encoded using the context encoding method, while the remaining levels are encoded using the bypass method.

[0056] Table 1 Residual coding based on abs_level_gtxX_flag and remainder

[0057] 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 …

[0058] For blocks encoded in Transform Skip Residual Coding (TSRC) mode, TSRC encodes each sub-block sequentially from the top-left sub-block along the coding scan order. Similarly, the syntax element `sb_coded_flag` indicates whether the current sub-block has all residuals equal to zero. When a specific condition occurs, all syntax elements of `sb_coded_flag` for all sub-blocks except the last sub-block are encoded into the bitstream. If for all sub-blocks before the last sub-block, all `sb_coded_flag` values ​​are not equal to 1, then for the last sub-block, `sb_coded_flag` will be exported as 1, and this flag will not be encoded into the bitstream. To guarantee worst-case throughput, a predefined value `RemCcbs` is used to limit the maximum number of bits for context encoding. If the current sub-block has a non-zero level, TSRC will encode the level at each position using the coding scan order. If `RemCcbs` is greater than 4, the following syntax elements will be encoded using the context encoding method. For each level, `sig_coeff_flag` is first encoded into the bitstream to indicate whether the level is zero. If the level is not zero, `coeff_sign_flag` is encoded to indicate whether the level is positive or negative. Then, `abs_level_gtx_flag[n][0]` is encoded to indicate whether the current absolute level at the current position is greater than 1, where n is the index along the scan order of the current position within the sub-block. If `abs_level_gtx_flag[n][0]` is not zero, `par_level_flag` is encoded. After encoding each of the above syntax elements using the context encoding method, the value of `RemCcbs` is decreased by 1.

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

[0060] Derivation of Rice Encoding Parameters

[0061] In the current RRC design in VVC, the two syntax elements `abs_remainder` and `dec_abs_level`, encoded as bypass bits, can exist in the bitstream of the remaining levels. Both `abs_remainder` and `dec_abs_level` are binarized using a combination of truncated Rice (TR) and finite k-order Exp-Golomb (EGk) binarization processes specified in the VVC specification. This requires the Rice coding parameters to binarize the given level. To obtain the optimal Rice coding parameters, a local summation method is used, as described below.

[0062] The array AbsLevel[xC][yC] represents an array of absolute values ​​of the transform coefficient levels of the current transform block. Given an array AbsLevel[x][y] of transform blocks with color component indices cIdx and a top-left luminance position (x0, y0), derive the local sum variable locSumAbs according to the following pseudocode procedure:

[0063]

[0064] Where log2TbWidth and log2TbHeight are the base-2 logarithms of the width and height of the transform block, respectively. For abs_remainder and dec_abs_level, the variable baseLevel is 4 and 0, respectively. Given the local variable locSumAbs, the Rice encoding parameter cRiceParam is derived as shown in Table 2.

[0065] Table 2 - cRiceParam Specification Based on locSumAbs

[0066] 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

[0067] Derivation of Rice Encoding Parameters Based on History

[0068] If the coefficients are located on the TU boundary, or if the Rice method is used for decoding first, the template calculation used for deriving the Rice coding parameters may produce inaccurate coefficient estimates. For these coefficients, the template calculation is biased towards 0 because some template positions may be located outside the TU and interpreted or initialized to the value 0. Figure 6 An example template pattern for calculating locSumAbs for coefficients located near the TU boundary is shown. Figure 6 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 positions of its neighboring samples in the template pattern are shown as patterned blocks. The patterned blocks indicate the predetermined nearest neighbors of the current coefficient used to compute the local and variable locSumAbs.

[0069] exist Figure 6 In the above derivation of the Rice coding parameters, since the current coefficient 606 is close to the boundary of TU 604, some neighboring samples in the template pattern, such as neighboring samples 608B and 608E, are outside the TU boundary. In the derivation of the Rice coding parameters above, when calculating the local sum variable locSumAbs, these neighboring samples outside the boundary are set to 0, leading to inaccurate Rice coding parameter derivation. For high bit depth samples (e.g., more than 10 bits), the number of neighboring samples outside the TU boundary can be large. Setting these large numbers to 0 will introduce more errors into the Rice coding parameter derivation.

[0070] To improve the accuracy of estimating Rice coding parameters from the computed template, it is recommended that, for template locations outside the current TU, the local sum variable locSumAbs be updated using historical derived values ​​instead of initializing it to 0. An implementation of this method is shown below in an excerpt of the VVC specification text from clause 9.3.3.2, with the recommended text underlined.

[0071] To maintain the history of adjacent coefficients / sample values, a history counter for each color component, StatCoeff[cIdx], is used, where cIdx = 0, 1, 2, representing the three color components Y, U, and V, respectively. If the CTU is the first CTU in a partition (e.g., image, stripe, or tile), StatCoeff[cIdx] is initialized as follows:

[0072] StatCoeff[idx] = 2 * Floor(Log2(BitDepth-10) (1)

[0073] Here, BitDepth specifies the bit depth of the samples in the video's luminance and chrominance arrays; Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x. Before TU decoding and history counter updates, the replacement variable HistValue is initialized as follows:

[0074] HistValue[cIdx] = 1 << StatCoeff[cIdx] (2)

[0075] 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 summation variable locSumAbs is re-derived according to the following pseudocode procedure, where changes are underlined:

[0076]

[0077]

[0078] Before encoding each TU, the HistValue, calculated according to equation (2), is used to derive the Rice encoding parameters so that the first abs_remainder or dec_abs_level syntax element of each TU can be encoded if possible.

[0079] The history counter StatCoeff is updated once per transition unit (TU) using an exponential moving average process from the first non-zero Golomb-Rice encoded transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]). When the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder, the history counter StatCoeff for the color component cIdx is updated as follows:

[0080] StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor(Log2(abs_remainder[cIdx])) + 2 ) >> 1 (3)

[0081] When the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as dec_abs_level, the history counter StatCoeff for the color component cIdx is updated as follows:

[0082] StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor(Log2(dec_abs_level[cIdx])) ) >> 1 (4)

[0083] Before decoding the next TU, according to equation (2), the updated StatCoeff can be used to compute the replacement variable HistValue for the next TU.

[0084] As described above, when the first non-zero Golomb-Rice coded transform coefficient in the current TU is encoded as either `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 coding parameters may not be a suitable value for finding the optimal Rice coding parameters for the remaining positions in the current TU. In this disclosure, an embodiment is described that synchronizes the updates of `HistValue` and the history counter `StatCoeff`, such that the replacement variable `HistValue` corresponding to the updated history counter `StatCoeff` is used to calculate the Rice coding parameters.

[0085] In one embodiment, when the first non-zero Golomb-Rice encoded transform coefficient in the TU of color component cIdx is encoded as abs_remainder, the history counter of color component cIdx is updated according to equation (3). When the first non-zero Golomb-Rice encoded transform coefficient in the TU of color component cIdx is encoded as dec_abs_level, the history counter of color component cIdx is updated according to equation (4). Once the history counter StatCoeff[cIdx] is updated, the replacement variable HistValue is updated according to equation (5), and the updated replacement variable HistValue is used to derive Rice encoding parameters for the remaining abs_remainder and dec_abs_level syntax elements in the current TU of color component cIdx, until the new StatCoeff[cIdx] and HistValue are updated again.

[0086] HistValue = 1 << StatCoeff[cIdx] (5)

[0087] The possible changes to the VVC specification are as follows.

[0088] Residual coding syntax

[0089] The modifications to section 7.3.11.11 (Residual Coding Syntax) are as follows (the added parts are underlined):

[0090]

[0091]

[0092] In another embodiment, the history counter StatCoeff is updated independently of previous history counter values, in addition to synchronously updating the history counter StatCoeff and the replacement variable HistValue. By eliminating dependencies between history counters, such as through parallel processing, video encoding and decoding can be implemented more efficiently.

[0093] In this embodiment, when the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as abs_remainder, the history counter of the color component cIdx is updated as follows:

[0094] StatCoeff[cIdx] = Floor(Log2(abs_remainder[cIdx])) + 1 (6)

[0095] When the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as dec_abs_level, the history counter for the color component cIdx is updated as follows:

[0096] StatCoeff[cIdx] = Floor(Log2(dec_abs_level[cIdx])) (7)

[0097] Once the history counter StatCoeff[cIdx] is updated, HistValue will be updated according to equation (5), and the updated HistValue will be used to derive Rice encoding parameters for the remaining abs_remainder and dec_abs_level syntax elements in the current TU of color component cIdx, until the new StatCoeff[cIdx] and HistValue are updated again.

[0098] The possible changes to the VVC specification are as follows.

[0099] The following modifications have been made to Residual Coding Syntax 7.3.11.11 (Residual Coding Syntax) (the added parts are marked with underscores, and the content with strikethroughs will be deleted):

[0100]

[0101]

[0102] As can be seen from the table above, StatCoeff is determined based on abs_remainder or dec_abs_level and is independent of previous StatCoeff values. Therefore, the StatCoeff values ​​of different TUs are independent of each other.

[0103] In another embodiment, since the update of the replacement variable HistValue is performed together with the update of the history counter StatCoeff, the step of initializing the replacement variable HistValue at the beginning of processing each TU can be eliminated, thus saving computational power.

[0104] In this embodiment, if the CTU is the first CTU in a strip or tile, the replacement variable HistValue is initialized with the initial StatCoeff[cIdx] as follows:

[0105] HistValue = sps_persistent_rice_adaptation_enabled_flag? 1 < <StatCoeff[cIdx] : 0 (8)

[0106] The initial HistValue is used for encoding until it is updated according to the following rules.

[0107] When the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as abs_remainder, the history counter of the color component cIdx is updated according to equation (3) (or equation (6)). When the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as dec_abs_level, the history counter of the color component cIdx is updated according to equation (4) (or equation (7)).

[0108] Once the history counter StatCoeff[cIdx] is updated, the replacement variable HistValue will be updated according to equation (5). The updated replacement variable HistValue will be used to derive Rice encoding parameters for the remaining abs_remainder and dec_abs_level syntax elements until the new StatCoeff[cIdx] and HistValue are updated again.

[0109] The possible changes to the VVC specification are as follows.

[0110] Residual coding syntax

[0111] The modifications to section 7.3.11.11 (Residual Coding Syntax) are as follows (the added parts are underlined):

[0112]

[0113]

[0114]

[0115] Since the replacement variable HistValue is updated every 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, it is not necessary to initialize the replacement variable HistValue at the beginning of processing each TU. Thus, as shown above, the initialization step can be eliminated, saving computational resources for the video encoder and decoder.

[0116] Figure 7 An example of a process 700 for encoding video partitions according to some embodiments of the present disclosure is described. One or more computing devices (e.g., computing devices implementing video encoder 100) implement this by executing suitable program code (e.g., program code implementing entropy encoding module 116). Figure 7 The operations depicted are shown in the accompanying drawings. For illustrative purposes, process 700 is described with reference to some examples depicted in the drawings. However, other implementations are also possible.

[0117] In box 702, process 700 includes accessing partitions of the video signal. A partition can be a video frame, strip, tile, or any type of partition processed as a unit by the video encoder during encoding. A partition comprises a set of CTUs, and each CTU comprises one or more CUs, and as... Figure 6 As shown in the example, each CU includes multiple TUs for encoding.

[0118] In block 704, including 706-712, process 700 includes processing each CTU in the set of CTUs in the partition to encode the partition into bits. In block 706, process 700 includes updating the replacement variable HistValue and the history counter StatCoeff together. As described above, in some embodiments, the history counter StatCoeff can be updated according to equations (3) and (4) when the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder and dec_abs_level, respectively. In other embodiments, the history counter StatCoeff can be updated according to equations (6) and (7) when the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder and dec_abs_level, respectively.

[0119] In both cases, the replacement variable HistValue is updated whenever the history counter StatCoeff is updated. For example, if the replacement variable HistValue is updated according to equation (3) (or equation (6)), the history counter StatCoeff is updated according to equation (5) based on the updated value of the history counter StatCoeff. Similarly, if the replacement variable HistValue is updated according to equation (4) (or equation (7)), the history counter StatCoeff is updated according to equation (5) based on the updated value of the history counter StatCoeff. Thus, both the history counter StatCoeff and the replacement variable HistValue are updated before the next Rice coding parameter is calculated.

[0120] In box 708, the Rice coding parameters of the TU in the CTU are calculated based on the updated replacement variable HistValue, as described above. In box 710, procedure 700 includes encoding the TU in the CTU into a binary representation based on the calculated Rice coding parameters, for example, by a combination of truncated Rice (TR) and a finite k-order EGK as specified in the VVC specification. In box 712, procedure 700 includes encoding the binary representation of the CTU into bits for inclusion in the video bitstream. For example, the encoding can be performed using Context Adaptive Binary Arithmetic Coding (CABAC) discussed above. In box 714, procedure 700 includes outputting the encoded video bitstream.

[0121] Figure 8 An example of a process 800 for decoding video partitions according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing suitable program code. Figure 8The operation is shown. For example, a computing device implementing the video decoder 200 can do so by executing the program code of the entropy decoding module 216, the inverse quantization module 218, and the inverse transform module 219. Figure 8 The operations depicted are shown in the accompanying drawings. For illustrative purposes, process 800 is described with reference to some examples depicted in the drawings. However, other implementations are also possible.

[0122] In box 802, process 800 includes accessing a binary string or binary representation of a partition representing a video signal. The partition can be a video frame, strip, or tile, or any type of partition processed as a unit by the video encoder during encoding. The partition comprises a set of CTUs. Each CTU includes one or more CUs, and as... Figure 6 As shown in the example, each CU includes multiple TUs for encoding.

[0123] In block 804, including 806-812, process 800 includes processing the binary string of each CTU in the CTU set in the partition to generate a decoded sample of the partition. In block 806, process 800 includes updating the replacement variable HistValue in conjunction with an update to the history counter StatCoeff. As described above, in some embodiments, the history counter StatCoeff can be updated according to equations (3) and (4) when the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder and dec_abs_level, respectively. In other embodiments, the history counter StatCoeff can be updated according to equations (6) and (7) when the first non-zero Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder and dec_abs_level, respectively.

[0124] In both cases, the replacement variable HistValue is updated whenever the history counter StatCoeff is updated. For example, if the replacement variable HistValue is updated according to equation (3) (or equation (6)), the history counter StatCoeff is updated according to equation (5) based on the updated value of the history counter StatCoeff. Similarly, if the replacement variable HistValue is updated according to equation (4) (or equation (7)), the history counter StatCoeff is updated according to equation (5) based on the updated value of the history counter StatCoeff. Thus, both the history counter StatCoeff and the replacement variable HistValue are updated before the next Rice coding parameter is calculated.

[0125] In box 808, process 800 includes calculating the Rice encoding parameters of the TU in the CTU based on the updated replacement variable HistValue, as described above. In box 810, process 800 includes decoding the binary string or binary representation of the TU in the CTU into coefficient values ​​based on the calculated Rice encoding parameters, for example, by a combination of truncated Rice (TR) and a finite k-order EGK as specified in the VVC specification. In box 812, process 800 includes, for example, by a combination of truncated Rice (TR) and a finite k-order EGK, as described above. Figure 2 The discussed inverse quantization and inverse transform are used to reconstruct the pixel values ​​of the TU in the CTU. In box 814, process 800 includes the decoding partition of the output video.

[0126] Although in the above description, in the figure (e.g., Figure 6 The diagram above describes and illustrates a TU, but the same technique can be applied to a transform block (TB). In other words, in the embodiments given above (including the figures), TU can also represent TB.

[0127] Example of a computational system for quantization related to video encoding and decoding

[0128] Any suitable computing system can be used to perform the operations described herein. For example, Figure 9 It describes what can be achieved Figure 1 Video encoder 100 or Figure 2 Examples of computing devices 900 for video decoder 200. In some embodiments, computing device 900 may include processor 912 communicatively coupled to memory 914 and executing computer-executable program code and / or accessing information stored in memory 914. Processor 912 may include a microprocessor, application-specific integrated circuit (“ASIC”), state machine, or other processing device. Processor 912 may include any number (including one) of processing devices. Such a processor may include or be able to communicate with a computer-readable medium storing instructions that, when executed by processor 912, cause the processor to perform the operations described in this disclosure.

[0129] 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 code to a processor. Non-limiting examples of computer-readable media include disks, memory chips, ROM, RAM, ASICs, configured processors, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor may 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.

[0130] 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 multiple external or internal devices, such as input or output devices. For example, the computing device 900 is shown with an input / output (“I / O”) interface 918 that can 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 communicative coupling can be implemented in any suitable manner (e.g., via a printed circuit board connection, via a cable connection, via wireless communication, etc.). Non-limiting examples of input devices 920 include touchscreens (e.g., one or more cameras for imaging a touch area or a pressure sensor for detecting pressure changes caused by a touch), mice, keyboards, or any other device that can be used to generate input events in response to physical actions of a user of the computing device. Non-limiting examples of output device 922 include an LCD screen, an external monitor, a speaker, or any other device that can be used to display or otherwise present the output generated by the computing device.

[0131] Computing device 900 can configure processor 912 to perform the above-mentioned tasks. Figure 1-8 Program code describing one or more operations. The program code may include video encoder 100 or video decoder 200. The program code may reside in memory 914 or any suitable computer-readable medium and may be executed by processor 912 or any other suitable processor.

[0132] 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 adapted to establish a wired or wireless data connection to one or more data networks 928. Non-limiting examples of the network interface device 924 include Ethernet network adapters, modems, etc. The computing device 900 may transmit messages as electronic or optical signals via the network interface device 924.

[0133] General considerations

[0134] This disclosure sets forth numerous specific details to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter can be practiced without these specific details. In other instances, methods, apparatus, or systems known to a person of ordinary skill have not been described in detail so as not to obscure the claimed subject matter.

[0135] Unless otherwise expressly stated, it should be understood that throughout the discussion in this specification, terms such as “processing,” “estimating,” “calculating,” “determining,” and “identifying” refer to the actions or processing of a computing device, such as one or more computers or similar electronic computing devices, which manipulate or convert data represented as physical electronic or magnetic quantities within the memory, registers, or other information storage, transmission, or display devices of a computing platform.

[0136] The one or more systems discussed in this disclosure are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide results based on one or more inputs. Suitable computing devices include multi-purpose microprocessor-based computer systems that access stored software for programming or configuring computing systems, ranging from general-purpose computing devices to dedicated computing devices that implement one or more embodiments of this subject matter. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings contained in this disclosure in software used when programming or configuring a computing device.

[0137] Embodiments of the methods disclosed herein can be executed in the operation of such a computing device. The order of the boxes presented in the above examples can be varied—for example, the boxes can be reordered, combined, and / or decomposed into sub-boxes. Some boxes or processes can be executed in parallel.

[0138] The use of “suitable for” or “configured to” in this disclosure implies open and inclusive language, which does not preclude a device from being adapted or configured to perform additional tasks or steps. Furthermore, the use of “based on” implies openness and inclusiveness because processing, steps, calculations, or other actions “based on” one or more of the stated conditions or values ​​can actually be based on additional conditions or values ​​beyond those stated conditions or values. The headings, lists, and numbering included in this disclosure are for convenience only and are not intended to be limiting.

[0139] While the subject matter has been described in detail with reference to specific embodiments thereof, it should be understood that those skilled in the art, upon understanding the foregoing, can readily make modifications, variations, and equivalents to these embodiments. Therefore, it should be understood that this disclosure is presented for illustrative purposes rather than for limitation, and does not exclude modifications, variations, and / or additions to the subject matter that would be obvious to those skilled in the art.

Claims

1. A method for decoding video, the method comprising: Access the binary string representing a partition of the video, the partition comprising multiple coding tree units (CTUs); Decoding each of the plurality of CTUs in the partition, wherein decoding the CTU includes: Update the history counter StatCoeff used to calculate the color components of Rice coding parameters; Before calculating the next Rice encoding parameter, the replacement variable HistValue is updated based on the updated history counter; The Rice coding parameters of the transform unit TU in the CTU are calculated based on the updated replacement variable HistValue; Based on the calculated Rice encoding parameters, the binary string corresponding to TU in the CTU is decoded into the coefficient value of TU; and The pixel value of the TU in the CTU is determined based on the coefficient value; and Output the decoded partitions of the video, wherein the decoded partitions of the video include multiple decoded CTUs within the partitions. The method further includes setting the history counter StatCoeff to an initial value based on the bit depth of the samples of the luminance and chrominance arrays of the video.

2. The method according to claim 1, wherein, Updating the historical counter StatCoeff includes: When it is determined that the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as abs_remainder, the history counter StatCoeff of the color component cIdx is updated to: StatCoeff[cIdx] = Floor(Log2(abs_remainder[cIdx])) + 1; and When it is determined that the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as dec_abs_level, the history counter of the color component cIdx is updated to: StatCoeff[cIdx] = Floor(Log2(dec_abs_level[cIdx])), Where Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

3. The method according to claim 1, wherein, The partition is a frame, strip, or tile.

4. The method according to claim 1, wherein, The calculation of the Rice coding parameters of the TU in the CTU based on the historical counter includes: Using the values ​​of the neighboring coefficients in the predetermined nearest neighbors of the coefficients in the TU of the CTU and the substitution variable HistValue, the local sum variable locSumAbs of the coefficients in the TU of the CTU is calculated; and The Rice encoding parameters of the TU are derived based on the local variable locSumAbs.

5. The method according to claim 4, wherein, The calculation of the local sum variable locSumAbs of the coefficients in the TU of the CTU includes: Determine one of a plurality of neighboring coefficients from a predetermined nearest neighbor of the coefficient outside the TU; and The local sum variable locSumAbs is calculated using the replacement variable HistValue as the value of the adjacent coefficient outside the TU.

6. The method according to claim 1, wherein, Updating the replacement variable HistValue based on the historical counter includes updating the replacement variable HistValue of the color component cIdx by calculating the following formula: HistValue[cIdx] = 1 << StatCoeff[cIdx], StatCoeff represents the history counter.

7. A system comprising: Processing equipment; and A non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium, and thereby perform the following operations: Access a binary string representing a partition of a video, the partition comprising multiple coding tree units (CTUs); Decoding each of the multiple CTUs in the partition includes: Update the history counter StatCoeff used to calculate the color components of Rice coding parameters; Before calculating the next Rice encoding parameter, the replacement variable HistValue is updated based on the updated history counter; The Rice coding parameters of the transform unit TU in the CTU are calculated based on the updated replacement variable HistValue; Based on the calculated Rice encoding parameters, the binary string corresponding to TU in the CTU is decoded into the coefficient value of TU; and The pixel value of the TU in the CTU is determined based on the coefficient value; and Output the decoded partitions of the video, wherein the decoded partitions of the video include multiple decoded CTUs within the partitions. The processing device is further configured to set the history counter StatCoeff to an initial value based on the bit depth of the samples of the luminance and chrominance arrays of the video.

8. A method for encoding video, the method comprising: Access a partition of the video, the partition comprising multiple coding tree units (CTUs); Processing the video partitions to generate binary representations of the partitions, the processing includes: Encoding each of the plurality of CTUs in the partition, wherein encoding the CTU includes: Update the history counter StatCoeff used to calculate the color components of Rice coding parameters; Before calculating the next Rice encoding parameter, the replacement variable HistValue is updated based on the updated history counter; The Rice coding parameters of the transform unit TU in the CTU are calculated based on the updated replacement variable HistValue; and Based on the calculated Rice encoding parameters, the coefficient value of the TU is encoded into the binary representation corresponding to the TU in the CTU; and The binary representation of the partition is encoded into the video stream. The method further includes setting the history counter StatCoeff to an initial value based on the bit depth of the samples of the luminance and chrominance arrays of the video.

9. The method according to claim 8, wherein, Updating the historical counter StatCoeff includes: When it is determined that the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as abs_remainder, the history counter StatCoeff of the color component cIdx is updated to: StatCoeff[cIdx] = Floor(Log2(abs_remainder[cIdx])) + 1; and When it is determined that the first non-zero Golomb-Rice coded transform coefficient in the TU is encoded as dec_abs_level, the history counter of the color component cIdx is updated to: StatCoeff[cIdx] = Floor(Log2(dec_abs_level[cIdx])), Where Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

10. The method according to claim 8, wherein, The partition is a frame, strip, or tile.

11. The method according to claim 8, wherein, The calculation of the Rice coding parameters of the TU in the CTU based on the historical counter includes: Using the values ​​of the neighboring coefficients in the predetermined nearest neighbors of the coefficients in the TU of the CTU and the substitution variable HistValue, the local sum variable locSumAbs of the coefficients in the TU of the CTU is calculated; and The Rice encoding parameters of the TU are derived based on the local variable locSumAbs.

12. The method according to claim 11, wherein, The calculation of the local sum variable locSumAbs of the coefficients in the TU of the CTU includes: Determine one of a plurality of neighboring coefficients from a predetermined nearest neighbor of the coefficient outside the TU; and The local sum variable locSumAbs is calculated using the replacement variable HistValue as the value of the adjacent coefficient outside the TU.

13. The method according to claim 8, wherein, Updating the replacement variable HistValue based on the historical counter includes updating the replacement variable HistValue of the color component cIdx by calculating the following formula: HistValue[cIdx] = 1 << StatCoeff[cIdx], StatCoeff represents the history counter.

14. A system comprising: Processing equipment; and A non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium, and thereby perform the following operations: Access a partition of the video, the partition comprising multiple coding tree units (CTUs); Processing the video partitions to generate binary representations of the partitions, the processing includes: Encoding each of the plurality of CTUs in the partition, wherein encoding the CTU includes: Update the history counter StatCoeff used to calculate the color components of Rice coding parameters; Before calculating the next Rice encoding parameter, the replacement variable HistValue is updated based on the updated history counter; The Rice coding parameters of the transform unit TU in the CTU are calculated based on the updated replacement variable HistValue; and Based on the calculated Rice coding parameters, the coefficient values ​​of the TU are encoded into the binary representation corresponding to the TU in the CTU; and The binary representation of the partition is encoded into the video stream. The processing device is further configured to set the history counter StatCoeff to an initial value based on the bit depth of the samples of the luminance and chrominance arrays of the video.

15. A non-transitory computer-readable storage medium having a computer program and a bitstream stored thereon, wherein, When the computer program is executed by the processing device, it implements the method of claim 8 to generate the bitstream.

Images