Video decoding method, video encoding method, video decoding device, and video encoding device

Abstract

In some embodiments, a video decoder uses history-based Rice parameter derivation and wavefront parallel processing (WPP) to decode video from a bitstream of the video. A video decoder accesses a binary string representing a partition of video and processes each coding tree unit (CTU) in the partition to generate a coefficient value decoded in the CTU. The process includes: before decoding the CTU, determining whether the CTU is a first CTU of a current CTU row in a partition; if so, the historical counter is set as an initial value. The process further includes decoding the CTU by calculating a Rice parameter of a transform unit (TU) in the CTU based on a value of the history counter; and decoding a binary string corresponding to a TU in the CTU into a coefficient value of the TU based on the calculated Rice parameter.

Description

[0001] This application is a divisional application of Chinese patent application No. 202280042714.1, entitled "History-based Rice parameter derivation for wavefront parallel processing in video coding", which entered the Chinese national phase of PCT international patent application PCT / US2022 / 075502 filed on August 26, 2022. Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 260,600, filed August 26, 2021, entitled "History-Based Rice Parameter Derivations for Wavefront Parallel Processing in Video Coding"; U.S. Provisional Application No. 63 / 262,078, filed October 4, 2021, entitled "History-Based Rice Parameter Derivations for Wavefront Parallel Processing in Video Coding"; and U.S. Provisional Application No. 63 / 251,385, filed October 1, 2021, entitled "Representation of Bit Depth Range for VVC OperationRange Extension," the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to computer-implemented methods and systems for video processing. Specifically, this disclosure relates to history-based Rice parameter derivation for wavefront parallel processing in video coding. Background Technology

[0004] The ubiquitous availability of camera-enabled devices, such as smartphones, tablets, and computers, has made capturing video or images easier than ever before. However, even short videos can have a very large data volume. Video encoding technologies (including video encoding and decoding) enable video data to be compressed into smaller sizes, allowing for the storage and transmission of a wide variety of videos. Video encoding is used in a wide range of applications, such as digital television broadcasting, video transmission over the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing), DVDs, Blu-ray discs, etc. 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 encoding schemes. Summary of the Invention

[0005] Some embodiments relate to history-based Rice parameter derivation for wavefront parallel processing in video coding. In one example, a method for decoding video includes: accessing a binary string representing a partition of the video, the partition including a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; for each CTU in the plurality of CTUs in the partition, before decoding the CTU, determining that parallel coding is enabled and that the CTU is the first CTU in the current CTU row of the one or more CTU rows in the partition; in response to determining that parallel coding is enabled and that the CTU is the first CTU in the current CTU row in the partition, setting a history counter for calculating the color components of the Rice parameter to an initial value; decoding the CTU, including: calculating the Rice parameter of a transform unit (TU) in the CTU based on the history counter, decoding the binary string corresponding to the TU in the CTU into coefficient values ​​of the TU based on the calculated Rice parameter, and determining the pixel values ​​of the TU in the CTU according to the coefficient values; and outputting a decoded partition of the video, the decoded partition including the plurality of decoded CTUs in the partition.

[0006] In another example, a non-transitory computer-readable medium stores program code executable by one or more processing devices to perform multiple operations, including: accessing a binary string representing a partition of video, the partition comprising multiple coding tree units (CTUs) forming one or more rows of CTUs; for each CTU in the partition, determining, before decoding the CTU, that parallel coding is enabled and that the CTU is the first CTU in the current row of the one or more CTUs in the partition; in response to determining that parallel coding is enabled and that the CTU is the first CTU in the current row of the partition, setting a history counter used to calculate the color components of the Rice parameter to an initial value; decoding the CTU, including: calculating the Rice parameter of the transform unit (TU) in the CTU based on the history counter, decoding the binary string corresponding to the TU in the CTU into coefficient values ​​of the TU based on the calculated Rice parameter, and determining the pixel value of the TU in the CTU according to the coefficient values; and outputting a decoded partition of the video, the decoded partition comprising the multiple decoded CTUs in the partition.

[0007] In another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform a plurality of operations, the plurality of operations including: accessing a binary string representing a partition of video, the partition including a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; for each CTU in the plurality of CTUs in the partition, determining, before decoding the CTU, that parallel coding is enabled and that the CTU is the first CTU in the current CTU row of the one or more CTU rows in the partition; in response to determining that parallel coding is enabled and that the CTU is the first CTU in the current CTU row in the partition, setting a history counter used to calculate the color components of the Rice parameter to an initial value; decoding the CTU, including: calculating the Rice parameter of the transform unit (TU) in the CTU based on the history counter, decoding the binary string corresponding to the TU in the CTU into coefficient values ​​of the TU based on the calculated Rice parameter, and determining the pixel value of the TU in the CTU according to the coefficient value; and outputting a decoded partition of video, the decoded partition including the plurality of decoded CTUs in the partition.

[0008] In another example, a method for encoding video includes: accessing a partition of the video, the partition comprising a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; processing the partition of the video to generate a binary representation of the partition, the processing including: for each of the plurality of CTUs in the partition, before encoding the CTU, determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of one or more CTU rows in the partition; in response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, setting a history counter used to calculate the color components of the Rice parameter to an initial value; encoding the CTU, including: calculating the Rice parameter of the transform unit (TU) in the CTU based on the history counter, and encoding the coefficient values ​​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 the bitstream of the video.

[0009] In another example, a non-transitory computer-readable medium stores program code executable by one or more processing devices to perform multiple operations, including: accessing a partition of video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; processing the partition of video to generate a binary representation of the partition, the processing including: for each CTU in the partition, determining, before encoding the CTU, that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the one or more CTU rows in the partition; in response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, setting a history counter used to calculate the color components of the Rice parameter to an initial value; encoding the CTU, including: calculating the Rice parameter of the transform unit (TU) in the CTU based on the history counter, and encoding the coefficient values ​​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 the video bitstream.

[0010] In another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform a plurality of operations, the plurality of operations including: accessing a partition of video, the partition including a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; processing the partition of video to generate a binary representation of the partition, the processing including: for each of the plurality of CTUs in the partition, before encoding the CTU, determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of one or more CTU rows in the partition; in response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, setting a history counter used to calculate the color components of the Rice parameter to an initial value; encoding the CTU, including: calculating the Rice parameter of the transform unit (TU) in the CTU based on the history counter, and encoding the coefficient values ​​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 the bitstream of the video.

[0011] These illustrative embodiments are mentioned not to limit or restrict this disclosure, but to provide examples to aid in understanding it. Further embodiments are discussed in the detailed description, and further description is provided therein. Attached Figure Description

[0012] The features, embodiments, and advantages of this disclosure will be better understood when the following detailed description is read with reference to the accompanying drawings.

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

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

[0015] Figure 3 Examples of encoding tree unit partitioning of images in a video according to some embodiments of the present disclosure are described.

[0016] Figure 4 Examples of coding unit partitioning of coding tree units according to some embodiments of the present disclosure are described.

[0017] Figure 5 An example of an encoded block is described, in which the elements of the encoded block are processed in a predetermined order.

[0018] Figure 6 An example of a template pattern for calculating the local summation variable of coefficients located near the boundary of a transformation unit is described.

[0019] Figure 7 An example of a tile is described, in which wavefront parallel processing is enabled for the tile.

[0020] Figure 8 Examples of frames, tiles, and coding tree units contained in the frames, according to some embodiments of the present disclosure, are described, wherein a history counter is calculated for the frame, the tiles, and the coding tree units contained in the frame.

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

[0022] Figure 10 Examples of a process for decoding video partitions according to some embodiments of the present disclosure are described.

[0023] Figure 11 Another example of a process for encoding video partitions according to some embodiments of the present disclosure is described.

[0024] Figure 12 Another example of a process for decoding video partitions according to some embodiments of the present disclosure is described.

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

[0026] The embodiments provide history-based Rice parameter derivations for wavefront parallel processing in video coding. As discussed above, an increasing amount of video data is being generated, stored, and transmitted. It is advantageous to improve the efficiency of video coding techniques, thereby representing the video with less data without compromising the visual quality of the decoded video. One way to improve coding efficiency is through entropy coding, which compresses processed video samples into a binary bitstream using as few bits as possible. On the other hand, since videos typically contain large amounts of data, it is advantageous to reduce processing time during encoding (encoding and decoding). For this purpose, parallel processing can be employed in video encoding and decoding.

[0027] In entropy coding, video samples are binarized into binary bins, and coding algorithms such as Context Adaptive Binary Arithmetic Coding (CABAC) can further compress the bins into bits. Binarization requires computing binarization parameters, such as the Rice parameters used in the combination of truncated Rice (TR) and finite k-order exponential Columbus (EGk) binarization processes specified in the Multifunctional Video Coding (VVC) specification. To improve coding efficiency, a history-based Rice parameter derivation is used. In this history-based Rice parameter derivation, the Rice parameters of the transform units (TUs) in the current coding tree unit (CTU) of a partition (e.g., a picture, slice, or tile) are derived based on a history counter (denoted as StatCoeff), which is calculated based on the coefficients in the current CTU and previous TUs in the previous CTU. The replacement variable (denoted as HistValue) is then derived using the history counter to derive the Rice parameters. The history counter can be updated while processing the TU. In some examples, the replacement variable of the TU remains the same even if the history counter has been updated.

[0028] Dependencies between previous and current CTUs in a partition used to calculate historical counters can conflict with, limit, or even prevent the use of parallel processing, leading to unstable or inefficient video coding. Various embodiments described herein address these problems by enabling parallel processing to accelerate video processing through reducing or eliminating dependencies between some CTUs in a partition, or by detecting and avoiding conflicts before they occur. The following non-limiting examples illustrate some embodiments.

