Video decoding method, encoding method, decoding apparatus, and encoding apparatus

Abstract

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

Description

[0001] This application is a continuation of PCT International Patent Application No. PCT / US2022 / 075502, filed August 26, 2022, entitled “History-Based Rice Parameter Derivations for Wavefront Parallel Processing in Video Coding,” which entered the Chinese national phase as Chinese Patent Application No. 202280042714.1, entitled “History-Based Rice Parameter Derivations for Wavefront Parallel Processing in Video Coding,” which 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 Operation Range Extension,” the entire contents of which are incorporated herein by reference in their entirety.

[0002] Cross Reference to Related Applications

[0003] 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 Operation Range Extension,” all of which are incorporated herein by reference in their entirety. TECHNICAL FIELD

[0004] The present disclosure relates generally to computer-implemented methods and systems for video processing. In particular, the present disclosure relates to history-based Rice parameter derivations for wavefront parallel processing in video coding. BACKGROUND

[0005] The prevalence of camera-enabled devices, such as smartphones, tablets, and computers, has made it easier than ever to capture video or images. However, even short videos can be very large in data size. Video coding techniques, including video encoding and decoding, enable video data to be compressed into a smaller size, thereby enabling various videos to be stored and transmitted. Video coding has been used in a wide range of applications, such as digital television broadcasts, 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 for storing videos and / or the network bandwidth consumption for transmitting videos, it is desirable to improve the efficiency of video coding schemes. SUMMARY

[0006] Some embodiments relate to history-based Rice parameter derivation for wavefront parallel processing in video coding. In one example, a method for decoding a video includes accessing a bin 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 of the plurality of CTUs in the partition, prior to decoding the CTU, determining that parallel coding is enabled and that the CTU is a first CTU of a current CTU row among 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 of the current CTU row in the partition, setting a history counter for a color component used to calculate a Rice parameter to an initial value; decoding the CTU, including calculating a Rice parameter for a transform unit (TU) in the CTU based on the history counter, decoding the bin string corresponding to the TU in the CTU into coefficient values for the TU based on the calculated Rice parameter, and determining pixel values for the TU in the CTU from the coefficient values; and outputting a decoded partition of the video, the decoded partition including the plurality of CTUs in the partition that have been decoded.

[0007] In another example, a non-transitory computer-readable medium having program code stored thereon, the program code executable by one or more processing devices to perform a plurality of operations comprising: accessing a bin string representing a partition of a video, the partition comprising a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; for each CTU of the plurality of CTUs in the partition, prior to decoding the CTU, determining that parallel coding is enabled and that the CTU is a first CTU of a current CTU row among 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 of the current CTU row in the partition, setting a history counter for a color component used to calculate a rice parameter to an initial value; decoding the CTU, including calculating a rice parameter for a transform unit (TU) in the CTU based on the history counter, decoding a bin string corresponding to the TU in the CTU into a coefficient value for the TU based on the calculated rice parameter, and determining a pixel value for the TU in the CTU from the coefficient value; and outputting a decoded partition of the video, the decoded partition comprising the plurality of CTUs in the partition that have been decoded.

[0008] In another example, a system comprising 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 comprising: accessing a bin string representing a partition of a video, the partition comprising a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows; for each CTU of the plurality of CTUs in the partition, prior to decoding the CTU, determining that parallel coding is enabled and that the CTU is a first CTU of a current CTU row among 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 of the current CTU row in the partition, setting a history counter for a color component used to calculate a rice parameter to an initial value; decoding the CTU, including calculating a rice parameter for a transform unit (TU) in the CTU based on the history counter, decoding a bin string corresponding to the TU in the CTU into a coefficient value for the TU based on the calculated rice parameter, and determining a pixel value for the TU in the CTU from the coefficient value; and outputting a decoded partition of the video, the decoded partition comprising the plurality of CTUs in the partition that have been decoded.

[0009] In another example, a method for encoding a video includes accessing 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; processing the partition of the video to generate a binary representation of the partition, the processing including, for each CTU of the plurality of CTUs in the partition, prior to encoding the CTU, determining that parallel encoding is enabled and that the CTU is a first CTU of a 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 of the current CTU row in the partition, setting a history counter for a color component used to calculate a rice parameter to an initial value; encoding the CTU, including calculating the rice parameter for a transform unit (TU) in the CTU based on the history counter, and encoding a coefficient value of the TU into the binary representation corresponding to the TU in the CTU based on the calculated rice parameter; and encoding the binary representation of the partition into a bitstream of the video.

[0010] In another example, a non-transitory computer-readable medium having program code stored thereon, the program code executable by one or more processing devices to perform a plurality of operations, the plurality of operations comprising: accessing a partition of a 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 the video to generate a binary representation of the partition, the processing including, for each CTU of the plurality of CTUs in the partition, prior to encoding the CTU, determining that parallel encoding is enabled and that the CTU is a first CTU of a 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 of the current CTU row in the partition, setting a history counter for a color component used to calculate a rice parameter to an initial value; encoding the CTU, including calculating the rice parameter for a transform unit (TU) in the CTU based on the history counter, and encoding a coefficient value of the TU into the binary representation corresponding to the TU in the CTU based on the calculated rice parameter; and encoding the binary representation of the partition into a bitstream of the video.

[0011] 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 including: accessing a partition of a 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 the video to generate a binary representation of the partition, the processing including: for each CTU of the plurality of CTUs in the partition, prior to encoding the CTU, determining that parallel encoding is enabled and that the CTU is a first CTU of a 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 of the current CTU row in the partition, setting a history counter for a color component used to compute a rice parameter to an initial value; encoding the CTU including: based on the history counter, computing a rice parameter for a transform unit (TU) in the CTU, and based on the computed rice parameter, encoding coefficient values of the TU into the binary representation corresponding to the TU in the CTU; and encoding the binary representation of the partition into a bitstream of the video.

[0012] Reference to these descriptive block embodiments is not intended to limit or restrict the present disclosure but is merely intended to provide examples of embodiments for helping understanding the present disclosure. Additional embodiments are discussed in the DETAILED DESCRIPTION and further description is provided in the DETAILED DESCRIPTION. BRIEF DESCRIPTION OF DRAWINGS

[0013] The features, embodiments and advantages of the present disclosure will be better understood when read with reference to the following detailed description in conjunction with the accompanying drawings.

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

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

[0016] Figure 3 Examples of coding tree unit partitioning of a picture in a video according to some embodiments of the present disclosure are described.

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

[0018] Figure 5 Examples of coding blocks are described in which elements of the coding block are processed in a predetermined order.

[0019] Figure 6 Examples of a template pattern for a local sum variable for computing coefficients located near a transform unit boundary are described.

[0020] Figure 7 Examples are described in which a tile is enabled for wavefront parallel processing.

[0021] Figure 8 Examples are described of a frame, tiles contained in the frame, and coding tree units in accordance with some embodiments of the disclosure in which a history counter is computed for the frame, tiles contained in the frame, and coding tree units.

[0022] Figure 9 Examples are described of a process for encoding a partition of a video in accordance with some embodiments of the disclosure.

[0023] Figure 10 Examples are described of a process for decoding a partition of a video in accordance with some embodiments of the disclosure.

[0024] Figure 11 Another example is described of a process for encoding a partition of a video in accordance with some embodiments of the disclosure.

[0025] Figure 12 Another example is described of a process for decoding a partition of a video in accordance with some embodiments of the disclosure.

[0026] Figure 13 Examples of computing systems that can be used to implement some embodiments of the disclosure are described. DETAILED DESCRIPTION

[0027] Embodiments provide history-based Rice parameter derivation for wavefront parallel processing in video coding. As discussed above, more and more video data is generated, stored, and transmitted. It is advantageous to improve the efficiency of video coding techniques so that less data is used to represent a video 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 code stream using as few bits as possible. On the other hand, because a video typically contains a large amount of data, it is advantageous to reduce the processing time during encoding (encoding and decoding). To this end, parallel processing can be employed in video coding and decoding.

[0028] In entropy coding, video samples are binarized into binary bins, and an encoding algorithm such as context adaptive binary arithmetic coding (CABAC) can further compress the bins into bits. Binarization requires computation of binarization parameters, such as the Rice parameter used in the combination of the truncated Rice (TR) and the finite k-th order exponential Golomb (EGk) binarization processes specified in the Versatile Video Coding (VVC) specification. To improve coding efficiency, a history-based Rice parameter derivation is used. In such a history-based Rice parameter derivation, the Rice parameter for a transform unit (TU) in a current coding tree unit (CTU) of a partition (e.g., a picture, a slice, or a tile) is derived based on a history counter (denoted as StatCoeff) that is computed based on coefficients in the current TU and previous TUs in the current CTU and previous CTUs in the partition. The history counter is then used to derive a replacement variable (denoted as HistValue) for deriving the Rice parameter. The history counter can be updated when a TU is processed. In some examples, the replacement variable for a TU remains the same even if the history counter has been updated.

[0029] The dependency between previous CTUs and the current CTU in a partition for computing the history counter can conflict with, limit, or even prevent the use of parallel processing, resulting in unstable or inefficient video coding. Various implementations described herein address these issues by reducing or eliminating the dependency between some CTUs in a partition so that parallel processing can be enabled to speed up the video processing process, or by detecting and avoiding the conflict before it occurs. The following non-limiting examples are provided to introduce some embodiments.

[0030] In an embodiment, the dependency between CTUs in different CTU rows when computing the history counter is removed, thus eliminating the dependency conflict 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 an initial value before computing the Rice parameter for the first CTU in a CTU row. Subsequent history counters can be computed based on the history counter value in previous TUs in the same CTU row. In this way, in the history-based Rice parameter derivation, the dependency of a CTU is limited within the same CTU row, which does not interfere with parallel processing in different CTU rows, while still benefiting from the coding gain achieved by the history-based Rice parameter derivation. Furthermore, the history-based Rice parameter derivation process is simplified, reducing the computational complexity.