[0029] In one embodiment, dependencies between CTUs in different CTU rows are removed when calculating the history counter, thereby eliminating dependency conflicts with parallel processing. For example, the history counter can be reinitialized for each CTU row of a partition. The history counter can be set to its initial value before calculating the Rice parameter of the first CTU in the CTU row. Subsequent history counters can be calculated based on the history counter values ​​of previous TUs in the same CTU row. In this way, in history-based Rice parameter derivation, CTU dependencies are confined to the same CTU row, without interfering with parallel processing in different CTU rows, while still benefiting from the coding gain achieved through history-based Rice parameter derivation. Furthermore, the history-based Rice parameter derivation process is simplified, reducing computational complexity.

[0030] In another embodiment, the dependency between CTUs when calculating the history counter is consistent with the dependency between CTUs in parallel processing. For example, parallel encoding can be implemented in partitioned CTU rows, and there can be an N-CTU delay between two consecutive CTU rows. That is, processing of a CTU row begins after processing N CTUs in the previous CTU row. In this scenario, the history counter for the CTU row can be calculated based on samples from the first N or fewer CTUs in the previous CTU row. This can be achieved through a storage synchronization process. After processing the last TU in the first CTU of the CTU row, the history counter can be stored in a storage variable. Then, before processing the first TU in the first CTU of the subsequent CTU row, the history counter can be synchronized with the stored value in the storage variable.

[0031] In some examples, an alternative history-based Rice parameter derivation is used. In this alternative history-based Rice parameter derivation, the replacement variable HistValue is updated once the history counter StatCoeff is updated while processing a TU. To avoid dependency conflicts with parallel encoding, the dependency between CTUs when computing the history counter can be similarly limited to no more than N CTUs. Similarly, a storage synchronization process can be implemented. After processing the last TU in the first CTU of a CTU row, the history counter and replacement variable can each be stored in a storage variable. Then, before processing the first TU in the first CTU of a subsequent CTU row, the history counter and replacement variable can be synchronized with the stored values ​​in the corresponding storage variables.

[0032] In this way, the dependency between CTUs in two consecutive CTU rows when calculating the history counter is limited to no greater than the dependency between CTUs when performing parallel encoding (i.e., aligned with the dependency between CTUs when performing parallel encoding). Therefore, the history counter calculation does not interfere with parallel processing, while still benefiting from the coding gain derived through the history-based Rice parameter derivation.

[0033] Alternatively, parallel processing and history-based Ricean parameter derivation can be prevented from coexisting in the bitstream. For example, the video encoder can determine whether parallel processing is enabled. If parallel processing is enabled, history-based Ricean parameter derivation is disabled; otherwise, history-based Ricean parameter derivation is enabled. Similarly, if the video encoder determines that history-based Ricean parameter derivation is enabled, parallel processing is disabled, and vice versa.

[0034] Using the Rice parameters determined as discussed above, the video encoder can binarize the prediction residual data (e.g., quantized transform coefficients of residuals) into a binary bin, and further compress the bin into bits to be included in the video bitstream using an entropy coding algorithm. On the decoder side, the decoder can inversely decode the bitstream into a binary bin, determining the Rice parameters using any of the methods or combinations described above, and then determining the coefficients based on the binary bin. The coefficients can then be further dequantized and inversely transformed to reconstruct the video blocks used for display.

[0035] In some embodiments, the bit depth of the video samples (e.g., the bit depth used to determine the initial value of the history counter StatCoeff) can be determined based on the Sequence Parameter Set (SPS) syntax element sps_bitdepth_minus8. The value of the SPS syntax element sps_bitdepth_minus8 is in the range of 0 to 8. Similarly, the size of the Decoded Picture Buffer (DPB) used to store the decoded pictures can be determined based on the Video Parameter Set (VPS) syntax element vps_ols_dpb_bitdepth_minus8. The value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in the range of 0 to 8. Based on the determined DPB size, storage space can be allocated for the DPB. The determined bit depth and DPB can be used throughout the process of decoding the video bitstream into pictures.

[0036] As described herein, some embodiments provide improvements in video coding and computational efficiency by coordinating history-based Ricean parameter derivation with parallel coding. This avoids conflicts between history-based Ricean parameter derivation and parallel coding, thereby improving the stability of the coding process. Furthermore, coding gains can still be achieved through history-based Ricean parameter derivation without sacrificing computational efficiency by limiting the dependencies between CTUs in history-based Ricean parameter derivation to no greater than those in parallel coding. These techniques can serve as effective coding tools in future video coding standards.

[0037] Now refer to the attached diagram, Figure 1 This is a block diagram illustrating an example of a video encoder 100 configured to implement 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, an in-loop filter module 120, an intra-prediction module 126, an inter-prediction module 124, a motion estimation module 122, a decoded picture buffer 130, and an entropy coding module 116.

[0038] The input to the video encoder 100 is an input video 102 containing a sequence of pictures (also referred to as 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, each block containing multiple pixels. A block can be a macroblock, a coding tree unit, a coding unit, a prediction unit, and / or a prediction block. A single 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 (e.g., intra-frame prediction, inter-frame prediction, or a mixture of intra-frame and inter-frame prediction).

[0039] Typically, the first frame of a video signal is an intra-predicted frame, which is encoded using only intra-prediction. In intra-prediction mode, blocks of the frame are predicted using only data from the same frame. Intra-predicted frames can be decoded even without information from other frames. To perform intra-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 called residual block 106.

[0040] To further remove redundancy from the block, transform module 114 transforms the residual block 106 into the transform domain by applying a transform to the samples in the block. Examples of transforms may include, but are not limited to, the Discrete Cosine Transform (DCT) or the Discrete Sine Transform (DST). The transformed values ​​are called transform coefficients, which represent the residual block in the transform domain. In some examples, the residual block can be directly quantized without transformation by transform module 114. This is called transform skip mode.

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

[0042] Quantization of coefficients / samples within a block can be performed independently; 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 quantization 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 preceding the current coefficient in the encoding / decoding scan order. This quantization method is called dependent quantization.

[0043] 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.

[0044] The quantized samples are then encoded by entropy coding module 116 to further reduce the size of the video signal. Entropy coding module 116 is configured 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 Ricean (TR) and finite k-order exponential Columbus (EGk) binarization. To improve coding efficiency, a history-based Ricean parameter derivation method is used, where the Ricean parameters derived for the transform unit (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), probabilistic interval segmented entropy (PIPE) coding, or other entropy coding techniques. The entropy-coded data is added to the bitstream of the output encoded video 132.

[0045] As discussed above, reconstructed blocks 136 from neighboring blocks are used in intra-frame prediction of blocks in an image. Generating reconstructed blocks 136 involves calculating the reconstruction residuals of that block. The reconstruction residuals can be determined by applying inverse quantization and inverse transform to the quantization residuals of the blocks. Inverse quantization module 118 is configured to apply inverse quantization to quantized samples to obtain dequantization coefficients. Inverse quantization module 118 applies the inverse scheme 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 the dequantized samples, such as inverse DCT or inverse DST. The output of inverse transform module 119 is the reconstruction residual of the block in the pixel domain. The reconstruction residuals can be added to the prediction block 134 of the block to obtain reconstructed blocks 136 in the pixel domain. For blocks that have skipped the transform, inverse transform module 119 is not applied to those blocks. The dequantized samples are the reconstruction residuals of the blocks.

[0046] Inter-frame prediction or intra-frame prediction can be used to encode blocks in subsequent images following the first intra-frame predicted image. In inter-frame prediction, the prediction of blocks 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 blocks based on motion estimates provided by the motion estimation module 122.

[0047] The motion estimation module 122 compares the current block 104 of the current image with the decoded reference image 108 to perform 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 blocks in multiple decoded reference images 108. Therefore, multiple motion vectors are generated and provided to the inter-frame prediction module 124.

[0048] Inter-frame prediction module 124 uses 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 motion vectors, inter-frame 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 for the current block.

[0049] For an inter-frame prediction block, the video encoder 100 can subtract the inter-frame 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 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 and inverse transforming the residual, and then combining it with the corresponding prediction block 134.

[0050] To obtain the decoded image 108 for motion estimation, the reconstructed block 136 is processed by the loop filter module 120. The loop filter module 120 is configured to smooth pixel transitions, thereby improving video quality. The loop filter module 120 can be configured 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), etc.

[0051] Figure 2 An example of a video decoder 200 configured to implement the embodiments presented herein is described. 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-frame prediction module 226, an inter-frame prediction module 224, and a decoded image buffer 230.

[0052] Entropy decoding module 216 is configured to perform entropy decoding of encoded video 202. Entropy decoding module 216 decodes quantization coefficients, encoding 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 encoded video 202 into a binary representation, and then converts the binary representation into quantization levels of coefficients. Then, the entropy-decoded coefficients are inversely quantized by inverse quantization module 218, and subsequently inversely 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 in the reference above. Figure 1 The inverse quantization module 118 and inverse transform module 119 are described. The residual block from the inverse transform can be added to the corresponding prediction block 234 to generate the reconstruction block 236. For blocks where the transform has been skipped, 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 reconstruction block 236.

[0053] The prediction block 234 for a specific block is generated based on the block's prediction mode. If the block's coding parameters indicate intra-frame prediction for the block, the reconstructed block 236 of the reference block in the same image can be fed into the intra-frame prediction module 226 to generate the block's prediction block 234. If the block's coding parameters indicate inter-frame prediction for the block, 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.

[0054] As mentioned above, regarding Figure 1 The inter-frame prediction discussed involves one or more reference images. The video decoder 200 generates a decoded image 208 of the reference images by applying a 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.