[0031] In another embodiment, the dependency between CTUs when computing the history counter is aligned 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 starts after processing of N CTUs in the previous CTU row. In this scenario, the history counter for a CTU row can be computed based on samples in the first N or fewer CTUs in the previous CTU row. This can be implemented by a store synchronization procedure. After processing the last TU in the first CTU of a CTU row, the history counter can be stored in a store variable. Then, before processing the first TU in the first CTU of a subsequent CTU row, the history counter can be synchronized with the stored value in the store variable.

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

[0033] In this way, the dependency between CTUs in two consecutive CTU rows when computing the history counter is limited to no more than the dependency between CTUs when performing parallel encoding (i.e., is aligned with the dependency between CTUs when performing parallel encoding). Thus, the history counter computation does not interfere with parallel processing while still benefiting from the coding gain achieved by the history-based Rice parameter derivation.

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

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

[0036] In some embodiments, the bit depth of samples of a video (e.g., the bit depth used to determine the initial value of the history counter StatCoeff) can be determined according to a 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 a decoded picture buffer (DPB) used to store decoded pictures can be determined based on a 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. According to the determined size of the DPB, storage space can be allocated for the DPB. The determined bit depth and the DPB can be used throughout the process of decoding the video bitstream into pictures.

[0037] As described herein, some embodiments provide improvements in video coding efficiency and computational efficiency by coordinating history-based Rice parameter derivation with parallel encoding. In doing so, conflicts between history-based Rice parameter derivation and parallel encoding can be avoided, thereby improving the stability of the encoding process. Further, by limiting the dependency between CTUs in history-based Rice parameter derivation to be no greater than the dependency in parallel encoding, coding gains can still be achieved through history-based Rice parameter derivation without sacrificing the computational efficiency of the encoding process. These techniques can be effective coding tools in future video coding standards.

[0038] Reference will now be made to the drawings, Figure 1 is a block diagram illustrating an example of a video encoder 100 configured to implement embodiments presented herein. In Figure 1In the illustrated example, 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.

[0039] The input to video encoder 100 is an input video 102 that contains a sequence of pictures (also referred to as frames or images). In a block-based video encoder, for each picture, video encoder 100 employs a partition module 112 to divide the picture into blocks 104, each containing a number of pixels. The blocks can be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. A picture can include blocks of different sizes, and the block partitioning can also be different for different pictures of a video. Each block can be encoded using different prediction (e.g., intra prediction or inter prediction or a mix of intra and inter prediction).

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

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

[0042] The video encoder 100 can further quantize the transform coefficients using a quantization module 115 to obtain quantized coefficients. Quantization involves dividing the samples by a quantization step size followed by a rounding, and inverse quantization involves multiplying the quantized values by the quantization step size. This quantization process is referred to as scalar quantization. Quantization is used to reduce the dynamic range of the video samples (either transformed or not) so that fewer bits are used to represent the video samples.

[0043] The quantization of the coefficients / samples within a block can be performed independently, and this quantization method is used in some existing video compression standards, such as H.264 and HEVC. For an NxM block, a specific scan order can be used to convert the 2-D coefficients of the block into a 1-D array for quantization and encoding. The quantization of the coefficients within a block can use the scan order information. For example, the quantization of a given coefficient in the block can depend on the state of the previously quantized values along the scan order. To further improve the coding efficiency, more than one quantizer can be used. Which quantizer is used to quantize the current coefficient depends on the information that precedes the current coefficient according to the encoding / decoding scan order. This quantization method is referred to as dependent quantization.

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

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

[0046] As discussed above, reconstructed blocks 136 from neighboring blocks are used in intra prediction of blocks of a picture. Generating a reconstructed block 136 of a block involves computing a reconstructed residual for the block. The reconstructed residual can be determined by applying inverse quantization and inverse transform to the quantized residual of the block. An inverse quantization module 118 is configured to apply inverse quantization to the quantized samples to obtain dequantized coefficients. The inverse quantization module 118 applies the inverse of the quantization scheme applied by the quantization module 115 by using the same quantization step size as the quantization module 115. An inverse transform module 119 is configured to apply an inverse transform of the transform applied by the transform module 114 to the dequantized samples, e.g., inverse DCT or inverse DST. The output of the inverse transform module 119 is the reconstructed residual of the block in the pixel domain. The reconstructed residual can be added to the predicted block 134 of the block to obtain the reconstructed block 136 in the pixel domain. For blocks that have skipped transform, the inverse transform module 119 is not applied to those blocks. The dequantized samples are the reconstructed residual of the block.

[0047] Blocks in subsequent pictures after the first intra predicted picture can be encoded using either inter prediction or intra prediction. In inter prediction, the prediction for a block in a picture comes from one or more previously encoded video pictures. To perform inter prediction, the video encoder 100 uses an inter prediction module 124. The inter prediction module 124 is configured to perform motion compensation for a block based on motion estimates provided by the motion estimation module 122.

[0048] The motion estimation module 122 compares the current block 104 of the current picture to the decoded reference pictures 108 for motion estimation. The decoded reference pictures 108 are stored in the decoded picture buffer 130. The motion estimation module 122 selects the reference block from the decoded reference pictures 108 that best matches the current block. The motion estimation module 122 further identifies the offset between the location of the reference block (e.g., x, y coordinates) and the location of the current block. This offset is referred to as a motion vector (MV) and is provided to the inter prediction module 124. In some cases, multiple reference blocks are identified for blocks in multiple decoded reference pictures 108. Thus, multiple motion vectors are generated and provided to the inter prediction module 124.

[0049] The inter prediction module 124 uses the motion vectors and other inter prediction parameters to perform motion compensation to generate a prediction for the current block (i.e., the inter predicted block 134). For example, based on the motion vector, the inter prediction module 124 can locate the prediction block pointed to by the motion vector in the corresponding reference picture. 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.

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

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

[0052] Figure 2 An example of a video decoder 200 configured to implement embodiments presented herein is described. The video decoder 200 processes the encoded video 202 in a bitstream and generates decoded pictures 208. In the illustrated example, the video decoder 200 includes an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an intra prediction module 226, an inter prediction module 224, and a decoded picture buffer 230. Figure 2 In the illustrated example, the video decoder 200 includes an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an intra prediction module 226, an inter prediction module 224, and a decoded picture buffer 230.

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

[0054] The prediction block 234 for a particular block is generated based on the prediction mode of the block. If the coding parameters of the block indicate that the block is intra predicted, the reconstructed blocks 236 of reference blocks in the same picture can be fed into the intra prediction module 226 to generate the prediction block 234 for the block. If the coding parameters of the block indicate that the block is inter predicted, the prediction block 234 is generated by the inter prediction module 224. The functions of the intra prediction module 226 and the inter prediction module 224 are similar to those of the Figure 1 intra prediction module 126 and the inter prediction module 124, respectively.

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

[0056] Reference is now made to Figure 3 , Figure 3 Examples of coding tree unit partitioning of pictures in a video according to some embodiments of the present disclosure are described. As discussed above with reference to Figure 1 and Figure 2 To encode a picture of a video, the picture is partitioned into blocks, e.g., CTUs (coding tree units) 302 in VVC, as shown in Figure 3 For example, a CTU 302 can be a block of 128x128 pixels. The CTUs are processed in a certain order, e.g., the order shown in Figure 3 In some examples, 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.

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

[0058] 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, in which 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... 18Each coefficient after that performs the process.

[0059] Residual coding

[0060] In video coding, residual coding is used to convert quantization levels into a bitstream. After quantization, for an NxM transform unit (TU) coding block, there are N x M quantization levels. The N x M levels can be zero or non-zero values. If the levels are not in binary form, the non-zero levels are further binarized into binary bins. Context adaptive binary arithmetic coding (CABAC) can further compress the bins into bits. Moreover, there are two coding methods based on context modeling. Specifically, one of the methods adaptively updates the context model according to neighboring coding information. This method is called a context coding method, and the bins coded in this way are called context-coded bins. In contrast, the other method assumes that the probability of 1 or 0 is always 50%, so a fixed context model is always used without adaptation. This method is called a bypass method, and the bins coded by this method are called bypass bins.

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

[0062] To guarantee the worst-case throughput, a predefined value remBinsPassl is used to limit the maximum number of context-coded bins. Within a subblock, RRC will code the level of each position using the reverse coding scan order. If remBinsPassl is greater than 4, when coding the current level, first a flag named sig_coeff_flag is coded into the bitstream to indicate whether the level is zero or not. If the level is not zero, abs_level_gtx_flag[n][0] is coded to indicate whether the absolute level is 1 or greater than 1, where n is the index of the current position within the subblock along the scan order. If the absolute level is greater than 1, par_level_flag is coded to indicate whether the level is odd or even in VVC, and then abs_level_gtx_flag[n][l] exists. The flag par_level_flag and abs_level_gtx_flag[n][l] are also used together to indicate the level is 2, or 3, or greater than 3. After each of the above syntax elements is coded into context-coded bins, the value of remBinsPassl is decremented by 1.

[0063] If the absolute level is greater than 3 or the value of remBinsPassl is not greater than 4, after the aforementioned bins are coded by the context coding method, two more syntax elements abs_remainder and dec_abs_level can be coded into bypass-coded bins for the remaining levels. In addition, the sign of each level within the block is also coded to represent the quantized level, and the sign of each level within the block is coded into bypass-coded bins.

[0064] Another residual coding method uses abs_level_gtxX_flag and the remaining levels to allow conditionally parsing of the syntax elements for level coding of the residual block, the corresponding binarization of the absolute value of the level is shown in Table 1. Here, abs_level_gtxX_flag describes whether the absolute value of the level is greater than X, where X is an integer, e.g. 0, 1, 2 or N. If abs_level_gtxY_flag is 0, there will be no flag abs_level_gtx(Y+1), where Y is an integer between 0 and N-1. If abs_level_gtxY_flag is 1, there will be a flag abs_level_gtx(Y+1). Furthermore, if abs_level_gtxN_flag is 0, there will be no remaining levels. When abs_level_gtxN_flag is 1, there will be remaining levels, which represent the values after (N+1) is removed from the levels. Typically, abs_level_gtxX_flag is coded using a context coding method, and the remaining levels are coded using a bypass method, respectively.

[0065] Table 1 Residual coding based on abs_level_gtxX_flag and the remaining levels

[0066]

[0067]

[0068] For a block coded in transform skip residual coding mode (TSRC), TSRC will start from the top-left sub-block and code each sub-block in coding scan order. Similarly, the syntax element sb_coded_flag is used to indicate whether all the residuals of the current sub-block are equal to zero. When certain conditions occur, all the syntax elements of sb_coded_flag for all sub-blocks except the last one are coded into the bitstream. If all sb_coded_flag for all sub-blocks before the last one are not equal to 1, it will be derived that sb_coded_flag for the last sub-block is 1 and the flag is not coded into the bitstream. To guarantee the worst-case throughput, a pre-defined value RemCcbs is used to limit the maximum number of context-coded bins. If the current sub-block has a non-zero level, TSRC will code the level for each position in coding scan order. If RemCcbs is greater than 4, the following syntax elements will be coded using the context coding method. For each level, sig_coeff_flag is first coded into the bitstream to indicate whether the level is zero. If the level is not zero, coeff_sign_flag is coded to indicate whether the level is positive or negative. Then, abs_level_gtx_flag[n][0] is coded to indicate whether the current absolute level of the current position is greater than 1, where n is the index of the current position within the sub-block along the scan order. If abs_level_gtx_flag[n][0] is not zero, par_level_flag is coded. After each of the above syntax elements is coded using the context coding method, the value of RemCcbs is decremented by 1.

[0069] After the above syntax elements are coded for all positions within the current sub-block, if RemCcbs is still greater than 4, at most four additional abs_level_gtx_flag[n][j] will be coded using the context coding method, where n is the index of the current position within the sub-block along the scan order; j is from 1 to 4. After each abs_level_gtx_flag[n][j] is coded, the value of RemCcbs is decremented by 1. If RemCcbs is not greater than 4, the syntax element abs_remainder will be coded using the bypass method for the current position within the sub-block, if necessary. For those positions that the absolute level is coded using the syntax element abs_remainder entirely through the bypass method, coeff_sign_flag is also coded through the bypass method. In summary, there is a pre-defined counter remBinsPassl in RRC or RemCcbs in TSRC to limit the total number of context-coded bins and to guarantee the worst-case throughput.

[0070] Rice parameter derivation

[0071] In the current RRC design in VVC, two syntax elements, abs_remainder and dec_abs_level, coded into bypass bins, can exist in the bitstream of the remaining levels. abs_remainder and dec_abs_level are binarized by a combination of the truncated Rice (TR) and the finite k-th order exponential Golomb (EGk) binarization processes specified in the VVC specification, which requires a Rice parameter to binarize a given level. To obtain the optimal Rice parameter, a local summing method is employed, as described below.

[0072] The array AbsLevel[ xC ][ yC ] represents an array of absolute values of transform coefficient levels of the current transform block of the color component index cldx. Given an array AbsLevel[ x ][ y ] of a transform block with color component index cldx and top-left luma position ( x0, y0 ), the local summing variable locSumAbs is derived in the manner specified by the following pseudo code process:

[0073]

[0074] where log2TbWidth and log2TbHeight are the base-2 logarithm 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 summing variable locSumAbs, the Rice parameter cRiceParam is derived in the manner specified in Table 2.

[0075] Table 2 - Specification of cRiceParam based on locSumAbs

[0076] locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0077] History-based rice parameter derivation

[0078] If a coefficient is located at a TU boundary, or is first decoded using the Rice method, the template computation for the Rice parameter derivation can produce inaccurate coefficient estimates. For these coefficients, the template computation is biased towards 0, as some template positions can be located outside the TU and interpreted or initialized to the value 0. Figure 6 An example of the template pattern of locSumAbs for computing coefficients located near a TU boundary is shown. Figure 6The CTU 602, which is partitioned into CUs, is shown, each CU including multiple TUs. For the TU 604, the positions of the current coefficients are shown in solid blocks, and the positions of their neighboring samples in the template pattern are shown in patterned blocks. The patterned blocks indicate the predetermined neighborhood of the current coefficients for computing the local sum variable locSumAbs.

[0079] In Figure 6 In the above LDC derivation, these neighboring samples outside the boundary are set to 0 when computing the local sum variable locSumAbs, resulting in inaccurate LDC derivation. For high bit-depth samples (e.g., greater than 10 bits), the neighboring samples outside the boundary can be large numbers. Setting these large numbers to 0 introduces more errors in the LDC derivation.

[0080] To improve the accuracy of LDC estimation according to the computation template, it is suggested to use the history-derived values to update the local sum variable locSumAbs for the template positions outside the current TU, instead of initializing with 0. The implementation of this method is illustrated below by the VVC specification text excerpted from Clause 9.3.3.2, with the suggested text underlined.

[0081] To maintain the history of neighboring coefficient / sample values, a history counter StatCoeff[cldx] is utilized for each color component, where cldx = 0, 1, 2, representing the three color components Y, U, V, respectively. If the CTU is the first CTU in a partition (e.g., picture, slice, or tile), StatCoeff[cldx] is initialized as follows:

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

[0083] Here, BitDepth specifies the bit depth of the samples of the luma and chroma arrays of the video, Floor(x) denotes the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2. Before TU decoding and history counter updating, the replacement variable HistValue is initialized as:

[0084] HistValue[cldx] = 1 « StatCoeff[cldx] (2)

[0085] The replacement variable HistValue is used as an estimate for neighboring samples that are located outside the TU boundary (e.g., neighboring samples have a horizontal or vertical coordinate that is located outside the TU). The local sum variable locSumAbs is re-derived as specified by the following pseudo code, with changes underlined:

[0086]

[0087] For each TU, the history counter StatCoeff is updated once by an exponential moving average process from the first non-zero C. Run-length coded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]). When the first non-zero C. Run-length coded transform coefficient in a TU is coded as abs_remainder, the history counter StatCoeff for color component cldx is updated as follows:

[0088] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1 (3)

[0089] When the first non-zero C. Run-length coded transform coefficient in a TU is coded as dec_abs_level, the history counter StatCoeff for color component cldx is updated as follows:

[0090] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1 (4)

[0091] The updated StatCoeff can be used to compute the replacement variable HistValue for the next TU according to equation (2) before decoding the next TU.

[0092] Wavefront parallel processing (WPP)

[0093] WPP is designed to provide a parallel encoding mechanism. When WPP is enabled in VVC, each CTU row of a frame or tile or slice constitutes a separate partition. WPP is enabled / disabled by the SPS element sps_entropy_coding_sync_enabled_flag. Figure 7 An example of a tile is shown, where WPP is enabled for the tile. In Figure 7In general, each CTU row of a tile is processed with a one-CTU delay with respect to its previous CTU row. In this way, if palette coding is enabled at the end of each CTU row, no dependencies between consecutive CTU rows at the partition boundary are broken except for the CABAC context variables and the palette predictor. To mitigate the potential loss of coding efficiency, the content of the adaptive CABAC context variables and the palette predictor is propagated from the first encoded CTU of the previous CTU row to the first CTU of the current CTU row. WPP does not change the regular raster scan order of the CTUs.

[0094] When WPP is enabled, multiple threads (up to the number of CTU rows in a partition (e.g., tile, slice, or frame)) can work in parallel to process individual CTU rows. By using WPP in the decoder, each decoding thread processes a single CTU row of a partition. The scheduling of the thread processing has to be organized such that for each CTU, the decoding of the top neighboring CTU in the previous CTU row must have been completed. The additional small overhead of adding WPP is such that after the encoding of the first CTU in each CTU row except the last one is completed, the content of all CABAC context variables and the palette predictor can be stored.

[0095] When the history-based Rice parameter derivation discussed above is enabled for high bit-depth and high bit-rate video coding, the last StatCoeff in the previous CTU row is passed to the first TU in the current CTU row. Therefore, when WPP is enabled at the same time, this process interferes with WPP and breaks the parallelism of WPP. In this disclosure, multiple solutions are proposed to solve this problem when parallel coding (e.g., WPP) is enabled.

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

[0097] As an example, the initial value of StatCoeff[cldx] can be determined as follows:

[0098] StatCoeff[idx] = 2 * Floor(Log2(BitDepth - 10)) (5)

[0099] Here, BitDepth specifies the bit depth of samples of the luma or chroma array, and Floor(x) denotes the largest integer less than or equal to x. As another example, the initial value of StatCoeff[cldx] can be determined as:

[0100] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19 - QP) / 6)) - 1 (6)

[0101] Here, MIN_Stat, MAX_Stat are two predefined integers, QP is the initial QP of each slice, and Clip() is an operation defined as follows:

[0102]

[0103] Before encoding the first TU of each CTU row of a partition (e.g., a frame, tile, or slice), a replacement variable HistValue is calculated as follows:

[0104] HistValue[cldx] = 1 « StatCoeff[cldx] (8)

[0105] HistValue can be used to calculate the local sum variable locSumAbs as described above. For each TU, HistValue can be updated once by an exponential moving average process from the first non-zero Columb-Rice encoded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]). When the first non-zero Columb-Rice encoded transform coefficient in a TU is coded as abs_remainder, the history counter StatCoeff[cldx] for color component cldx is updated as follows:

[0106] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1 (9)

[0107] When the first non-zero Columb-Rice encoded transform coefficient in a TU is coded as dec_abs_level, the history counter StatCoeff[cldx] for color component cldx is updated as follows:

[0108] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1 (10)

[0109] The updated StatCoeff[cldx] is used to compute a replacement variable HistValue for the first TU of the next TU of the current CTU or the next CTU in the current CTU row as shown in equation (8).

[0110] Figure 8 An example of a frame 802 and CTUs contained in the frame is shown. In this example, the frame 802 contains two tiles: tile 804A and tile 804B. Tile 804A contains four CTU rows: CTU row 1 to CTU row 4. The first CTU row includes CTU 0 to CTU 9, the second CTU row includes CTU 10 to CTU 19, and so on. Likewise, tile 804B also contains four CTU rows: CTU row 1' to CTU row 4'. The first CTU row includes 10 CTUs: CTU 0' to CTU 9', the second CTU row includes CTU 10' to CTU 19', and so on.

[0111] According to this embodiment, the initial value of StatCoeff[cldx] for tile 804A can be determined according to equation (5) or (6). Before encoding the first TU of each of CTU row 1 to CTU row 4, the initial value of StatCoeff[cldx] is used to compute a replacement variable HistValue[cldx] using equation (8). For example, before encoding the first TU of CTU 0, the variable HistValue is computed using equation (8). This value of HistValue is used to determine the local sum variable locSumAbs of the coefficients in the first TU, which is further used to determine the Rice parameter of the individual coefficients 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). The current value of StatCoeff is used to determine HistValue for the second TU in CTU 0 according to equation (8) before processing the second TU. Then, a similar procedure is taken for the second TU, using HistValue to determine the Rice parameter and update StatCoeff. For the first TU in CTU 1, HistValue is computed according to equation (8) using the latest StatCoeff from the TUs in CTU 0. This procedure can be repeated until the last CTU (i.e., CTU 9) in the current CTU row 1 is processed.

[0112] 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 similar process as described above for CTU row 1 is performed. Again, the variable StatCoeff is initialized once more according to equation (5) or (6) before encoding the first TU of each of CTU 20 and CTU 30.

[0113] Tile 804B can be processed in a similar manner. Before encoding the first TU of each of CTU row l' to CTU row 4' (i.e., CTU 0', CTU 10', CTU 20', and CTU 30'), the value of StatCoeff[cldx] 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 locSumAbs and the LPS parameter for the first CTU of each CTU row and the TUs in the remaining CTUs. In addition, in 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 for the next TU in the same CTU row.

[0114] Although Figure 8 Although described as a frame 802 containing two tiles 804A and 804B, the same process applies to other scenarios, such as a slice containing multiple tiles, a frame containing multiple slices, and so on. In any of these scenarios, the value of the history counter StatCoeff[cldx] is reset to the initial value before encoding the first TU in each CTU row of a partition (e.g., a frame, a tile, or a slice) to eliminate the dependency of CTU rows in the LPS parameter derivation.

[0115] The possible normative changes for VVC as indicated by underlining are specified as follows.

[0116]

[0117] For 9.3.2.1, another possible normative change for VVC is specified as follows.

[0118]

[0119] Bit depth of video samples

[0120] The bit depth of the input video supported by VVC version 2 can exceed 10 bits. Higher video bit depth can provide higher visual quality to the decoded video with lower compression distortion. To support high bit depth of the 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 changed as follows.

[0121] sps_bitdepth_minus8 specifies the bit depth BitDepth of samples of luma and chroma arrays, and the value of luma and chroma quantization parameter range offset QpBdOffset, as follows:

[0122] BitDepth = 8 + sps_bitdepth_minus8 (x1)

[0123] QpBdOffset = 6 * sps_bitdepth_minus8 (x2)

[0124] sps_bitdepth_minus8 shall be in the range of 0 to 8, inclusive.

[0125] When sps_video_parameter_set_id is greater than 0 and the SPS is referred by a layer included in the i-th multi-layer OLS specified by the VPS (for any i, which is in the range of 0 to NumMultiLayerOlss - 1, inclusive), the requirement for bitstream conformance is that the value of sps_bitdepth_minus8 shall be less than or equal to the value of vps_ols_dpb_bitdepth_minus8[i].

[0126] vps_ols_dpb_bitdepth_minus8[i] specifies the maximum allowed value of sps_bitdepth_minus8 for all SPS referred by CLVSs in the i-th multi-layer OLS. The value of vps_ols_dpb_bitdepth_minus8[i] shall be in the range of 0 to 8, inclusive.

[0127] NOTE 2 - To decode the i-th multi-layer OLS, the decoder can safely allocate memory to the DPB according to the values of 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].

[0128] From the foregoing, it can be seen that the bit depth BitDepth of samples of the luma and chroma arrays can be derived according to equation (xl) based on the SPS syntax element sps_bitdepth_minus8. With the determined BitDepth value, the history counter StatCoeff, the substitution variable HistValue, and the Rice parameter can be derived as discussed above.

[0129] The VPS syntax element vps_ols_dpb_bitdepth_minus8[i] can be used to derive the size of the decoded picture buffer (DPB). For a coded bitstream, there can be multiple video layers. The video parameter set is used to specify the corresponding syntax elements. For video decoding, the DPB can be used to store reference pictures so that previously coded pictures can be used to generate prediction signals for use in coding 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 an output delay for a hypothetical reference decoder. Decoded pictures can be kept in the DPB for a predetermined period of time specified for the hypothetical reference decoder and output after the predetermined period of time has elapsed.

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

[0131] picture_size1 (in bits) = vps_ols_dpb_pic_width[i] * vps_ols_dpb_pic_height[i] * (vps_ols_dpb_bitdepth_minus8[i] + 8)

[0132] If (vps_ols_dpb_chroma_format[i] == 0) / / monochrome, then

[0133] picture_size = picture_size1;

[0134] Else if (vps_ols_dpb_chroma_format[i] == 1) / / 4:2:0, then

[0135] picture_size = 1.5 * picture_size1;