[0055] Now for reference Figure 3 , Figure 3 Examples of coding tree unit partitioning of images in a video according to some embodiments of the present disclosure are described. As described above regarding... Figure 1 and Figure 2 The discussion focuses on dividing images into blocks for encoding video, such as the CTU (Coding Tree Unit) 302 in VVC. Figure 3 As shown. For example, CTU 302 can be a block of 128×128 pixels. In a certain order (e.g.) Figure 3 The CTU is processed in the order shown. In some examples, such as... Figure 4As shown, each CTU 302 in the image can be divided into one or more CUs (coding units) 402, and each CU 402 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 CUs 402 in different ways. For example, in VVC, the CUs 402 can be rectangular or square, and can be coded without further division into prediction units or transform units. Each CU 402 can be the same size as its root CTU 302, or it can be a subdivision of the root CTU 302, as small as a 4×4 block. Figure 4 As shown, in VVC, CTU 302 can be partitioned into CU 402, which can be done using a quadtree, a binary tree, or a ternary tree. Figure 4 In the diagram, solid lines indicate quadtree partitioning, while dashed lines indicate binary or ternary tree partitioning.

[0056] As mentioned above, regarding Figure 1 and Figure 2 The quantization discussed here is used to reduce the dynamic range of elements in a block of video signal, allowing the video signal to be represented using fewer bits. In some examples, before quantization, the element located at a specific position 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 followed by rounding, while inverse quantization involves multiplying by the quantization step size. This quantization process is also called scalar quantization. The quantization of coefficients within a block can be performed independently; this independent quantization method is used in some existing video compression standards (such as H.264, HEVC, etc.). In other examples, such as VVC, dependent quantization is used.

[0057] For an N×M block, the 2-D coefficients of the block can be converted into a 1-D array using a specific scan order for coefficient quantization and encoding, and the same scan order is used for encoding and decoding. Figure 5 An example of a coding block (e.g., a transform unit (TU)) is shown, where the coefficients of the coding block are processed using a predetermined scan order. In this example, the coding block 500 is 8×8 in size, and the processing begins at the lower right corner at position L0 and extends to the upper left corner L. 63 End at this point. If block 500 is a transform block, then Figure 5 The predetermined order shown starts from the highest frequency and proceeds to the lowest frequency. In some examples, the processing of a block (e.g., quantization and binarization) begins with the first non-zero element of the block according to a predetermined scan order. For example, if positions L0 to L... 17 The coefficients at L are all zero and L 18 If the coefficient at point L is not zero, then the processing starts from L. 18 Starting with the coefficients at the specified location, and following the scanning order for L... 18This process is performed on each subsequent coefficient.

[0058] Residual Coding In video coding, residual coding is used to convert quantization levels into a bitstream. After quantization, for an N×M transform unit (TU) coded block, there are N×M quantization levels. These N×M levels can be zero or non-zero values. If a level is not in binary form, the non-zero level is further binarized into a binary bin. Context-Adaptive Binary Arithmetic Coding (CABAC) can further compress the bin 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 the context coding method, and bins encoded in this way are called context-coded bins. Conversely, the other method assumes that the probability of 1 or 0 is always 50%, and therefore always uses a fixed context model without adaptation. This method is called the bypass method, and bins encoded using this method are called bypass bins.

[0059] For a 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 (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 exist, they are encoded using a bypass method. An RRC block can consist of several predefined sub-blocks. The syntax element `sb_coded_flag` indicates whether all levels of the current sub-block are 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 are zero. However, based on the encoding scan order from `last_sig_coeff_x` and `last_sig_coeff_y`, it is deduced that the `sb_coded_flag` of the last non-zero sub-block with the last non-zero level is 1 and is not encoded into the bitstream. Furthermore, it is deduced that the `sb_coded_flag` of the top-left sub-block containing the DC position is 1 and is not encoded into the bitstream. The syntax elements of `sb_coded_flag` in the bitstream are encoded using a context encoding method. RRC will start from the last non-zero sub-block, as described above for... Figure 5 The reverse encoding scan sequence discussed encodes each sub-block sequentially.

[0060] To guarantee worst-case throughput, a predefined value `remBinsPassl` is used to limit the maximum number of context encoding bins. Within a sub-block, RRC encodes the level at each position using the reverse encoding scan order. If `remBinsPassl` 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. If the level is not zero, `abs_level_gtx_flag[n][0]` is encoded to indicate whether the absolute level is 1 or greater than 1, where n is the index of the current position within the sub-block along the scan order. If the absolute level is greater than 1, `par_level_flag` is encoded to indicate whether the level is odd or even in the VVC, and then `abs_level_gtx_flag[n][l]` is present. The flags `par_level_flag` and `abs_level_gtx_flag[n][l]` are also used together to indicate that the level is 2, 3, or greater than 3. After each of the above syntax elements is encoded into a context-encoded bin, the value of remBinsPassl is decremented by 1.

[0061] If the absolute level is greater than 3 or the value of `remBinsPassl` is not greater than 4, then after encoding the aforementioned bin using the context encoding method, the other two syntax elements `abs_remainder` and `dec_abs_level` can be encoded into bypass-encoded bins for use with the remaining levels. Furthermore, the symbols for each level within the block will be encoded to represent the quantization level, and the symbols for each level within the block will also be encoded into bypass-encoded bins.

[0062] Another residual coding method uses `abs_level_gtxX_flag` and the remaining levels to allow conditional parsing of syntax elements for level encoding of residual blocks, with the corresponding binarization of the absolute values ​​of the levels 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, the flag `abs_level_gtx(Y+1)` will not exist, where Y is an integer between 0 and N-1. If `abs_level_gtxY_flag` is 1, the flag `abs_level_gtx(Y+1)` will exist. Furthermore, if `abs_level_gtxN_flag` is 0, the remaining levels will not exist. When `abs_level_gtxN_flag` is 1, the remaining levels will exist, representing the value after removing (N+1) from the level. Typically, the abs_level_gtxX_flag is encoded using a context encoding method, while the other levels are encoded using a bypass method.

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

[0064] For blocks encoded using Transform Skip Residual Coding (TSRC), TSRC encodes each sub-block sequentially, starting from the top-left sub-block and proceeding along the coding scan order. Similarly, the syntax element `sb_coded_flag` indicates whether all residuals in the current sub-block are equal to zero. Under certain conditions, all syntax elements of `sb_coded_flag` for all sub-blocks except the last one are encoded into the bitstream. If all `sb_coded_flag` values ​​in all sub-blocks before the last one are not equal to 1, it is deduced that the last sub-block's `sb_coded_flag` is 1, and this flag is not encoded into the bitstream. To guarantee worst-case throughput, a predefined value `RemCcbs` is used to limit the maximum context coding bin. If the current sub-block has a non-zero level, TSRC encodes the level at each position in the coding scan order. If `RemCcbs` is greater than 4, the following syntax elements are 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. 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 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` is encoded. After encoding each of the above syntax elements using the context encoding method, the value of `RemCcbs` is decremented by 1.

[0065] After encoding the aforementioned syntax elements for all positions within the current sub-block, if RemCcbs is still greater than 4, then the context encoding method is used to encode up to four additional abs_level_gtx_flag[n][j], where n is the index of the current position within the sub-block along the scan order; j is from 1 to 4. After encoding each abs_level_gtx_flag[n][j], the value of RemCcbs is decremented by 1. If RemCcbs is not greater than 4, then, if necessary, the bypass method is used to encode the syntax element abs_remainder for the current position within the sub-block. For those positions where the absolute level is encoded entirely using the syntax element abs_remainder via the bypass method, the coeff_sign_flag is also encoded via the bypass method. In summary, a predefined counter remBinsPassl exists in RRC or RemCcbs exists in TSRC to limit the total number of context-encoded bins and ensure worst-case throughput.

[0066] Rice parameter derivation In the current RRC design in VVC, two syntax elements, abs_remainder and dec_abs_level, encoded into the bypass bin can exist in the bitstreams of the remaining levels. Through the combination of the truncated Rice (TR) and finite k-order exponential Golomb (EGk) binarization processes specified in the VVC specification, abs_remainder and dec_abs_level are binarized, which requires the Rice parameter to binarize a given level. To obtain the optimal Rice parameter, a local summation method is adopted as described below.

[0067] The array AbsLevel[xC][yC] represents the array of the absolute values of the transform coefficient levels of the current transform block for the color component index cIdx. Given the array AbsLevel[x][y] of a transform block with color component index cIdx and top-left luminance position (x0, y0), the local summation variable locSumAbs is derived in the manner specified by the following pseudocode procedure: locSumAbs = 0 If (xC < (1 << log2TbWidth) - 1), then { locSumAbs += AbsLevel[xC + 1][yC] If (xC < (1 << log2TbWidth) - 2), then locSumAbs += AbsLevel[xC + 2][yC] If (yC < (1 << log2TbHeight) - 1), then locSumAbs += AbsLevel[xC + 1][yC + 1] } If (yC < (1 << log2TbHeight) - 1), then { locSumAbs += AbsLevel[xC][yC + 1] If (yC < (1 << log2TbHeight) - 2), then locSumAbs += AbsLevel[xC][yC + 2] } locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) 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 summation variable locSumAbs, the Rice parameter cRiceParam is derived as specified in Table 2.

[0068] Table 2—Specifications of cRiceParam based on locSumAbs

[0069] Rice parameter derivation based on history If the coefficients lie on the boundaries of the TU, or if the Rice method is used for decoding first, the template computation used for Rice parameter derivation can produce inaccurate coefficient estimates. For these coefficients, the template computation is biased towards 0 because some template positions can lie outside the TU and be interpreted or initialized to the value 0. Figure 6 An example template pattern for calculating locSumAbs, the coefficients located near the TU boundary, is shown. Figure 6 A CTU 602 is shown, divided into multiple CUs, each CU comprising 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 neighborhood of the current coefficient used to compute the local summation variable locSumAbs.

[0070] exist Figure 6 In the template pattern, because the current coefficient 606 is close to the boundary of TU 604, some neighboring samples of the current coefficient 606 (e.g., neighboring samples 608B and 608E) are located outside the TU boundary. In the Rice parameter derivation described above, these neighboring samples outside the boundary are set to 0 when calculating the local summation variable locSumAbs, leading to inaccurate Rice parameter derivation. For high-bit-depth samples (e.g., greater than 10 bits), neighboring samples outside the TU boundary can be large numbers. Setting these large numbers to 0 will introduce more error into the Rice parameter derivation.

[0071] To improve the accuracy of Rice estimation according to the calculation template, it is recommended that for template positions outside the current TU, historical derived values be used to update the local summation variable locSumAbs instead of initializing it with 0. The implementation of this method is illustrated below by the VVC specification text excerpted from Clause 9.3.3.2, where the recommended text is underlined.

[0072] To maintain the history of adjacent coefficient / sample values, the historical counter StatCoeff[cIdx] for each color component is utilized, where cIdx = 0, 1, 2, representing the three color components Y, U, V respectively. If the CTU is the first CTU in a partition (such as a picture, slice, or tile), then StatCoeff[cIdx] is initialized as follows: StatCoeff[idx] = 2 * Floor(Log2( BitDepth - 10) (1) Here, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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 TU decoding and historical counter update, the replacement variable HistValue is initialized as: HistValue[cIdx] = 1<<StatCoeff[cIdx] (2) The replacement variable HistValue is used for the estimation of adjacent samples outside the TU boundary (e.g., adjacent samples have horizontal or vertical coordinates outside the TU). The local summation variable locSumAbs is re-derived in the manner specified by the following pseudocode, where the changes are underlined: locSumAbs = 0 If (xC < (1<<log2TbWidth) - 1), then { locSumAbs += AbsLevel[ xC + 1 ][ yC ] If (xC < (1<<log2TbWidth) - 2), then locSumAbs += AbsLevel[ xC + 2 ][ yC ] otherwise locSumAbs += HistValue If (yC < (1<<log2TbHeight) - 1), then locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] otherwise locSumAbs += HistValue } otherwise locSumAbs += 2 * HistValue If (yC < (1 << log2TbHeight) - 1), then { locSumAbs += AbsLevel[xC][yC + 1] If (yC < (1 << log2TbHeight) - 2), then locSumAbs += AbsLevel[xC][yC + 2] otherwise locSumAbs += HistValue } otherwise locSumAbs += HistValue For each TU, the historical counter StatCoeff is updated once from the first non - zero Golomb - Rice coded transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]) through an exponential moving average process. When the first non - zero Golomb - Rice coded transform coefficient in the TU is coded as abs_remainder, the historical counter StatCoeff for 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 the TU is coded as dec_abs_level, the historical counter StatCoeff for color component cIdx is updated as follows: StatCoeff[cIdx] = (StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1 (4) The updated StatCoeff can be used to calculate the replacement variable HistValue for the next TU according to Equation (2) before decoding the next TU.

[0073] Wavefront parallel processing (WPP) WPP is designed to provide a parallel coding mechanism. When WPP is enabled in VVC, each CTU line of a frame, tile, or slice constitutes a separate partition. WPP is enabled / disabled via the SPS element `sps_entropy_coding_sync_enabled_flag`. Figure 7 An example of a tile is shown, where WPP is enabled for that tile. Figure 7 In this approach, each CTU line of a tile is processed with a one-CTU delay relative to its preceding CTU line. This ensures that if palette coding is enabled at the end of each CTU line, dependencies between consecutive CTU lines are not broken at partition boundaries, except for the CABAC context variables and the palette predictor. To mitigate potential losses in coding efficiency, the contents of the adaptive CABAC context variables and the palette predictor are propagated from the first coded CTU of the previous CTU line to the first CTU of the current CTU line. WPP does not alter the regular raster scan order of the CTUs.

[0074] When WPP is enabled, multiple threads (up to the number of CTU lines in a partition, such as a tile, slice, or frame) can work in parallel to process individual CTU lines. By using WPP in the decoder, each decoding thread processes a single CTU line of the partition. The scheduling of thread processing must be organized so that for each CTU, the decoding of the top-adjacent CTU in its preceding CTU line must have been completed. The small additional overhead of WPP allows all CABAC context variables and the contents of the palette predictor to be stored after encoding the first CTU in each CTU line (except the last one) is complete.

[0075] When enabling the history-based Rice parameter derivation discussed above for high-bit-depth and high-bit-rate video coding, the last StatCoeff in the previous CTU line will be passed to the first TU in the current CTU line. Therefore, this process interferes with WPP and breaks its parallelism when WPP is enabled simultaneously. This disclosure proposes several solutions to address this problem when parallel coding (e.g., WPP) is enabled.

[0076] In one embodiment, the dependency between CTUs in different CTU rows when calculating the history counter StatCoeff is removed, thereby eliminating interference from history-based Rice parameter derivation on parallel encoding. In this embodiment, instead of using the history counter StatCoeff value obtained from the previous CTU row, the initial value of StatCoeff[cIdx] is used to encode the first abs_remainder[cIdx] or dec_abs_level[cIdx] in each CTU row of a partition (e.g., a frame, tile, or slice), where cIdx is the index of the color component.

[0077] As an example, the initial value of StatCoeff[cIdx] can be determined as follows: StatCoeff[idx] = 2 * Floor(Log2(BitDepth - 10)) (5) Here, BitDepth specifies the bit depth of the samples in the luminance or chrominance array, and Floor(x) represents the largest integer less than or equal to x. As another example, the initial value of StatCoeff[cIdx] can be determined as: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l (6) Here, MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: (7) Before encoding the first TU of each CTU row for a partition (e.g., frame, tile, or slice), the substitution variable HistValue is calculated as follows: HistValue[cIdx] = 1< <StatCoeff[cIdx] (8) HistValue can be used to compute the local summation variable locSumAbs as described above. For each TU, HistValue is updated once via an exponential moving average process from the first non-zero Columbus-Rice encoded transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]). When the first non-zero Columbus-Rice encoded transform coefficient in the TU is encoded as abs_remainder, the history counter StatCoeff[cIdx] of the color component cIdx is updated as follows: StatCoeff[cIdx] = (StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1 (9) When the first non-zero Columbus-Rice coded transform coefficient in the TU is encoded as dec_abs_level, the history counter StatCoeff[cIdx] of the color component cIdx is updated as follows: StatCoeff[cIdx] = (StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1 (10) The updated StatCoeff[cIdx] is used to calculate the replacement variable HistValue for the next TU of the current CTU or the first TU of the next CTU in the current CTU row, as shown in equation (8).

[0078] Figure 8 The diagram shows frame 802 and an example of the CTUs contained within it. In this example, frame 802 contains two tiles: tile 804A and tile 804B. Tile 804A contains four CTU rows: CTU row 1 through CTU row 4. The first CTU row includes CTUs 0 through 9, the second CTU row includes CTUs 10 through 19, and so on. Similarly, block 804B also contains four CTU rows: CTU rows 1' through 4'. The first CTU row includes 10 CTUs: CTUs 0' through 9', the second CTU row includes CTUs 10' through 19', and so on.

[0079] According to this embodiment, the initial value of StatCoeff[cIdx] for tile 804A can be determined according to equation (5) or (6). Before encoding the first TU of each CTU row from CTU row 1 to CTU row 4, the replacement variable HistValue[cIdx] is calculated using the initial value of StatCoeff[cIdx] with equation (8). For example, before encoding the first TU of CTU 0, the variable HistValue is calculated using equation (8). This value of HistValue is used to determine the local summation variable locSumAbs of the coefficients in the first TU, and the local summation variable locSumAbs is further used to determine the Rice parameter of each coefficient of the first TU. When processing the first TU of the current CTU 0, the history counter StatCoeff can be updated according to equation (9) or (10). Before processing the second TU in CTU 0, the current value of StatCoeff is used to determine the HistValue of the second TU according to equation (8). Then, a similar process is applied to the second TU, using HistValue to determine the Rice parameter and update StatCoeff. For the first TU in CTU 1, HistValue is calculated using the latest StatCoeff from the TU in CTU 0 according to equation (8). This process can be repeated until the last CTU in the current CTU row 1 (i.e., CTU 9) is processed.

[0080] For the second CTU row of tile 804A, the history counter StatCoeff is initialized according to equation (5) or (6) before encoding the first TU of CTU 10 (i.e., the first CTU of the second CTU row). For the TUs in the CTUs of the second CTU row, a process similar to that described above for CTU row 1 is performed. Similarly, the variable StatCoeff is initialized again according to equation (5) or (6) before encoding the first TU of each of CTUs 20 and 30.

[0081] Tile 804B can be processed in a similar manner. Before encoding the first TU in each of CTU rows 1' to 4' (i.e., CTU 0', CTU 10', CTU 20', and CTU 30'), the value of StatCoeff[cIdx] is initialized according to equation (5) or (6), and the history counter HistValue is calculated using equation (8). The calculated history counter HistValue is used to calculate the locSumAbs and Rice parameters of the first CTU and the remaining TUs in each CTU row. In addition, within each TU, the history counter StatCoeff can be updated at most once according to equation (9) or (10), and the updated value of StatCoeff is used to determine the HistValue of the next TU in the same CTU row.

[0082] Although Figure 8 Frame 802 is described as containing two tiles, 804A and 804B, but the same process applies to other scenarios, such as slices containing multiple tiles, frames containing multiple slices, etc. In any of these scenarios, the value of the history counter StatCoeff[cIdx] is reset to its initial value before encoding the first TU in each CTU line of a partition (e.g., frame, tile, or slice) to eliminate the dependency on CTU lines in the Rice parameter derivation.

[0083] The possible specification changes for VVC, indicated by underline, are specified below.

[0084]

[0085] Regarding 9.3.2.1, another possible specification change for VVC is specified as follows.

[0086]

[0087] Bit depth of video samples VVC version 2 supports input video bit depths exceeding 10 bits. Higher video bit depths provide higher visual quality to the decoded video with lower compression distortion. To support higher bit depths of input video, the semantics of the corresponding SPS (Sequence Parameter Set) syntax element sps_bitdepth_minus8 and VPS (Video Parameter Set) syntax element vps_ols_dpb_bitdepth_minus8[i] can be modified as follows.

[0088] sps_bitdepth_minus8 specifies the bit depth (BitDepth) of the samples in the luma and chroma arrays, and the value QpBdOffset of the range offset for the luma and chroma quantization parameters, as follows: BitDepth = 8 + sps_bitdepth_minus8 (x1) QpBdOffset = 6 * sps_bitdepth_minus8 (x2) sps_bitdepth_minus8 should be in the range of 0 to 8 (inclusive).

[0089] When sps_video_parameter_set_id is greater than 0 and the SPS is referenced by a layer contained in the i-th multilayer OLS specified by the VPS (for any i, it is in the range of 0 to NumMultiLayerOlss - 1 (inclusive), the requirement for bitstream consistency is that the value of sps_bitdepth_minus8 should be less than or equal to the value of vps_ols_dpb_bitdepth_minus8[i].

[0090] vps_ols_dpb_bitdepth_minus8[i] specifies the maximum allowed value of sps_bitdepth_minus8 for all SPS referenced by the CLVS in the CVS of the i-th multi-level OLS. The value of vps_ols_dpb_bitdepth_minus8[i] should be in the range of 0 to 8 (inclusive).

[0091] Note 2 — In order to decode the i-th multi-layer OLS, the decoder can safely allocate memory to the DPB according to the values ​​of the syntax elements vps_ols_dpb_pic_width[i], vps_ols_dpb_pic_height[i], vps_ols_dpb_chroma_format[i], and vps_ols_dpb_bitdepth_minus8[i].

[0092] As seen above, the bit depth (BitDepth) of the samples in the luminance and chrominance arrays can be derived from equation (x1) based on the SPS syntax element sps_bitdepth_minus8. Using the determined BitDepth value, the history counter StatCoeff, the substitution variable HistValue, and the Rice parameter can be derived as discussed above.

[0093] The VPS syntax element `vps_ols_dpb_bitdepth_minus8[i]` can be used to deduce the size of the Decoded Picture Buffer (DPB). For the encoded bitstream, multiple video layers can exist. The video parameter set is used to specify the corresponding syntax element. For video decoding, the DPB can be used to store reference pictures, allowing previously encoded pictures to be used to generate prediction signals for use when encoding other pictures. The DPB can also be used to reorder decoded pictures so that they can be output and / or displayed in the correct order. The DPB can also be used to specify the output delay for the hypothetical reference decoder. Decoded pictures can be continuously stored in the DPB for a predetermined time period specified for the hypothetical reference decoder and output after the predetermined time period has elapsed.

[0094] To safely allocate memory to the DPB, the size of the DPB is determined by the syntax elements vps_ols_dpb_pic_width[i], vps_ols_dpb_pic_height[i], vps_ols_dpb_chroma_format[i], and vps_ols_dpb_bitdepth_minus8[i] as follows.

[0095] picture_size1 (in bits) = vps_ols_dpb_pic_width[i] * vps_ols_dpb_pic_height[i] * (vps_ols_dpb_bitdepth_minus8[i] + 8) If (vps_ols_dpb_chroma_format[i] == 0) / / monochrome, then picture_size = picture_size1; Otherwise, if (vps_ols_dpb_chroma_format[i] == 1) / / 4:2:0, then picture_size = 1.5 * picture_size1; Otherwise, if (vps_ols_dpb_chroma_format[i] == 2 / / 4:2:2, then picture_size = 2 * picture_size1; Otherwise, if (vps_ols_dpb_chroma_format[i] == 3 / / 4:4:4, then picture_size = 3 * picture_size1; Therefore, the size of the DPB will be determined by `picture_size`. In other words, the size of the DPB can be determined based on the chroma format of the samples. If the video frame is a monochrome frame, the size of the frame to be buffered is determined to be the basic picture size `picture_size1`. If the color subsamples of the color video frame are 4:2:0, the frame size is determined to be 1.5 times the basic picture size `picture_size1`; if the color subsamples of the color video frame are 4:2:2, the frame size is determined to be twice the basic picture size `picture_size1`; if the color subsamples of the color video frame are 4:4:4, the frame size is determined to be three times the basic picture size `picture_size1`. Based on the color subsamples, the size of the DPB can be determined as the number of frames to be stored in the DPB multiplied by the frame size.

[0096] Figure 9 Examples of a process 900 for encoding video partitions according to some embodiments of the present disclosure are 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 9 The operations described in the figure are illustrated below. For illustrative purposes, some examples are shown in the figure to describe process 900. However, other implementations are possible.

[0097] At box 902, process 900 includes accessing partitions of the video signal. A partition can be a video frame, slice, or tile, or any type of partition processed as a unit by the video encoder during encoding. Partitions include, for example... Figure 8 The CTUs shown are arranged in rows. Each CTU includes one or more other CTUs, and each CTU includes multiple TUs for encoding, such as... Figure 6 As shown in the example.

[0098] At box 904, procedure 900 involves processing each CTU in the set of CTUs in the partition to encode the partition into bits; box 904 includes 906 through 914. At box 906, procedure 900 involves determining whether a parallel encoding mechanism is enabled and whether the current CTU is the first CTU in the CTU row. In some examples, parallel encoding may be indicated by a flag with a value of 0 indicating that parallel encoding is disabled and a value of 1 indicating that parallel encoding is enabled. If it is determined that a parallel encoding mechanism is enabled and the current CTU is the first CTU in the CTU row, then procedure 900 involves setting the history counter StatCoeff to an initial value at box 908. As discussed above, if history-based Rice parameter derivation is enabled, the initial value of the history counter may be set according to equation (5) or (6); otherwise, the initial value of the history counter is set to zero.

[0099] If it is determined that parallel coding is not enabled, or the current CTU is not the first CTU in the CTU row, or after setting the history counter at box 908, process 900 involves calculating the Rice parameter of the TU in the CTU based on the history counter at box 910. (See above for reference.) Figures 6 to 8 The detailed description states that if the history counter is reset at box 908, the Rice parameter of the TU in the CTU is calculated based on the reset history counter or the subsequently updated history counter. If the history counter is not reset at box 908, the Rice parameter of the TU in the CTU is calculated based on the history counter updated in the previous CTU or the subsequently updated history counter in the current CTU.

[0100] At box 912, procedure 900 involves encoding the TU in the CTU into a binary representation based on the calculated Rice parameter, for example, by encoding a combination of a truncated Rice (TR) and a finite k-order EGk as specified in the VVC specification. At box 914, procedure 900 involves encoding the binary representation of the CTU into bits to be included in the video bitstream. For example, the encoding can be performed using Context Adaptive Binary Arithmetic Coding (CABAC) discussed above. At box 916, procedure 900 involves outputting the encoded video bitstream.

[0101] Figure 10 Examples of a process 1000 for decoding video partitions according to some embodiments of the present disclosure are described. One or more computing devices implement this by executing suitable program code. Figure 10 The operations described herein. For example, a computing device implementing the video decoder 200 can be implemented by executing program code for the entropy decoding module 216, the inverse quantization module 218, and the inverse transform module 219. Figure 10 The operations described in the figure are illustrated below. For illustrative purposes, some examples are shown in the figure to describe process 1000. However, other implementations are possible.

[0102] At box 1002, process 1000 involves accessing a binary string or binary representation of a partition representing a video signal. A partition can be a video frame, slice, or tile, or any type of partition processed as a unit by the video encoder during encoding. Partitions include, for example,... Figure 8 The CTUs shown are arranged in rows. Each CTU includes one or more other CTUs, and each CTU includes multiple TUs for encoding, such as... Figure 6 As shown in the example.

[0103] At box 1004, procedure 1000 involves processing the binary string of each CTU in the set of CTUs in the partition to generate a decoded sample for the partition. Box 1004 includes 1006 to 1014. At box 1006, procedure 1000 involves determining whether parallel coding is enabled and whether the current CTU is the first CTU in the CTU row. Parallel coding can be indicated by a flag, where a value of 0 indicates that parallel coding is disabled and a value of 1 indicates that parallel coding is enabled. If it is determined that parallel coding is enabled and the current CTU is the first CTU in the CTU row, then procedure 1000 involves setting the history counter StatCoeff to its initial value at box 1008. As discussed above, if history-based Rice parameter derivation is enabled, the initial value of the history counter can be set according to equation (5) or (6); otherwise, the initial value of the history counter is set to zero.

[0104] If it is determined that parallel coding is not enabled, or the current CTU is not the first CTU in the CTU row, or after setting the history counter at box 1008, process 1000 involves calculating the Rice parameter of the TU in the CTU based on the history counter at box 1010. (See above for reference.) Figures 6 to 8 In detail, if the history counter is reset at box 1008, the Rice parameter of the TU in the CTU is calculated based on the reset history counter or the subsequently updated history counter. If the history counter is not reset at box 1008, the Rice parameter of the TU in the CTU is calculated based on the history counter updated in the previous CTU or the subsequently updated history counter in the current CTU.

[0105] At box 1012, procedure 1000 involves decoding the binary string or binary representation of the TU in the CTU into coefficient values ​​based on the calculated Rice parameters, for example by decoding using a combination of truncated Rice (TR) and finite k-order EGK as specified in the VVC specification. At box 1014, procedure 1000 involves reconstructing the pixel values ​​of the TU in the CTU, for example by decoding using the parameters described above for... Figure 2 The inverse quantization and inverse transform discussed are used for reconstruction. At box 1016, process 1000 involves the decoding partitioning of the output video.

[0106] In another embodiment, the dependencies between CTUs when calculating the history counter StatCoeff are aligned with the dependencies between CTUs in a parallel coding mechanism (e.g., WPP). For example, the history counter StatCoeff of a partition (e.g., frame, tile, or slice) can be calculated based on coefficient values ​​in the first N or fewer CTUs in the previous CTU row, where N is the maximum latency allowed between two consecutive CTU rows in a parallel coding mechanism. Thus, the dependencies between CTUs in two consecutive CTU rows when calculating the history counter StatCoeff are limited to no greater than the dependencies between CTUs when performing parallel processing (and therefore aligned with the dependencies between CTUs when performing parallel processing).

[0107] This embodiment can be implemented using a storage synchronization procedure. For example, in the WPP described above, the delay between two consecutive CTU rows is 1 CTU, so N=1. During the storage procedure, after encoding the last TU of the first CTU in each CTU row (except the last CTU row), StatCoeff[cIdx] can be stored in the storage variable StatCoeffWpp[cIdx]. For each CTU row except the first CTU row, a synchronization procedure derived from the Rice parameter is applied before encoding the first TU. During the synchronization procedure, StatCoeff[cIdx] is synchronized with StatCoeffWpp[cIdx] stored from the previous CTU row.

[0108] As discussed above, before encoding the first TU in each CTU row, the variable HistValue is calculated as follows: HistValue[cIdx] = 1< <StatCoeff[cIdx] (11) If the current CTU row is the first CTU row of the partition, then StatCoeff[cIdx] can be initialized according to equation (5) or (6). The calculated HistValue can be used to determine the local summation variable locSumAbs, which in turn is used to determine the Rice parameter of the TU in the current CTU. For each TU, StatCoeff is updated once by an exponential moving average process from the first non-zero Columbus-Rice encoded transform coefficients (abs_remainder[cIdx] or dec_abs_level[cIdx]), as described above for equations (9) and (10).

[0109] After encoding the last TU of the first CTU in the first CTU row, StatCoeff[cIdx] can be saved as StatCoeffWpp[cIdx] in the storage step, as follows: StatCoeffWpp[cIdx] = StatCoeff[cIdx] (12) The encoding of the remaining CTUs in the first CTU row can be performed in a manner similar to that described above for the first embodiment.

[0110] StatCoeff[cIdx] is obtained via a synchronization step before encoding the first TU in the second CTU row and any subsequent CTU rows: StatCoeff[cIdx] = StatCoeffWpp[cIdx] (13) Using the obtained StatCoeff[cIdx] value, calculate HistValue according to equation (11). The rest of the procedure for the CTU line is the same as that for the first CTU line.

[0111] The possible changes to the VVC specification are specified below (the changes are indicated by underline).

[0112]

[0113] Alternative history-based Rice parameter derivation The history-based Rice parameter derivation can be implemented in an alternative way. In this alternative implementation, if the CTU is the first CTU in the partition (e.g., image, tile, or tile), the HistValue is initialized with the initial value of StatCoeff[cIdx] as follows: HistValue=sps_persistent_Rice_adaptation_enabled_flag?1< <StatCoeff[cIdx]:0(14) The initial HistValue is used to encode the first abs_remainder[cIdx] or dec_abs_level[cIdx] until the HistValue is updated according to the following rules. When the first non-zero Columbus-Rice coded transform coefficient in the TU is encoded as abs_remainder, the history counter of the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1(15) When the first non-zero Columbus-Rice coded transform coefficient in the TU is encoded as dec_abs_level, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1(16) Once the history counter StatCoeff[cIdx] has been updated, HistValue will be updated as shown in equation (17). The updated HistValue will be used to deduce the Rice parameters of the remaining syntax elements abs_remainder and dec_abs_level until a new StatCoeff[cIdx] and HistValue[cIdx] are updated again.

[0114] HistValue[cIdx] = 1< <StatCoeff[cIdx] (17) Based on the current VVC specification, the possible specification changes are specified below.

[0115] Clause 7.3.11.11 (Residual Coding Syntax) is amended as follows (the added content is underlined):

[0116] To resolve the dependency conflict between parallel encoding and the alternative history-based Rice parameter derivation, StatCoeff[cIdx] and HistValue[cIdx] for each color component are saved after encoding the last TU of the first CTU in each CTU row. The saved values ​​of StatCoeff[cIdx] and HistValue[cIdx] can be used to initialize StatCoeff[cIdx] and HistValue[cIdx] before processing the first TU of the first CTU in subsequent CTU rows.

[0117] This embodiment can also be implemented using a storage synchronization procedure. For example, in the storage procedure, after processing the last TU of the first CTU in each CTU row, StatCoeff[cIdx] and HistValue[cIdx] can be stored in storage variables, such as StatCoeffWpp[cIdx] and HistValueWpp[cIdx] as shown in equations (18) and (19), respectively. StatCoeffWpp[cIdx] = StatCoeff[cIdx] (18) HistValueWpp[cIdx] = HistValue[cIdx] (19) For each CTU row except the first CTU row, a synchronization process derived from the Rice parameter is applied before encoding the first TU. For example, StatCoeff[cIdx] and HistValue[cIdx] are synchronized with StatCoeffWpp[cIdx] and HistValueWpp[cIdx] saved from the previous CTU row, as shown in equations (20) and (21).

[0118] StatCoeff[cIdx] = StatCoeffWpp[cIdx] (20) HistValue[cIdx] = HistValueWpp[cIdx] (21) The synchronization variable HistValue is used to encode the first abs_remainder[cIdx] or dec_abs_level[cIdx] until HistValue is updated.

[0119] As discussed above, for each TU, StatCoeff[cIdx] can be updated once from the first non-zero Columbus-Rice code transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]), as shown in equation (15) or (16). Once the history counter StatCoeff[cIdx] has been updated, HistValue will be updated according to equation (17), and the updated HistValue will be used to derive the Rice parameters of the remaining syntax elements abs_remainder and dec_abs_level until a new StatCoeff[cIdx] and HistValue are updated again.

[0120] Based on the current VVC specification, the possible specification changes indicated by the underline are specified below.

[0121]

[0122]

[0123] Figure 11 Examples of a process 1100 for encoding video partitions according to some embodiments of the present disclosure are 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 11The operations described herein. For illustrative purposes, process 1100 is described with reference to some examples depicted in the figures. However, other implementations are possible.

[0124] At box 1102, process 1100 includes accessing partitions of the video signal. A partition can be a video frame, slice, or tile, or any type of partition processed as a unit by the video encoder during encoding. Partitions include, for example... Figure 8 The CTUs shown are arranged in rows. Each CTU includes one or more other CTUs, and each CTU includes multiple TUs for encoding, such as... Figure 6 As shown in the example.

[0125] At box 1104, procedure 1100 involves processing each CTU in the set of CTUs in the partition to encode the partition into bits; box 1104 includes 1106 through 1118. At box 1106, procedure 1100 involves determining whether parallel encoding is enabled and whether the current CTU is the first CTU in the CTU row. In some examples, parallel encoding may be indicated by a flag with a value of 0 indicating that parallel encoding is disabled and a value of 1 indicating that parallel encoding is enabled. If it is determined that parallel encoding is enabled and the current CTU is the first CTU in the CTU row, then procedure 1100 involves, at box 1107, determining whether the current CTU row is the first CTU row in the partition. If so, then procedure 1100 involves, at box 1108, setting the history counter StatCoeff to its initial value. As discussed above, the initial value of the history counter can be set according to equation (5) or (6). If the current CTU row is not the first CTU row in the partition, then procedure 1100 involves setting the history counter StatCoeff to the value stored in the history counter storage variable at box 1109, as shown in equation (13) or (20). In some examples, such as when derived using the alternative Rice parameter, the value of the replacement variable HistValue may also be reset to the stored value, as shown in equation (21).

[0126] If it is determined that parallel encoding is not enabled, or the current CTU is not the first CTU in the CTU row, or after setting the value of the history counter at box 1108 or 1109, process 1100 involves calculating the Rice parameter of the TU in the CTU at box 1110, based on the history counter (and the replacement variable HistValue, if HistValue was reset). As described above (see, for example, reference...). Figure 8(or in the alternative Rice parameter derivation), if the value of the history counter is reset at box 1108 or 1109, the Rice parameter of the TU in the CTU is calculated based on the reset history counter or the subsequently updated history counter. If the history counter is not reset at box 1108 or 1109, the Rice parameter of the TU in the CTU is calculated based on the history counter updated in the previous CTU or the subsequently updated history counter in the current CTU.

[0127] At box 1112, procedure 1100 involves encoding the TU in the CTU into a binary representation based on the calculated Rice parameter, for example by encoding a combination of truncated Rice (TR) and a finite k-order EGK as specified in the VVC specification. At box 1114, procedure 1100 involves 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.

[0128] At box 1116, procedure 1100 involves determining whether parallel encoding is enabled and whether the CTU is the first CTU in the current CTU row. If so, procedure 1100 involves storing the value of the history counter in a history counter storage variable at box 1118, as shown in equation (12) or (18). In some examples, such as when derived using the alternative Rice parameter, the value of the substitution variable HistValue may also be stored in the storage variable, as shown in equation (19). At box 1120, procedure 1100 involves outputting the encoded video bitstream.

[0129] In some scenarios, a CTU in a row other than the first CTU may be located at the boundary of a partition. For example, the first CTU in the second CTU row may not have a CTU in the partition above it. In these scenarios, the history counter for that CTU can be set to an initial value, rather than the stored value. In this case, it is possible to... Figure 11 A new box 1107' is added between boxes 1107 and 1109 to determine whether the CTU is located at the boundary of the partition (e.g., the CTU does not have a top-adjacent CTU within the partition). If yes, process 1100 proceeds to box 1108 to set the history counter to its initial value; otherwise, process 1100 proceeds to box 1109 to set the history counter to its stored value. Figure 11 The remaining boxes can remain unchanged.

[0130] Figure 12 Examples of a process 1200 for decoding video partitions according to some embodiments of the present disclosure are described. One or more computing devices implement this by executing suitable program code. Figure 12The operations described herein. For example, a computing device implementing the video decoder 200 can be implemented by executing program code for the entropy decoding module 216, the inverse quantization module 218, and the inverse transform module 219. Figure 12 The operations described in the figure are illustrated below. For illustrative purposes, some examples are shown in the figure to describe process 1200. However, other implementations are possible.

[0131] At box 1202, process 1200 includes accessing a binary string or binary representation of a partition representing a video signal. The partition can be a video frame, slice, or tile, or any type of partition processed as a unit by the video encoder during encoding. Partitions include, for example... Figure 8 The CTUs shown are arranged in rows. Each CTU includes one or more other CTUs, and each CTU includes multiple TUs for encoding, such as... Figure 6 As shown in the example.

[0132] At box 1204, procedure 1200 involves processing the binary string of each CTU in the CTU set in the partition to generate a decoded sample for the partition. Box 1204 includes 1206 to 1218. At box 1206, procedure 1200 involves determining whether parallel encoding is enabled and whether the current CTU is the first CTU in the CTU row. Parallel encoding can be indicated by a flag, where a value of 0 indicates that parallel encoding is disabled and a value of 1 indicates that parallel encoding is enabled. If it is determined that parallel encoding is enabled and the current CTU is the first CTU in the CTU row, then procedure 1200 involves, at box 1207, determining whether the current CTU row is the first CTU row in the partition. If so, then procedure 1200 involves, at box 1208, setting the history counter StatCoeff to its initial value. As discussed above, the initial value of the history counter can be set according to equation (5) or (6). If the current CTU row is not the first CTU row in the partition, then procedure 1200 involves setting the history counter StatCoeff to the value stored in the history counter storage variable at box 1209, as shown in equation (13) or (20). In some examples, such as when derived using the alternative Rice parameter, the value of the replacement variable HistValue may also be reset to the stored value, as shown in equation (21).

[0133] If it is determined that parallel encoding is not enabled, or the current CTU is not the first CTU in the CTU row, or after setting the history counter at box 1208 or 1209, process 1200 involves calculating the Rice parameter of the TU in the CTU at box 1210 based on the history counter (and the replacement variable HistValue, if HistValue is also set). As described above (see, for example, reference...). Figure 8(or in the alternative Rice parameter derivation), if the value of the history counter is reset at box 1208 or 1209, the Rice parameter of the TU in the CTU is calculated based on the reset history counter or the subsequently updated history counter. If the history counter is not reset at box 1208 or 1209, the Rice parameter of the TU in the CTU is calculated based on the history counter updated in the previous CTU or the subsequently updated history counter in the current CTU.

[0134] At box 1212, procedure 1200 involves decoding the binary string or binary representation of the TU in the CTU into coefficient values ​​based on the calculated Rice parameters, for example, by decoding a combination of truncated Rice (TR) and finite k-order EGK as specified in the VVC specification. At box 1214, procedure 1200 involves reconstructing the pixel values ​​of the TU in the CTU, for example, by decoding the combination of truncated Rice (TR) and finite k-order EGK as specified above. Figure 2 The inverse quantization and inverse transform discussed are used for reconstruction.

[0135] At box 1216, procedure 1200 involves determining whether parallel encoding is enabled and whether the CTU is the first CTU in the current CTU row. If so, procedure 1200 involves storing the value of the history counter in a history counter storage variable at box 1218, as shown in equation (12) or (18). In some examples, such as when derived using the alternative Rice parameter, the value of the substitution variable HistValue may also be stored in the storage variable, as shown in equation (19). At box 1220, procedure 1200 involves decoding the partitions of the output video.

[0136] In another embodiment, WPP or other parallel coding mechanisms are prevented from coexisting with history-based Rice parameter derivation in the bitstream. For example, if WPP is enabled, history-based Rice parameter derivation can be disabled. If WPP is disabled, history-based Rice parameter derivation can be enabled. Similarly, if history-based Rice parameter derivation is enabled, WPP can be disabled. As an example, the syntax can be changed as follows.

[0137] 7.3.2.22 Sequence parameter set range expansion syntax (the added content is underlined)

[0138] As another example, the corresponding semantics are changed as follows (the changes are underlined).

[0139]

[0140] Although in the description above, in the accompanying drawings (e.g.) Figure 6The diagram shows and describes TU, but the same technique can be applied to the transform block (TB). In other words, in the embodiments presented above (including the figures), TU can also represent TB.

[0141] Example of a computational system for implementing dependency quantization in video coding Any suitable computing system can be used to perform the operations described herein. For example, Figure 13 Describes what can be achieved Figure 1 Video encoder 100 or Figure 2 Examples of computing devices 1300 for video decoder 200. In some embodiments, computing device 1300 may include processor 1312, which is communicatively coupled to memory 1314 and executes computer-executable program code and / or accesses information stored in memory 1314. Processor 1312 may include a microprocessor, application-specific integrated circuit (ASIC), state machine, or other processing device. Processor 1312 may include any one of a plurality of processing devices, including a single processing device. Such a processor may include a computer-readable medium storing instructions or be communicative to a computer-readable medium storing instructions that, when executed by processor 1312, cause the processor to perform the operations described herein.

[0142] Memory 1314 may include any suitable non-transitory computer-readable medium. Computer-readable medium 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 memory, magnetic tape or other magnetic memory, 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.

[0143] The computing device 1300 may also include a bus 1316. The bus 1316 may communicatively connect one or more components of the computing device 1300. The computing device 1300 may also include multiple external or internal devices, such as input or output devices. For example, the computing device 1300 is shown having an input / output (I / O) interface 1318, which may receive input from one or more input devices 1320 or provide output to one or more output devices 1322. One or more input devices 1320 and one or more output devices 1322 may be communicatively connected to the I / O interface 1318. The communication connection may be implemented in any suitable manner (e.g., via printed circuit board connection, via cable connection, via wireless communication, etc.). Non-limiting examples of input devices 1320 include touchscreens (e.g., one or more cameras for imaging a touch area, or pressure sensors for detecting pressure changes caused by touch), mice, keyboards, or any other devices that may be used to generate input events in response to physical actions of a user of the computing device. Non-limiting examples of output device 1322 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.

[0144] The computing device 1300 can execute program code that configures the processor 1312 to execute the code described above. Figures 1 to 12 One or more of the operations described. The program code may include video encoder 100 or video decoder 200. The program code may reside in memory 1314 or any suitable computer-readable medium and may be executed by processor 1312 or any other suitable processor.

[0145] The computing device 1300 may also include at least one network interface device 1324. The network interface device 1324 may include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 1328. Non-limiting examples of the network interface device 1324 include Ethernet network adapters, modems, etc. The computing device 1300 may transmit messages as electrical or optical signals via the network interface device 1324.

[0146] The embodiments of the present invention also relate to the following technical solutions: Technical Solution 1: A method for decoding video, the method comprising: Access a binary string representing a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; For each of the plurality of CTUs in the partition Before decoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, Set the history counter used to calculate the color components of the Rice parameter to its initial value; Decoding the CTU includes: Based on the historical counter, the Rice parameter of the transformation unit (TU) in the CTU is calculated; Based on the calculated Rice parameters, the binary string corresponding to the TU in the CTU is decoded into the coefficient value of the TU; and The pixel value of the TU in the CTU is determined based on the coefficient value; and Output the decoded partition of the video, wherein the decoded partition includes multiple CTUs that have been decoded in the partition.

[0147] Technical Solution 2: The method described in Technical Solution 1, wherein the partition is a frame, a slice, or a tile.

[0148] Technical Solution 3: According to the method of Technical Solution 1, wherein setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0149] Technical Solution 4: According to the method of Technical Solution 1, wherein calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0150] Technical Solution 5: According to the method of Technical Solution 4, wherein determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx through the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0151] Technical Solution 6: The method according to claim 4, wherein the local summation variable locSumAbs for calculating the coefficients in the TU of the CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