[0136] Otherwise, if (vps_ols_dpb_chroma_format[ i ] == 2 / / 4:2:2, then

[0137] picture_size = 2 * picture_size1;

[0138] Otherwise, if (vps_ols_dpb_chroma_format[ i ] == 3 / / 4:4:4, then

[0139] picture_size = 3 * picture_size1;

[0140] Thus, the size of the DPB will be determined by picture_size. In other words, the size of the DPB can be determined according to 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 base picture size picture_size1. If the color subsampling of the color video frame is 4:2:0, the size of the frame is determined to be 1.5 times the base picture size picture_size1; if the color subsampling of the color video frame is 4:2:2, the size of the frame is determined to be twice the base picture size picture_size1; and if the color subsampling of the color video frame is 4:4:4, the size of the frame is determined to be three times the base picture size picture_size1. According to the color subsampling, the size of the DPB can be determined to be the number of frames to be stored in the DPB multiplied by the size of the frame.

[0141] Figure 9 An example of a process 900 for encoding a partition of a video according to some embodiments of the present disclosure is described. One or more computing devices (e.g., a computing device implementing video encoder 100) implement the operations described in the Figure 9 section by executing suitable program code (e.g., program code implementing entropy encoding module 116). For purposes of illustration, process 900 is described with reference to some of the examples described in the figures. However, other implementations are possible.

[0142] At block 902, process 900 includes accessing a partition of a video signal. The partition can be a video frame, slice, or tile, or any type of partition that is processed by a video encoder as a unit when performing encoding. The partition includes a set of CTUs arranged in CTU rows as shown in Figure 8 . Each CTU includes one or more CTUs, and each CTU includes a plurality of TUs for encoding as shown in the example of Figure 6 .

[0143] At block 904, process 900 involves processing each CTU in the set of CTUs in the partition to encode the partition into bits, block 904 including 906-914. At block 906, process 900 involves determining whether a parallel encoding mechanism is enabled and whether the current CTU is the first CTU of a CTU row. In some examples, parallel encoding can be indicated by a flag, with a value of 0 of the flag indicating that parallel encoding is disabled and a value of 1 of the flag indicating that parallel encoding is enabled. If it is determined that the parallel encoding mechanism is enabled and that the current CTU is the first CTU of a CTU row, process 900 involves setting a history counter StatCoeff to an initial value at block 908. 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.

[0144] If it is determined that the parallel encoding mechanism is not enabled or that the current CTU is not the first CTU of a CTU row, or after the history counter is set at block 908, process 900 involves computing a Rice parameter for a TU in the CTU based on the history counter at block 910. As discussed above with reference to the detailed description of Figure 6 to Figure 8 If the history counter is reset at block 908, the Rice parameter for the TU in the CTU is computed based on the reset history counter or a subsequently updated history counter. If the history counter is not reset at block 908, the Rice parameter for the TU in the CTU is computed based on the history counter updated in the previous CTU or subsequently updated in the current CTU.

[0145] At block 912, process 900 involves encoding the TU in the CTU into a binary representation based on the computed Rice parameter, e.g., by a combination of truncated Rice (TR) and finite k-th order EGk specified in the VVC specification. At block 914, process 900 involves encoding the binary representation of the CTU into bits for inclusion in a bitstream of the video. For example, the encoding can be performed using context adaptive binary arithmetic coding (CABAC) discussed above. At block 916, process 900 involves outputting the encoded video bitstream.

[0146] Figure 10 An example of a process 1000 for decoding a partition of a video according to some embodiments of the disclosure is described. One or more computing devices implement the operations described in Figure 10 by executing suitable program code. For example, a computing device implementing video decoder 200 can implement the operations described in Figure 10 by executing program code for entropy decoding module 216, inverse quantization module 218, and inverse transform module 219. For purposes of illustration, process 1000 is described with reference to some of the examples described in the figures. However, other implementations are possible.

[0147] At block 1002, the process 1000 involves accessing a bin string or a binary representation that represents a partition of a video signal. The partition can be a video frame, a slice, or a tile, or any type of partition that is processed by a video encoder as a unit when performing encoding. The partition includes a set of CTUs arranged in CTU rows as shown in Figure 8 Each CTU includes one or more CTUs, and each CTU includes a plurality of TUs for encoding as shown in Figure 6 the example shown in

[0148] At block 1004, the process 1000 involves processing the bin string of each CTU in the set of CTUs in the partition to generate decoded samples of the partition, which includes 1006-1014. At block 1006, the process 1000 involves determining whether a parallel encoding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. Parallel encoding can 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 the parallel encoding mechanism is enabled and the current CTU is the first CTU of the CTU row, the process 1000 involves setting a history counter StatCoeff to an initial value at block 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.

[0149] If it is determined that the parallel encoding mechanism is not enabled or the current CTU is not the first CTU of the CTU row, or after the history counter is set at block 1008, the process 1000 involves calculating a Rice parameter for a TU in the CTU based on the history counter at block 1010. As discussed above with reference to Figure 6 to Figure 8 If the history counter is reset at block 1008, the Rice parameter for the TU in the CTU is calculated based on the reset history counter or a subsequently updated history counter. If the history counter is not reset at block 1008, the Rice parameter for the TU in the CTU is calculated based on the history counter updated in the previous CTU or subsequently updated in the current CTU.

[0150] At block 1012, the process 1000 involves decoding the bin string or the binary representation of the TU in the CTU into coefficient values based on the calculated Rice parameter, for example, by the combination of truncated Rice (TR) and finite k-th order EGK specified in the VVC specification. At block 1014, the process 1000 involves reconstructing pixel values of the TU in the CTU, for example, by the inverse quantization and inverse transform discussed above with reference to Figure 2 At block 1016, the process 1000 involves outputting the decoded partition of the video.

[0151] In another embodiment, the dependencies between CTUs when computing the history counter StatCoeff are aligned with the dependencies between CTUs in a parallel encoding mechanism, such as WPP. For example, the history counter StatCoeff for a CTU row of a partition (e.g., frame, tile, or slice) can be computed based on the coefficient values in the first N or fewer CTUs in the previous CTU row, where N is the maximum delay between two consecutive CTU rows allowed in the parallel encoding mechanism. In this way, the dependencies between CTUs in two consecutive CTU rows when computing the history counter StatCoeff are limited to no more than the dependencies between CTUs when performing parallel processing (and thus, are aligned with the dependencies between CTUs when performing parallel processing).

[0152] 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. In the storage procedure, StatCoeff[cldx] can be saved in a storage variable StatCoeffWpp[cldx] after encoding the last TU of the first CTU in each CTU row (except the last CTU row), and for each CTU row except the first CTU row, a synchronization procedure of the Rice parameter derivation is applied before encoding the first TU. In the synchronization procedure, StatCoeff[cldx] is synchronized with StatCoeffWpp[cldx] saved from the previous CTU row.

[0153] As discussed above, before encoding the first TU in each CTU row, the variable HistValue is computed as follows:

[0154] HistValue[cldx] = 1 « StatCoeff[cldx] (11)

[0155] If the current CTU row is the first CTU row of a partition, StatCoeff[cldx] can be initialized according to equation (5) or (6). The computed HistValue can be used to determine a local sum variable locSumAbs, which in turn is used to determine the Rice parameter for the TUs in the current CTU. For each TU, StatCoeff is updated once through an exponential moving average procedure from the first non-zero, Golomb-Rice encoded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]), as described above for equations (9) and (10).

[0156] After encoding the last TU of the first CTU in the first CTU row, StatCoeff[cldx] can be saved as StatCoeffWpp[cldx] in a storing step as follows:

[0157] StatCoeffWpp[cldx] = StatCoeff[cldx] (12)

[0158] The encoding of the remaining CTUs in the first CTU row can be performed in a similar manner as described above for the first embodiment.

[0159] Before encoding the first TU in the second CTU row and any subsequent CTU rows, StatCoeff[cldx] can be obtained through a synchronizing step as follows:

[0160] StatCoeff[cldx] = StatCoeffWpp[cldx] (13)

[0161] Using the obtained StatCoeff[cldx] value, HistValue is calculated according to equation (11). The remaining process of the CTU row is the same as that of the first CTU row.

[0162] Possible changes to the VVC specification are specified as follows (changes are underlined)

[0163]

[0164]

[0165] Alternative history-based rice parameter derivation

[0166] The history-based Rice parameter derivation can be implemented in an alternative way. In this alternative implementation, if a CTU is the first CTU in a partition (e.g., picture, slice, or tile), the initial value of StatCoeff[cldx] is used to initialize HistValue as follows:

[0167] HistValue = sps_persistent_Rice_adaptation_enabled_flag? 1 « StatCoeff[cldx] : 0 (14)

[0168] The initial HistValue is used to code the first abs_remainder[cldx] or dec_abs_level[cldx] until the HistValue is updated according to the following rules. When the first non-zero, Golomb-Rice coded transform coefficient in a TU is coded into abs_remainder, the history counter for color component cldx is updated as follows:

[0169] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1 (15)

[0170] When the first non-zero, Golomb-Rice coded transform coefficient in a TU is coded into dec_abs_level, the history counter for color component cldx is updated as follows:

[0171] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1 (16)

[0172] Once the history counter StatCoeff[cldx] has been updated, the HistValue is updated as shown in equation (17), and the updated HistValue will be used to derive the Rice parameters for the rest of the syntax elements abs_remainder and dec_abs_level until the new StatCoeff[cldx] and HistValue[cldx] are updated again.

[0173] HistValue[cldx] = 1 « StatCoeff[cldx] (17)

[0174] Based on the current VVC specification, possible specification changes are specified as follows.

[0175] Clause 731111 (Residual coding syntax) is changed as follows (added content is underlined):

[0176]

[0177]

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

[0179] This embodiment can also be implemented using a storage synchronization process. For example, in the storage process, StatCoeff[cldx] and HistValue[cldx] can be saved in storage variables, StatCoeffWpp[cldx] and HistValueWpp[cldx], respectively, as shown in Equations (18) and (19) after processing the last TU of the first CTU in each CTU row.

[0180] StatCoeffWpp[cldx] = StatCoeff[cldx] (18)

[0181] HistValueWpp[cldx] = HistValue[cldx] (19)

[0182] For each CTU row except the first CTU row, the synchronization process of the Rice parameter derivation is applied before coding the first TU. For example, StatCoeff[cldx] and HistValue[cldx] are synchronized with StatCoeffWpp[cldx] and HistValueWpp[cldx] saved from the previous CTU row, respectively, as shown in Equations (20) and (21).

[0183] StatCoeff[cldx] = StatCoeffWpp[cldx] (20)

[0184] HistValue[cldx] = HistValueWpp[cldx] (21)

[0185] The synchronized variable HistValue is used to code the first abs_remainder[cldx] or dec_abs_level[cldx] until HistValue is updated.

[0186] As discussed above, StatCoeff[cldx] can be updated once for each TU from the first non-zero column-bose-Lee encoded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]) as shown in equation (15) or (16). Once the history counter StatCoeff[cldx] has been updated, HistValue will be updated according to equation (17) and the updated HistValue will be used to derive the Lee parameters for the rest of the syntax elements abs_remainder and dec_abs_level until the new StatCoeff[cldx] and HistValue are updated again.

[0187] Based on the current VVC specification, the possible specification changes as indicated by underlined are specified as follows.

[0188]

[0189] Figure 11 An example of a process 1100 for encoding a partition of a video according to some embodiments of the present disclosure is described. One or more computing devices (e.g., a computing device implementing video encoder 100) implement the operations described in the Figure 11 section by executing suitable program code (e.g., program code implementing entropy encoding module 116). For purposes of illustration, process 1100 is described with reference to some of the examples described in the figures. However, other implementations are possible.

[0190] At block 1102, process 1100 includes accessing a partition of a video signal. The partition can be a video frame, slice, or tile, or any type of partition that is processed by a video encoder as a unit when performing encoding. The partition includes a set of CTUs arranged in CTU rows as shown in Figure 8 FIG. 1. Each CTU includes one or more CTUs, and each CTU includes a plurality of TUs for encoding as shown in the example of Figure 6 FIG. 2.

[0191] At block 1104, the process 1100 involves processing each CTU in the set of CTUs in the partition to encode the partition into bits, block 1104 including 1106-1118. At block 1106, the process 1100 involves determining whether the parallel encoding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. In some examples, parallel encoding can be indicated by a flag, with a value of 0 for the flag indicating that parallel encoding is disabled and a value of 1 for the flag indicating that parallel encoding is enabled. If it is determined that the parallel encoding mechanism is enabled and that the current CTU is the first CTU of the CTU row, the process 1100 involves determining, at block 1107, whether the current CTU row is the first CTU row in the partition. If so, the process 1100 involves setting the history counter StatCoeff to an initial value at block 1108. 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, the process 1100 involves setting the history counter StatCoeff to the value stored in the history counter storage variable, as shown in equation (13) or (20), at block 1109. In some examples, such as when an alternative Rice parameter derivation is utilized, the value of the replacement variable HistValue can also be reset to the stored value, as shown in equation (21).