[0152] Technical Solution 7: According to the method of Technical Solution 1, wherein decoding the CTU further includes updating the historical counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

[0153] Technical Solution 8: A non-transitory computer-readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform a plurality of operations, the plurality of operations including: Access a binary string representing a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; For each of the plurality of CTUs in the partition Before decoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, the history counter used to calculate the color components of the Rice parameter is set to an initial value; Decoding the CTU includes: Based on the historical counter, the Rice parameter of the conversion unit (TU) in the CTU is calculated; Based on the calculated Rice parameters, the binary string corresponding to the TU in the CTU is decoded into the coefficient value of the TU; and The pixel value of the TU in the CTU is determined based on the coefficient value; and Output the decoded partition of the video, wherein the decoded partition includes multiple CTUs that have been decoded in the partition.

[0154] Technical Solution 9: The non-transitory computer-readable medium according to Technical Solution 8, wherein the partition is a frame, or a slice, or a tile.

[0155] Technical Solution 10: The non-transitory computer-readable medium according to Technical Solution 8, wherein setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0156] Technical Solution 11: According to the non-transitory computer-readable medium described in Technical Solution 8, the step of calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0157] Technical Solution 12: According to the non-transitory computer-readable medium of Technical Solution 11, wherein determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx by the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0158] Technical Solution 13: According to the non-transitory computer-readable medium of Technical Solution 11, the local summation variable locSumAbs for calculating the coefficients in the TU of the CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

[0159] Technical Solution 14: According to the non-transitory computer-readable medium of Technical Solution 8, wherein decoding the CTU further includes updating the history counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

[0160] Technical solution 15: 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 to perform a plurality of operations, the plurality of operations including: Access a binary string representing a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; For each of the plurality of CTUs in the partition Before decoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, the history counter used to calculate the color components of the Rice parameter is set to an initial value; and Decoding the CTU includes: Based on the historical counter, the Rice parameter of the conversion unit (TU) in the CTU is calculated; Based on the calculated Rice parameters, the binary string corresponding to the TU in the CTU is decoded into the coefficient value of the TU; and The pixel value of the TU in the CTU is determined based on the coefficient value; and Output the decoded partition of the video, wherein the decoded partition includes multiple CTUs that have been decoded in the partition.

[0161] Technical solution 16: The system according to technical solution 15, wherein the partition is a frame, slice, or tile.

[0162] Technical Solution 17: The system according to Technical Solution 15, wherein setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx]= Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0163] Technical Solution 18: According to the system described in Technical Solution 15, the step of calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0164] Technical Solution 19: According to the system described in Technical Solution 18, determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx through the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0165] Technical Solution 20: The system according to Technical Solution 15, wherein decoding the CTU further includes updating the historical counter StatCoeff as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