[0192] If it is determined that the parallel encoding mechanism is not enabled or that the current CTU is not the first CTU of the CTU row, or after the value of the history counter is set at block 1108 or 1109, the process 1100 involves calculating the Rice parameter for the TUs in the CTU based on the history counter (and the replacement variable HistValue if HistValue was reset), at block 1110. As described above (e.g., with reference to Figure 8 If the value of the history counter was reset at block 1108 or 1109, the Rice parameter for the TUs in the CTU is calculated based on the reset history counter or a subsequently updated history counter. If the history counter was not reset at block 1108 or 1109, the Rice parameter for the TUs in the CTU is calculated based on the history counter updated in the previous CTU or subsequently updated in the current CTU.

[0193] At block 1112, the process 1100 involves encoding the TUs in the CTU into a binary representation based on the calculated Rice parameters, such as by the combination of truncated Rice (TR) and finite k-th order EGK specified in the VVC specification. At block 1114, the process 1100 involves encoding the binary representation of the CTU into bits for inclusion in the video bitstream. The encoding can be performed using context adaptive binary arithmetic coding (CABAC) as discussed above, for example.

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

[0195] In some scenarios, a CTU in a non-first CTU row can be located at a boundary of a partition. For example, the first CTU in a second CTU row can not have a CTU in the partition located at the top of the CTU. In these scenarios, the history counter of the CTU can be set to an initial value, rather than the stored value. In this case, the process 1100 can proceed to block 1108 to set the history counter to the initial value. Figure 11 A new block 1107' is added between block 1107 and block 1109 to determine whether the CTU is located at a boundary of a partition (e.g., the CTU does not have a top neighbor CTU within the partition). If so, the process 1100 proceeds to block 1108 to set the history counter to an initial value; if not, the process 1100 proceeds to block 1109 to set the history counter to the stored value. Figure 11 The remaining blocks of the process 1100 can remain unchanged.

[0196] Figure 12 An example of a process 1200 for decoding a partition of a video according to some embodiments of the disclosure is described. One or more computing devices implement the operations described in Figure 12 by executing suitable program code. For example, a computing device implementing the video decoder 200 can implement the operations described in Figure 12 by executing program code for the entropy decoding module 216, the inverse quantization module 218, and the inverse transform module 219. For purposes of illustration, the process 1200 is described with reference to some of the examples described in the figures. However, other implementations are possible.

[0197] At block 1202, the process 1200 includes accessing a binary string or binary representation representing a partition of a video signal. The partition can be a video frame, slice, or tile, or any type of partition that is processed as a unit by a video encoder when performing encoding. The partition includes a set of CTUs arranged in CTU rows as shown in Figure 8 Each CTU includes one or more CTUs, and each CTU includes a plurality of TUs for encoding as shown in the example of Figure 6 .

[0198] At block 1204, the process 1200 involves processing the bin string of each CTU in the set of CTUs in the partition to generate decoded samples of the partition, block 1204 including 1206-1218. At block 1206, the process 1200 involves determining whether the parallel encoding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. Parallel encoding can be indicated by a flag, with a value of 0 of the flag indicating that parallel encoding is disabled and a value of 1 of the flag indicating that parallel encoding is enabled. If it is determined that the parallel encoding mechanism is enabled and that the current CTU is the first CTU of the CTU row, the process 1200 involves determining, at block 1207, whether the current CTU row is the first CTU row in the partition. If so, the process 1200 involves setting, at block 1208, the history counter StatCoeff to an 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, the process 1200 involves setting, at block 1209, the history counter StatCoeff to the value stored in the history counter storage variable, as shown in equation (13) or (20). In some examples, such as when alternative Rice parameter derivation is utilized, the value of the alternative variable HistValue can also be reset to the stored value, as shown in equation (21).

[0199] If it is determined that the parallel encoding mechanism is not enabled or that the current CTU is not the first CTU of the CTU row, or after the history counter is set at block 1208 or 1209, the process 1200 involves calculating, at block 1210, the Rice parameter for the TUs in the CTU based on the history counter (and the alternative variable HistValue, if the value of HistValue is also set). As described above (e.g., with reference to Figure 8 If the value of the history counter is reset at block 1208 or 1209, the Rice parameter for the TUs in the CTU is calculated based on the reset history counter or a subsequently updated history counter. If the history counter is not reset at block 1208 or 1209, the Rice parameter for the TUs in the CTU is calculated based on the history counter updated in the previous CTU or subsequently updated in the current CTU.

[0200] At block 1212, the process 1200 involves decoding the bin string or binary representation of the TUs in the CTU into coefficient values based on the calculated Rice parameter, such as by the combination of truncated Rice (TR) and finite k-th order EGK specified in the VVC specification. At block 1214, the process 1200 involves reconstructing the pixel values of the TUs in the CTU, such as by the inverse quantization and inverse transform discussed above for Figure 2

[0201] ​At block 1216, the process 1200 involves determining whether parallel coding is enabled and whether the CTU is the first CTU of the current CTU row. If so, the process 1200 involves storing the value of the history counter in a history counter storage variable at block 1218, as shown in equation (12) or (18). In some examples, such as when an alternative rice parameter derivation is utilized, the value of the alternative variable HistValue can also be stored in the storage variable, as shown in equation (19). At block 1220, the process 1200 involves outputting the decoded partition of the video.

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

[0203] 7.3.2.22 Sequence parameter set range extension syntax (added content in underlined)

[0204]

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

[0206]

[0207] Although in the above description, TUs are shown and described in the figures (e.g. Figure 6 ), the same techniques can be applied to transform blocks (TBs). In other words, in the above-presented embodiments (including the figures), TUs can also represent TBs.

[0208] Computing system examples for implementing dependent quantization for video coding

[0209] Any suitable computing system can be used to perform the operations described herein. For example, Figure 13 A video encoder 100 or Figure 1 is described that can implement the techniques described herein. Figure 2FIG. 13 illustrates an example of a computing device 1300 of a video decoder 200. In some embodiments, the computing device 1300 can include a processor 1312 communicatively coupled to a memory 1314 and executing computer-executable program code and / or accessing information stored in the memory 1314. The processor 1312 can include a microprocessor, an application-specific integrated circuit (ASIC), a state machine, or other processing means. The processor 1312 can include any of a variety of processing devices including one processing device. Such a processor can include or be in communication with a computer- readable medium that stores instructions, which, when executed by the processor 1312, cause the processor to perform operations described herein.

[0210] The memory 1314 can include any suitable non-transitory computer-readable medium. A computer-readable medium can include any electronic, optical, magnetic, or other storage devices capable of providing computer-readable instructions or other program code to a processor. Non-limiting examples of computer-readable media include magnetic disks, memory chips, ROMs, RAMs, ASICs, configured processors, optical storage, magnetic tape or other magnetic storage devices, or any other medium that a computer processor can read from or write to. The instructions can include processor-specific instructions generated by a

[0211] The computing device 1300 can also include a bus 1316. The bus 1316 can communicatively couple one or more components of the computing device 1300. The computing device 1300 can also include a number of external or internal devices, such as input or output devices. For example, the computing device 1300 is shown with input / output (I / O) interface 1318, which can receive input from one or more input devices 1320 or provide output to one or more output devices 1322. The one or more input devices 1320 and the one or more output devices 1322 can be communicatively coupled to the I / O interface 1318. The communicative coupling can be achieved through any suitable means, such as via printed circuit board connections, via cable connections, via wireless transmission communications, etc. Non-limiting examples of input devices 1320 include a touchscreen (e.g., one or more cameras to image a touch area, or pressure sensors to detect pressure changes caused by a touch), a mouse, a keyboard, or any other device that can be used to generate input events in response to physical actions of a user of the computing device. Non-limiting examples of output devices 1322 include an LCD screen, an external monitor, a speaker, or any other device that can be used to display or otherwise present output generated by the computing device.

[0212] The computing device 1300 can execute program code that causes the processor 1312 to be configured to perform one or more of the operations described above with respect to Figure 1 to Figure 12 The program code can include the video encoder 100 or the video decoder 200. The program code can reside in the memory 1314 or any suitable computer-readable medium, and can be executed by the processor 1312 or any other suitable processor.

[0213] The computing device 1300 can also include at least one network interface device 1324. The network interface device 1324 can 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 network interface devices 1324 include Ethernet network adapters, modems, etc. The computing device 1300 can transmit messages as electrical or optical signals via the network interface device 1324.

[0214] Embodiments of the invention are also directed to the following technical solutions:

[0215] Technical solution 1: A method for decoding a video, the method comprising:

[0216] accessing a bin 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;

[0217] for each CTU of the plurality of CTUs in the partition,

[0218] determining, prior to decoding the CTU, that parallel encoding is enabled and the CTU is a first CTU of a current CTU row among the one or more CTU rows in the partition;

[0219] in response to determining that the parallel encoding is enabled and the CTU is the first CTU of the current CTU row in the partition,

[0220] setting a history counter for a color component cldx used to calculate a rice parameter to an initial value;

[0221] decoding the CTU, including:

[0222] calculating the rice parameter for a transform unit (TU) in the CTU based on the history counter;

[0223] decoding a bin string corresponding to the TU in the CTU into coefficient values of the TU based on the calculated rice parameter; and

[0224] determining pixel values of the TU in the CTU according to the coefficient values; and

[0225] outputting a decoded partition of the video, the decoded partition including a plurality of CTUs in the partition that have been decoded.

[0226] Technical solution 2: The method according to technical solution 1, wherein the partition is a frame, or a slice, or a tile.

[0227] Technical solution 3: The method according to technical solution 1, wherein the setting the history counter for a color component cldx used to calculate a rice parameter to an initial value comprises one or more of the following:

[0228] in response to determining that history-based rice parameter derivation is enabled, calculating the initial value as follows:

[0229] StatCoeff[cldx] = 2 * Floor(Log2(BitDepth - 10)),

[0230] where StatCoeff denotes the history counter, BitDepth specifies a bit depth of samples of luma and chroma arrays of the video, Floor(x) denotes a maximum integer less than or equal to x, and Log2(x) is a logarithm of x with base 2; or

[0231] calculating the initial value as follows:

[0232] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19 - QP) / 6)) - 1,