[0166] Technical Solution 21: A method for encoding video, the method comprising: Access the partition of the video, the partition comprising multiple coding tree units (CTUs), the multiple CTUs forming one or more CTU rows; Processing the partitions of the video to generate a binary representation of the partitions, the processing includes: For each of the plurality of CTUs in the partition Before encoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, the history counter used to calculate the color components of the Rice parameter is set to an initial value; and Encoding the CTU includes: Based on the historical counter, calculate the Rice parameters of the conversion unit (TU) in the CTU; and Based on the calculated Rice parameters, the coefficient values ​​of the TU are encoded into a binary representation corresponding to the TU in the CTU; and The binary representation of the partition is encoded into the video stream.

[0167] Technical solution 22: The method according to technical solution 21, wherein the partition is a frame, or a slice, or a tile.

[0168] Technical Solution 23: According to the method of Technical Solution 21, wherein setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0169] Technical Solution 24: According to the method of Technical Solution 21, wherein calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0170] Technical Solution 25: The method according to Technical Solution 24, wherein determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx by the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0171] Technical Solution 26: The method according to Technical Solution 24, wherein the local summation variable locSumAbs for calculating the coefficients in the TU of the CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

[0172] Technical Solution 27: The method according to Technical Solution 21, wherein encoding the CTU further includes updating the historical counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