[0233] where MIN_Stat, MAX_Stat are two predefined integers, QP is the initial QP of each slice, and Clip() is an operation defined as follows:

[0234]

[0235] Technical solution 4: The method according to technical solution 1, wherein the calculating the Rice parameter of a TU in the CTU based on the history counter comprises:

[0236] determining a replacement variable HistValue based on the history counter;

[0237] calculating a local sum variable locSumAbs of a coefficient in the TU of the CTU using a value of a neighboring coefficient in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0238] deriving the Rice parameter of the TU based on the local sum variable locSumAbs.

[0239] Technical solution 5: The method according to technical solution 4, wherein the determining a replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cIdx by:

[0240] HistValue[cIdx] = 1 << StatCoeff[cIdx],

[0241] where StatCoeff represents the history counter.

[0242] Technical solution 6: The method according to technical solution 4, wherein the calculating a local sum variable locSumAbs of a coefficient in the TU of the CTU comprises:

[0243] determining that a neighboring coefficient in the predetermined neighborhood of the coefficient is located outside the TU; and

[0244] using the replacement variable HistValue as a value of the neighboring coefficient located outside the TU to calculate the local sum variable locSumAbs.

[0245] Technical solution 7: The method according to technical solution 1, wherein the decoding the CTU further comprises updating the history counter as follows:

[0246] In response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in a TU is encoded into abs_remainder, updating a history counter for a color component cldx as:

[0247] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0248] In response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in a TU is encoded into dec_abs_level, updating the history counter for the color component cldx as:

[0249] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

[0250] where StatCoeff denotes the history counter, Floor(x) denotes the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

[0251] Technical solution 8: A non-transitory computer-readable medium having program code stored thereon, the program code executable by one or more processing devices to perform a plurality of operations comprising:

[0252] accessing a binary string representing a partition of a video, the partition including a plurality of coding tree units (CTUs), the plurality of CTUs forming one or more CTU rows;

[0253] for each CTU of the plurality of CTUs in the partition,

[0254] determining, prior to decoding the CTU, that parallel encoding is enabled and the CTU is a first CTU of a current CTU row among the one or more CTU rows in the partition;

[0255] in response to determining that the parallel encoding is enabled and the CTU is the first CTU of the current CTU row in the partition, setting a history counter for a color component used to calculate a Rice parameter to an initial value;

[0256] decoding the CTU, including:

[0257] calculating, based on the history counter, a Rice parameter for a transform unit (TU) in the CTU;

[0258] based on the computed Rice parameter, decoding a bin string corresponding to the TU in the CTU into coefficient values of the TU; and

[0259] determining pixel values of the TU in the CTU according to the coefficient values; and

[0260] outputting a decoded partition of the video, the decoded partition including a plurality of CTUs in the partition that have been decoded.

[0261] Technical solution 9: The non-transitory computer-readable medium of technical solution 8, wherein the partition is a frame, or a slice, or a tile.

[0262] Technical solution 10: The non-transitory computer-readable medium of technical solution 8, wherein the setting a history counter of a color component cIdx used for computing a Rice parameter to an initial value comprises one or more of the following:

[0263] in response to determining that history-based Rice parameter derivation is enabled, computing the initial value as follows:

[0264] StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)),

[0265] where StatCoeff represents the history counter, BitDepth specifies a bit depth of samples of luma and chroma arrays of the video, Floor(x) represents a maximum integer less than or equal to x, and Log2(x) is a logarithm of x with base 2; or

[0266] computing the initial value as follows:

[0267] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19 - QP) / 6)) - 1,

[0268] where MIN_Stat and MAX_Stat are two predefined integers, QP is an initial QP of each slice, and Clip() is an operation defined as follows:

[0269]

[0270] Technical solution 11: The non-transitory computer-readable medium of technical solution 8, wherein the computing a Rice parameter of a TU in the CTU based on the history counter comprises:

[0271] determining a replacement variable HistValue based on the history counter;

[0272] a local sum variable locSumAbs for a coefficient in a TU of the CTU is calculated using a value of a neighboring coefficient in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0273] The Rice parameter for the TU is derived based on the local sum variable locSumAbs.

[0274] Technical solution 12: The non-transitory computer-readable medium of technical solution 11, wherein the determining a replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cldx by:

[0275] HistValue[cldx] = 1 « StatCoeff[cldx],

[0276] where StatCoeff represents the history counter.

[0277] Technical solution 13: The non-transitory computer-readable medium of technical solution 11, wherein the calculating a local sum variable locSumAbs for a coefficient in a TU of the CTU comprises:

[0278] determining that a neighboring coefficient of the plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is outside the TU; and

[0279] using the replacement variable HistValue as a value of the neighboring coefficient outside the TU to calculate the local sum variable locSumAbs.

[0280] Technical solution 14: The non-transitory computer-readable medium of technical solution 8, wherein the decoding the CTU further comprises updating the history counter as follows:

[0281] in response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in a TU is encoded as abs_remainder, updating a history counter for a color component cldx as:

[0282] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0283] in response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in a TU is encoded as dec_abs_level, updating the history counter for the color component cldx as:

[0284] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

[0285] where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

[0286] Technical solution 15: A system comprising:

[0287] a processing device; and

[0288] 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 comprising:

[0289] accessing a bin string representing a partition of a video, the partition comprising a plurality of coding tree units (CTUs) that form one or more CTU rows;

[0290] for each CTU of the plurality of CTUs in the partition,

[0291] prior to decoding the CTU, determining that parallel encoding is enabled and that the CTU is a first CTU of a current CTU row among the one or more CTU rows in the partition;

[0292] in response to determining that the parallel encoding is enabled and that the CTU is the first CTU of the current CTU row in the partition, setting a history counter for color components used to calculate a rice parameter to an initial value; and

[0293] decoding the CTU, including:

[0294] calculating a rice parameter for a transform unit (TU) in the CTU based on the history counter;

[0295] decoding a bin string corresponding to the TU in the CTU into coefficient values of the TU based on the calculated rice parameter; and

[0296] determining pixel values of the TU in the CTU from the coefficient values; and

[0297] outputting a decoded partition of the video, the decoded partition comprising a plurality of CTUs in the partition that have been decoded.

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

[0299] Technical solution 17: The system according to technical solution 15, wherein the setting the history counter of the color component cIdx used for calculating the Rice parameter to an initial value comprises one or more of the following:

[0300] In response to determining to enable history-based Rice parameter derivation, the initial value is calculated as follows:

[0301] StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)),

[0302] where StatCoeff represents the history counter, BitDepth specifies the bit depth of samples of the luma and chroma arrays of the video, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2; or

[0303] The initial value is calculated as follows:

[0304] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19 - QP) / 6)) - 1,

[0305] where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP of each slice, and Clip() is an operation defined as follows:

[0306]

[0307] Technical solution 18: The system according to technical solution 15, wherein the calculating the Rice parameter of a TU in the CTU based on the history counter comprises:

[0308] determining a replacement variable HistValue based on the history counter;

[0309] calculating a local summation variable locSumAbs of a coefficient in the TU of the CTU using values of neighboring coefficients in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0310] deriving the Rice parameter of the TU based on the local summation variable locSumAbs.

[0311] Technical solution 19: The system according to technical solution 18, wherein the determining a replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cIdx by calculating:

[0312] HistValue[cldx] = 1 « StatCoeff[cldx],

[0313] where StatCoeff represents the history counter.

[0314] Technical solution 20: The system according to technical solution 15, wherein the decoding the CTU further comprises updating the history counter StatCoeff as follows:

[0315] in response to determining that the first non-zero, Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder, updating a history counter for color component cldx as:

[0316] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0317] in response to determining that the first non-zero, Golomb-Rice encoded transform coefficient in the TU is encoded as dec_abs_level, updating the history counter for the color component cldx as:

[0318] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

[0319] where StatCoeff represents the history counter, Floor(x) represents the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

[0320] Technical solution 21: A method for encoding a video, the method comprising:

[0321] 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;

[0322] processing the partition of the video to generate a binary representation of the partition, the processing comprising:

[0323] for each CTU of the plurality of CTUs in the partition,

[0324] determining that parallel encoding is enabled and the CTU is a first CTU of a current CTU row among the one or more CTU rows in the partition, prior to encoding the CTU;

[0325] in response to determining that the parallel coding is enabled and that the CTU is the first CTU of the current CTU row in the partition, setting a history counter of a color component used for computing a luma parameter to an initial value; and

[0326] encoding the CTU, including:

[0327] based on the history counter, computing a luma parameter of a transform unit (TU) in the CTU; and

[0328] based on the computed luma parameter, encoding coefficient values of the TU into a binary representation corresponding to the TU in the CTU; and

[0329] encoding the binary representation of the partition into a bitstream of the video.

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

[0331] Technical solution 23: The method according to technical solution 21, wherein the setting the history counter of a color component cIdx used for computing a luma parameter to an initial value comprises one or more of the following:

[0332] in response to determining that history-based luma parameter derivation is enabled, computing the initial value as follows:

[0333] StatCoeff[cIdx] = 2 * Floor(Log2(BitDepth - 10)),

[0334] where StatCoeff represents the history counter, BitDepth specifies a bit depth of samples of luma and chroma arrays of the video, Floor(x) represents a maximum integer less than or equal to x, and Log2(x) is a logarithm of x with base 2; or

[0335] computing the initial value as follows:

[0336] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19 - QP) / 6)) - 1,

[0337] where MIN_Stat and MAX_Stat are two predefined integers, QP is an initial QP of each slice, and Clip() is an operation defined as follows:

[0338]

[0339] Technical solution 24: The method according to technical solution 21, wherein the calculating the LPS parameter of a TU in the CTU based on the history counter comprises:

[0340] determining a replacement variable HistValue based on the history counter;

[0341] calculating a local sum variable locSumAbs of a coefficient in a TU of the CTU using a value of a neighboring coefficient in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0342] deriving the LPS parameter of the TU based on the local sum variable locSumAbs.

[0343] Technical solution 25: The method according to technical solution 24, wherein the determining the replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cldx by:

[0344] HistValue[cldx] = 1 « StatCoeff[cldx],

[0345] wherein StatCoeff represents the history counter.

[0346] Technical solution 26: The method according to technical solution 24, wherein the calculating the local sum variable locSumAbs of a coefficient in a TU of the CTU comprises:

[0347] determining that a neighboring coefficient in the predetermined neighborhood of the coefficient is located outside the TU; and

[0348] using the replacement variable HistValue as a value of the neighboring coefficient located outside the TU to calculate the local sum variable locSumAbs.

[0349] Technical solution 27: The method according to technical solution 21, wherein the encoding the CTU further comprises updating the history counter as follows:

[0350] in response to determining that a first non-zero, Colsley-LPS encoded transform coefficient in a TU is encoded as abs_remainder, updating a history counter for a color component cldx as:

[0351] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0352] In response to determining that a first non-zero, C. -L. encoded transform coefficient in the TU is encoded into dec_abs_level, the history counter for the color component cldx is updated as:

[0353] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

[0354] where StatCoeff denotes the history counter, Floor(x) denotes the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

[0355] Technical solution 28: A non-transitory computer-readable medium having stored thereon program code executable by one or more processing devices to perform a plurality of operations comprising:

[0356] accessing a partition of a video, the partition including a plurality of coding tree units (CTUs) that form one or more CTU rows;

[0357] processing the partition of the video to generate a binary representation of the partition, the processing including:

[0358] for each CTU of the plurality of CTUs in the partition,

[0359] determining, prior to encoding the CTU, that parallel encoding is enabled and the CTU is a first CTU of a current CTU row among the one or more CTU rows in the partition;

[0360] in response to determining that the parallel encoding is enabled and the CTU is the first CTU of the current CTU row in the partition, setting a history counter for color components used to calculate a Lempel parameter to an initial value; and

[0361] encoding the CTU, including:

[0362] calculating, based on the history counter, a Lempel parameter for a transform unit (TU) in the CTU; and

[0363] encoding, based on the calculated Lempel parameter, coefficient values of the TU into the binary representation corresponding to the TU in the CTU; and

[0364] encoding the binary representation of the partition into a bitstream of the video.

[0365] Technical solution 29: The non-transitory computer-readable medium of technical solution 28, wherein the partition is a frame, or a slice, or a tile.

[0366] Technical solution 30: The non-transitory computer-readable medium of technical solution 28, wherein the setting the history counter of the color component cIdx used for computing the Rice parameter to an initial value comprises one or more of the following:

[0367] In response to determining to enable history-based Rice parameter derivation, the initial value is computed as follows:

[0368] StatCoeff[cIdx] = 2*Floor(Log2(BitDepth-10)),

[0369] where StatCoeff denotes the history counter, BitDepth specifies the bit depth of samples of luma and chroma arrays of the video, Floor(x) denotes the largest integer less than or equal to x, Log2(x) is the logarithm of x with base 2; or

[0370] The initial value is computed as follows:

[0371] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19-QP) / 6))-l,

[0372] where MIN_Stat, MAX_Stat are two predefined integers, QP is an initial QP of each slice, Clip() is an operation defined as follows:

[0373]

[0374] Technical solution 31: The non-transitory computer-readable medium of technical solution 28, wherein the computing the Rice parameter of a TU in the CTU based on the history counter comprises:

[0375] determining a replacement variable HistValue based on the history counter;

[0376] computing a local summation variable locSumAbs of a coefficient in the TU of the CTU using values of neighboring coefficients in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0377] deriving the Rice parameter of the TU based on the local summation variable locSumAbs.

[0378] Technical solution 32: The non-transitory computer-readable medium of technical solution 31, wherein determining a replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cldx by calculating:

[0379] HistValue[cldx] = 1 « StatCoeff[cldx],

[0380] wherein StatCoeff represents the history counter.

[0381] Technical solution 33: The non-transitory computer-readable medium of technical solution 31, wherein calculating a local sum variable locSumAbs for a coefficient in a TU of the CTU comprises:

[0382] determining that one of a plurality of neighboring coefficients in the predetermined neighborhood of the coefficient is located outside the TU; and

[0383] using the replacement variable HistValue as a value for the neighboring coefficient located outside the TU to calculate the local sum variable locSumAbs.

[0384] Technical solution 34: The non-transitory computer-readable medium of technical solution 28, wherein encoding the CTU further comprises updating the history counter as follows:

[0385] in response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in a TU is encoded as abs_remainder, updating a history counter for a color component cldx as:

[0386] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0387] in response to determining that a first non-zero, Golomb-Rice encoded transform coefficient in the TU is encoded as dec_abs_level, updating the history counter for the color component cldx as:

[0388] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

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

[0390] Technical solution 35: A system comprising:

[0391] Processing equipment; and

[0392] 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:

[0393] Access a partition of the video, the partition comprising multiple coding tree units (CTUs) forming one or more CTU rows;

[0394] Processing the partitions of the video to generate a binary representation of the partitions, the processing includes:

[0395] For each of the plurality of CTUs in the partition

[0396] 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;

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

[0398] Encoding the CTU includes:

[0399] Based on the historical counter, calculate the Rice parameter of the conversion unit (TU) in the CTU; and

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

[0401] The binary representation of the partition is encoded into the video stream.

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

[0403] 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:

[0404] In response to determining to enable history-based Rice parameter derivation, the initial value is calculated as follows:

[0405] StatCoeff[cIdx] = 2*Floor(Log2(BitDepth-10)),

[0406] where StatCoeff denotes the history counter, BitDepth specifies the bit depth of samples of the luma and chroma arrays of the video, Floor(x) denotes the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2; or

[0407] The initial value is calculated as follows:

[0408] StatCoeff[idx] = Clip(MIN_Stat, MAX_Stat, (int)((19-QP) / 6))-l,

[0409] where MIN_Stat and MAX_Stat are two predefined integers, QP is the initial QP of each slice, and Clip() is an operation defined as follows:

[0410]

[0411] Technical solution 38: The system of technical solution 35, wherein the calculating the Rice parameter of a TU in the CTU based on the history counter comprises:

[0412] determining a replacement variable HistValue based on the history counter;

[0413] calculating a local summation variable locSumAbs of a coefficient in the TU of the CTU using a value of a neighboring coefficient in a predetermined neighborhood of the coefficient and the replacement variable HistValue; and

[0414] deriving the Rice parameter of the TU based on the local summation variable locSumAbs.

[0415] Technical solution 39: The system of technical solution 38, wherein the determining a replacement variable HistValue based on the history counter comprises determining a replacement variable HistValue for a color component cIdx by calculating:

[0416] HistValue[cIdx] = 1 << StatCoeff[cIdx],

[0417] where StatCoeff denotes the history counter.

[0418] Technical Solution 40: The system of technical solution 35, wherein the encoding the CTU further comprises updating the history counter StatCoeff as follows:

[0419] In response to determining that the first non-zero, Golomb-Rice encoded transform coefficient in the TU is encoded as abs_remainder, the history counter for color component cldx is updated as:

[0420] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(abs_remainder[cldx])) + 2) » 1; and

[0421] In response to determining that the first non-zero, Golomb-Rice encoded transform coefficient in the TU is encoded as dec_abs_level, the history counter for color component cldx is updated as:

[0422] StatCoeff[cldx] = (StatCoeff[cldx] + Floor(Log2(dec_abs_level[cldx]))) » 1,

[0423] where StatCoeff denotes the history counter, Floor(x) denotes the largest integer less than or equal to x, and Log2(x) is the logarithm of x with base 2.

[0424] General considerations

[0425] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter can be practiced without

[0426] Unless specifically stated otherwise, it will be appreciated that throughout the specification, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "identifying," or the like, refer to the action or processes of a computing device, such as one or more computers or a similar electronic computing device or devices, that manipulate or transform data represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the computing platform.

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

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

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

[0430] 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, the method comprising: Access a binary string representing a partition of the video, the partition comprising multiple Code Tree Units (CTUs) forming one or more CTU rows; For one of the plurality of CTUs in the partition Before decoding the CTU, it is determined 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 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 coefficients in the transformation unit TU of 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; The step of setting the history counter for the color component cIdx used to calculate 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 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 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 historical 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 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.

6. The method according to claim 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 to: 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, 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 one 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 coefficients in the transformation unit TU of 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; The step of setting the history counter for the color component cIdx used to calculate 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)), 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 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 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 historical 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 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.

12. The method according to claim 7, wherein, Encoding 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 to: 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