[0173] Technical Solution 28: A non-transitory computer-readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform a plurality of operations, the plurality of operations including: Access a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; Processing the partitions of the video to generate a binary representation of the partitions, the processing includes: For each of the plurality of CTUs in the partition Before encoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, the history counter used to calculate the color components of the Rice parameter is set to an initial value; and Encoding the CTU includes: Based on the historical counter, calculate the Rice parameters of the conversion unit (TU) in the CTU; and Based on the calculated Rice parameters, the coefficient values ​​of the TU are encoded into a binary representation corresponding to the TU in the CTU; and The binary representation of the partition is encoded into the video stream.

[0174] Technical Solution 29: The non-transitory computer-readable medium according to Technical Solution 28, wherein the partition is a frame, or a slice, or a tile.

[0175] Technical Solution 30: The non-transitory computer-readable medium according to Technical Solution 28, wherein setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0176] Technical Solution 31: According to the non-transitory computer-readable medium of Technical Solution 28, the step of calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0177] Technical Solution 32: According to the non-transitory computer-readable medium of Technical Solution 31, wherein determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx by the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0178] Technical Solution 33: According to the non-transitory computer-readable medium of Technical Solution 31, the local summation variable locSumAbs for calculating the coefficients in the TU of the CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

[0179] Technical Solution 34: According to the non-transitory computer-readable medium of Technical Solution 28, the encoding of the CTU further includes updating the history counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

[0180] Technical solution 35: 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 to perform a plurality of operations, the plurality of operations including: Access a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows; Processing the partitions of the video to generate a binary representation of the partitions, the processing includes: For each of the plurality of CTUs in the partition Before encoding the CTU, it is determined that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row among the one or more CTU rows in the partition; In response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row of the partition, the history counter used to calculate the color components of the Rice parameter is set to an initial value; and Encoding the CTU includes: Based on the historical counter, calculate the Rice parameters of the conversion unit (TU) in the CTU; and Based on the calculated Rice parameters, the coefficient values ​​of the TU are encoded into a binary representation corresponding to the TU in the CTU; and The binary representation of the partition is encoded into the video stream.

[0181] Technical solution 36: The system according to technical solution 35, wherein the partition is a frame, or a slice, or a tile.

[0182] Technical Solution 37: According to the system of Technical Solution 35, setting the history counter used to calculate the color component cIdx of the Rice parameter to an initial value includes one or more of the following: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Where StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples in the luminance and chrominance 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; or The initial value is calculated as follows: StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int) ((19 - QP) / 6))-l, Where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP for each slice, and Clip() is the operation defined as follows: .

[0183] Technical Solution 38: According to the system described in Technical Solution 35, the step of calculating the Rice parameter of the TU in the CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the substitution variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the CTU; and Based on the local summation variable locSumAbs, the Rice parameter of TU is derived.

[0184] Technical Solution 39: According to the system described in Technical Solution 38, determining the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue of the color component cIdx through the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

[0185] Technical Solution 40: The system according to Technical Solution 35, wherein encoding the CTU further includes updating the historical counter StatCoeff as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

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

[0187] Unless otherwise specifically stated, it should be understood that throughout the discussion in this specification, terms such as “processing,” “computing,” “solving,” “determining,” and “identifying” are used to refer to actions or processes of computing devices (such as one or more computers or similar electronic computing devices) that 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.

[0188] The one or more systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide a result conditioned on one or more inputs. Suitable computing devices include multi-purpose microprocessor-based computer systems that access stored software that programs or configures the computing system from a general-purpose computing device to a special-purpose computing device, thereby implementing one or more embodiments of the subject matter herein. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings contained herein in software used for programming or configuring the computing device.

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

[0190] The use of “suitable for” or “configured to” in this document implies open-ended and inclusive language, which does not exclude devices suitable for or configured to perform additional tasks or steps. Furthermore, the use of “based on” implies open-endedness and inclusiveness, because processes, steps, calculations, or other actions “based on” one or more of the listed conditions or values ​​may actually be based on additional conditions or values ​​beyond the listed values. The headings, lists, and numbering included in this document are for illustrative purposes only and are not intended to be limiting.

[0191] While the subject matter of this document 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, will readily make changes, variations, and equivalents to such embodiments. Therefore, it should be understood that this disclosure is presented for illustrative purposes rather than for limitation, and does not exclude such 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, applied to a decoder, the method comprising: In response that the current CTU is the first CTU in the current CTU row, the history counter used to calculate the color components of the Rice parameter is set to the initial value; Based on the historical counter, the Rice parameter of the coefficients in the current CTU's transformation unit TU is calculated; Based on the calculated Rice parameter, the binary string corresponding to the TU in the current CTU is decoded into the coefficient value of the TU; and The sample value of the TU in the current CTU is determined based on the coefficient value; The step of setting the history counter used to calculate the color components of the Rice parameter to an initial value includes: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Wherein, StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples of the luminance and chrominance 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.

2. The method according to claim 1, wherein, The partition is an image, slice, or tile.

3. The method according to claim 1, wherein, The calculation of the Rice parameter of the coefficient in the TU of the current CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the replacement variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the current CTU; and Based on the local summation variable locSumAbs, the Rice parameter of the coefficients in the TU is derived.

4. The method according to claim 3, wherein, The determination of the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue for the color component cIdx through the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

5. The method according to claim 3, wherein, The local summation variable locSumAbs used to calculate the coefficients in the TU of the current CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

6. The method according to claim 1, wherein, The method further includes updating the history counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

7. A method for encoding video, applied to an encoder, the method comprising: In response that the current CTU is the first CTU in the current CTU row, the history counter used to calculate the color components of the Rice parameter is set to the initial value; Based on the historical counter, the Rice parameter of the coefficients in the current CTU's transformation unit TU is calculated; and Based on the calculated Rice parameter, the coefficient value of the TU is encoded into a binary representation corresponding to the TU in the current CTU; The step of setting the history counter used to calculate the color components of the Rice parameter to an initial value includes: In response to determining that historical Rice parameter derivation is enabled, the initial values ​​are calculated as follows: StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)), Wherein, StatCoeff represents the history counter, BitDepth specifies the bit depth of the samples of the luminance and chrominance 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.

8. The method according to claim 7, wherein, The partition is an image, slice, or tile.

9. The method according to claim 7, wherein, The calculation of the Rice parameter of the coefficient in the TU of the current CTU based on the historical counter includes: Based on the historical counter, determine the replacement variable HistValue; Using the values ​​of neighboring coefficients in a predetermined neighborhood of the coefficients and the replacement variable HistValue, calculate the local summation variable locSumAbs of the coefficients in the TU of the current CTU; and Based on the local summation variable locSumAbs, the Rice parameter of the coefficients in the TU is derived.

10. The method according to claim 9, wherein, The determination of the replacement variable HistValue based on the history counter includes determining the replacement variable HistValue for the color component cIdx through the following calculation: HistValue[cIdx] = 1< <StatCoeff[cIdx], StatCoeff represents the history counter.

11. The method of claim 9, wherein, The local summation variable locSumAbs used to calculate the coefficients in the TU of the current CTU includes: Determine that one of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and The substitution variable HistValue is used as the value of the adjacent coefficient located outside the TU to calculate the local summation variable locSumAbs.

12. The method according to claim 7, wherein, The method further includes updating the history counter as follows: In response to determining the first non-zero Columbus-Rice coded transform coefficient in the TU, which is encoded as abs_remainder, the history counter for the color component cIdx is updated as follows: StatCoeff[cIdx]=(StatCoeff[cIdx]+Floor(Log2(abs_remainder[cIdx]))+2)>>1; and In response to the determination that the first non-zero Columbus-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]=(StatCoeff[cIdx]+Floor(Log2(dec_abs_level[cIdx])))>>1, Where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the base-2 logarithm of x.

13. A decoding apparatus configured to perform a method for decoding video as claimed in any one of claims 1 to 6.

14. An encoding apparatus configured to perform a method for encoding video as claimed in any one of claims 7 to 12.

15. A computer-readable storage medium storing a computer program and a bit stream thereon, characterized in that, When the computer program is executed by a processor, it implements the method for encoding video according to any one of claims 7 to 12 to generate the bitstream.

Images