Operational range extension for multi-function video coding

Abstract

In some embodiments, a video decoder decodes a video from a video bitstream encoded using Versatile Video Coding (VVC). Based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8 with a value in a range of 0 to 8, the video decoder determines a bit depth of samples of the video. Based on a video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8 with a value in a range of 0 to 8, the decoder also determines a size of a decoded picture buffer (DPB). The decoder allocates storage space with the determined size of the DPB, decodes the video bitstream into a plurality of pictures based on the determined bit depth, and stores the decoded plurality of pictures in the DPB. The decoder also outputs the decoded pictures for display.

Description

TECHNICAL FIELD

[0001] The present disclosure generally relates to computer-implemented methods and systems for video processing. In particular, the present disclosure relates to operating range extension for multi-function video coding. BACKGROUND

[0002] Ubiquitous camera-equipped devices (e.g., smartphones, tablets, and computers) make it now easier than ever to capture videos or images. However, even a short video can have a very large amount of data. Video coding techniques (including video encoding and decoding) compress video data into a smaller volume, enabling videos to be stored and transmitted. Video coding has wide applications, such as digital television broadcasts, video transmissions over the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing), DVDs, and Blu-ray discs, etc. To reduce the storage space for storing a video and / or the network bandwidth consumption for transmitting a video, it is desirable to improve the efficiency of video coding schemes. SUMMARY

[0003] 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 from a video bitstream encoded using versatile video coding (VVC) includes the following operations. A bit depth of samples of the video is determined based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8; a size of a decoded picture buffer (DPB) is determined based on a video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8, wherein a value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in a range of 0 to 8; a storage space with the determined size of the DPB is allocated; the video bitstream is decoded into a plurality of pictures based on the determined bit depth; one or more of the decoded plurality of pictures are stored in the DPB; and the one or more of the decoded plurality of pictures are outputted for display.

[0004] In another example, a non-transitory computer-readable medium stores program code, and the program code is executable by one or more processing devices to perform operations. The operations include the following: determining a size of a DPB of a video based on a VPS syntax element vps_ols_dpb_bitdepth_minus8 included in a video bitstream of the video, wherein the video bitstream is coded using VVC, and a value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in a range of 0 to 8; allocating storage space having the determined size of the DPB; decoding the video bitstream into a plurality of pictures; storing one or more of the decoded plurality of pictures in the DPB; and outputting the one or more of the decoded plurality of pictures for display.

[0005] 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 to execute program code stored in the non-transitory computer-readable medium to perform operations including the following: determining a size of a DPB of a video based on a VPS syntax element vps_ols_dpb_bitdepth_minus8 included in a video bitstream of the video, wherein the video bitstream is coded using VVC, and a value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in a range of 0 to 8; allocating storage space having the determined size of the DPB; decoding the video bitstream into a plurality of pictures; storing one or more of the decoded plurality of pictures in the DPB; and outputting the one or more of the decoded plurality of pictures for display.

[0006] Reference to these illustrative embodiments is not intended to limit or define the disclosure, but to provide examples to help explain the present disclosure. Additional embodiments are discussed in the DETAILED DESCRIPTION and further description is provided. BRIEF DESCRIPTION OF DRAWINGS

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

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

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

[0010] Figure 3 An example of coding tree unit partitioning of a picture in a video according to some embodiments of the present disclosure is shown.

[0011] Figure 4An example of coding unit partitioning of a coding tree unit is shown according to some embodiments of the disclosure.

[0012] Figure 5 An example of a coding block and a predetermined order of elements that process the coding block is shown.

[0013] Figure 6 An example of a template pattern used to calculate a local sum variable for coefficients located near a transform unit boundary is shown.

[0014] Figure 7 An example of a tile that enables wavefront parallel processing is shown.

[0015] Figure 8 An example of a frame, a tile included within this frame, and a coding tree unit that calculates a history counter according to some embodiments of the disclosure is shown.

[0016] Figure 9 An example of a process of partitioning of an encoded video according to some embodiments of the disclosure is shown.

[0017] Figure 10 An example of a process of partitioning of a decoded video according to some embodiments of the disclosure is shown.

[0018] Figure 11 Another example of a process of partitioning of an encoded video according to some embodiments of the disclosure is shown.

[0019] Figure 12 Another example of a process of partitioning of a decoded video according to some embodiments of the disclosure is shown.

[0020] Figure 13 An example of a computer system that can be used to implement some embodiments of the disclosure is shown. DETAILED DESCRIPTION

[0021] Various embodiments provide history-based Rice parameter derivation for wavefront parallel processing in video coding. As described above, more and more video data is generated, stored, and transmitted. It is beneficial to improve the efficiency of video coding techniques to represent video using less data and without sacrificing the visual quality of the decoded video. One way to improve coding efficiency is through entropy coding to compress processed video samples into a binary bitstream using as few bits as possible. On the other hand, because video often contains a large amount of data, it is beneficial to reduce the processing time during encoding (encoding and decoding). To this end, parallel processing can be employed in video coding and decoding.

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

[0023] The dependencies between the current CTU and the previous CTU in the partition used to compute the history counter can conflict, limit, or even hinder the use of parallel processing, resulting in unstable or inefficient video coding. Various embodiments described herein address these issues by reducing or eliminating the dependencies between some CTUs in a partition, thereby enabling parallel processing to be enabled to speed up the video processing process, or by detecting and avoiding conflicts before they occur. Non-limiting examples are provided below to introduce some implementations.

[0024] In one embodiment, the dependency between CTUs in different CTU rows when computing the history counter is removed, thereby eliminating dependency conflicts with parallel processing. For example, the history counter can be reinitialized for each CTU row of a partition. The history counter can be set to an initial value before computing the LDC parameter for the first CTU in a CTU row. Subsequent history counters can be computed based on the history counter value in the previous TU in the same CTU row. In this way, the dependency of CTUs in the history-based LDC derivation is limited within the same CTU row without interfering with parallel processing between different CTU rows, while still benefiting from the coding gain obtained by the history-based LDC derivation. Furthermore, the history-based LDC derivation process is simplified, and the computational complexity is reduced.

[0025] 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 between CTU rows of a partition, and there can be an N-CTU delay between two consecutive CTU rows. That is, N CTUs of a previous CTU row are processed before starting to process the current CTU row. In this case, the history counter of the current 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.

[0026] In some examples, an alternative history-based LDC derivation is used. In this alternative history-based LDC derivation, an alternative variable HistValue is updated once the history counter StatCoeff is updated when processing a TU. 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.

[0027] In this way, the dependency between CTUs in two consecutive CTU rows when computing the history counter is limited to no more than (i.e., 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 obtained by the history-based LDC derivation.

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

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

[0030] In some embodiments, the bit depth of the samples of the video (e.g., the bit depth used to determine the initial value of the history counter StatCoeff) can be determined according to an SPS syntax element sps_bitdepth_minus8. The value of the SPS syntax element sps_bitdepth_minus8 is in the range of 0 to 8. Similarly, the size of the DPB for storing decoded pictures can be determined based on a VPS syntax element vps_ols_dpb_bitdepth_minus8. The value of the VPS syntax element vps_ol_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.

[0031] As described herein, some embodiments improve the video coding efficiency and the computational efficiency by coordinating the history-based Rice parameter derivation and the parallel encoding. Doing so can avoid the conflict between the history-based Rice parameter derivation and the parallel encoding, and in turn improve the stability of the encoding process. Further, by limiting the dependency between CTUs in the history-based Rice parameter derivation to be no more than the dependency in the parallel encoding, the coding gain can still be obtained through the history-based Rice parameter derivation, and the computational efficiency of the encoding process is not sacrificed. The technique can be an efficient coding tool in future video coding standards.

[0032] Reference will now be made to the drawings, Figure 1 is a block diagram illustrating an example of a video encoder 100 for implementing the embodiments introduced herein. In Figure 1In the illustrated example, video encoder 100 includes partitioning module 112, transform module 114, quantization module 115, inverse quantization module 118, inverse transform module 119, loop filter module 120, intra-prediction module 126, inter-prediction module 124, motion estimation module 122, decoded picture buffer 130, and entropy encoding module 116.

[0033] The input to video encoder 100 is an input video 102 that includes a sequence of pictures (also referred to as frames or images). In a block-based video coder, for each of the pictures, video encoder 100 partitions the picture into blocks 104 using partitioning module 112, and each block includes a plurality of pixels. The blocks can be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. One 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 predictions, such as intra-prediction, inter-prediction, or a hybrid of intra- and inter-prediction.

[0034] 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. Decoding an intra-predicted picture can not require information from other pictures. To perform intra-prediction, Figure 1 Video encoder 100 illustrated in FIG. 1 can employ intra-prediction module 126. Intra-prediction module 126 is configured to generate an intra-predicted block (predicted block 134) using reconstructed samples in reconstructed block 136 of neighboring blocks of the same picture. Intra-prediction is performed according to an intra-prediction mode selected for the block. Video encoder 100 then calculates a difference between block 104 and intra-predicted block 134. This difference is referred to as residual block 106.

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

[0036] The video encoder 100 can further quantize the transform coefficients using a quantization module 115 to obtain quantized coefficients. Quantization involves rounding the samples by a quantization step size, while 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 (transformed or untransformed) video samples so that fewer bits are used to represent the video samples.

[0037] The quantization of coefficients / samples within a block can be done independently, and this quantization approach is used in some existing video compression standards, such as H.264 and HEVC. For an N by M block, a specific scan order can be used to convert the two-dimensional (2D) coefficients of the block into a one-dimensional (1-D) array for coefficient quantization and encoding. The quantization of coefficients within a block can utilize the scan order information. For example, the quantization of a given coefficient in a block can depend on the state of the previous quantized value 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 before the current coefficient in the encoding / decoding scan order. This quantization approach is referred to as dependent quantization.

[0038] The degree of quantization can be adjusted using a quantization step size. For example, for scalar quantization, different quantization step sizes can be applied to obtain 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.

[0039] The entropy encoding module 116 then encodes the quantized samples 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 bins, and the encoding algorithm further compresses the bins into bits. Examples of binarization methods include, but are not limited to, TR and limited EGk binarization. To improve the encoding efficiency, a method of history-based Rice parameter derivation is used, in which the Rice parameter derived for a TU is based on variables obtained or updated from a previous TU. Examples of entropy encoding algorithms include, but are not limited to, a variable-length coding (VLC) scheme, a context-adaptive VLC (CAVLC) scheme, an arithmetic coding scheme, a binarization, a context-adaptive binary arithmetic coding (CABAC), a syntax-based context-adaptive binary arithmetic coding (SBAC), a 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.

[0040] As described above, the reconstructed block 136 from neighboring blocks is used for intra prediction of a block of the picture. Generating the reconstructed block 136 of a block involves computing a reconstructed residual for this block. The reconstructed residual can be determined by applying inverse quantization and inverse transform to the quantized residual of the block. The inverse quantization module 118 is 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. The inverse transform module 119 is configured to apply an inverse transform (e.g., inverse DCT or inverse DST) of the transform applied by the transform module 114 to the dequantized samples. 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 a skip transform, the inverse transform module 119 is not applied to these blocks. The dequantized samples are the reconstructed residual of these blocks.

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

[0042] Motion estimation module 122 compares current block 104 of the current picture to decoded reference pictures 108 used for motion estimation. Decoded reference pictures 108 are stored in decoded picture buffer 130. Motion estimation module 122 selects a reference block from decoded reference pictures 108 that best matches the current block. Motion estimation module 122 further identifies an 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 inter-prediction module 124. In some cases, multiple reference blocks are identified for a block in multiple decoded reference pictures 108. Thus, multiple motion vectors are generated and provided to inter-prediction module 124.

[0043] Inter-prediction module 124 performs motion compensation using the motion vector and other inter-prediction parameters to generate a prediction for the current block (i.e., inter-predicted block 134). For example, based on the motion vector, inter-prediction module 124 can locate a prediction block in a corresponding reference picture that the motion vector points to. If there is more than one prediction block, the prediction blocks are combined with some weights to generate the prediction block 134 for the current block.

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

[0045] To obtain decoded pictures 108 used for motion estimation, reconstructed blocks 136 are processed by loop filter module 120. Loop filter module 120 is configured to smooth pixel transitions to improve video quality. Loop filter module 120 can be configured to implement one or more loop filters, such as a deblocking filter, a sample adaptive offset (SAO) filter, or an adaptive loop filter (ALF), among others.

[0046] Figure 2FIG2 shows an example of a video decoder 200 for implementing the embodiments described herein. The video decoder 200 processes the encoded video 202 in the bitstream and generates a decoded image 208. 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 , a loop filter module 220 , an intra prediction module 226 , an inter prediction module 224 , and a decoded picture buffer 230 .

[0047] The entropy decoding module 216 is used to perform entropy decoding of the encoded video 202. The entropy decoding module 216 decodes quantized coefficients, encoding parameters including intra-frame prediction parameters and inter-frame prediction parameters, and other information. In some examples, the entropy decoding module 216 decodes the bitstream of the encoded video 202 into a binary representation, and then converts this binary representation into the quantization levels of the coefficients. The entropy decoded coefficients are then inverse quantized by the inverse quantization module 218 and then 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 described above with reference to FIG. Figure 1 The inverse quantization module 118 and the inverse transform module 119 are described. The inverse transformed residual block can be added to the corresponding prediction block 234 to generate a reconstructed block 236. For blocks that skip transform, the inverse transform module 219 is not applied to them. The dequantized samples generated by the inverse quantization module 118 are used to generate the reconstructed block 236.

[0048] A 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 an intra-frame predicted block, a reconstructed block 236 of a reference block in the same image may be fed into the intra-frame prediction module 226 to generate the prediction block 234 for the block. If the coding parameters of the block indicate that the block is an inter-frame predicted block, the prediction block 234 is generated by the inter-frame prediction module 224. The role of the intra-frame prediction module 226 is similar to that of the Figure 1 The intra-frame prediction module 126 and the inter-frame prediction module 224 function similarly to Figure 1 The inter-frame prediction module 124.

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

[0050] Now refer to Figure 3 , Figure 3 An example of coding tree unit division of an image in a video according to some embodiments of the present disclosure is shown. Figure 1 andFigure 2 As described above, to encode a picture of a video, the picture is divided into blocks, e.g., as shown in a CTU 302 in VVC. For example, the CTU 302 can be a block of 128x128 pixels. The CTU is processed according to an order, e.g., as shown in Figure 3 Figure 3 In some examples, each CTU 302 in a picture can be divided into one or more coding units (CU) 402 as shown in Figure 4 Figure 4 In VVC, the division of the CTU 302 into CUs 402 can be quad-tree division, binary-tree division, or ternary-tree division. In Figure 4 In

[0051] As described above with reference to Figure 1 and Figure 2 Quantization is used to reduce the dynamic range of the elements of a block in a video signal in order to represent the video signal using fewer bits. In some examples, before quantization, the element at a particular position of a block is referred to as a coefficient. After quantization, the quantized value of a coefficient is referred to as a quantization level or level. Quantization typically involves division by a quantization step followed by rounding, and inverse quantization involves multiplication by the quantization step. Such a quantization process is also referred to as scalar quantization. Quantization of coefficients within a block can be performed independently, and such independent quantization approach is used in some existing video compression standards, e.g., H.264, HEVC, etc. In other examples, e.g., in VVC, dependent quantization is employed.

[0052] For a block of N by M, a specific scan order can be used to convert the 2-D coefficients of the block into a 1-D array for coefficient quantization and encoding, and the same scan order is used by encoding and decoding. Figure 5 An example of an encoded block (e.g., a TU) and a predetermined scan order for processing the coefficients of the encoded block is shown. In this example, the size of the encoded block 500 is 8x8, and the processing starts from the position L0 at the bottom right corner, and proceeds to L 63 If the block 500 is a transform block, Figure 5 ​​The illustrated predetermined order starts from the highest frequency to the lowest frequency. In some examples, the processing (e.g., quantization and binarization) of a block starts from the first non-zero element of the block according to the predetermined scan order. For example, if the coefficients at positions L0-L 17 18 are all zero and the coefficient at L 18 is non-zero, then the processing starts at the coefficient at L 18 and is performed on each coefficient after L

[0053] Residual coding

[0054] Residual coding is used to convert quantization levels into a bitstream in video coding. After quantization, an NxM TU coding block has N x M quantization levels. These N x M levels can be zero or non-zero values. If the levels are not binary, then these non-zero levels will be further binarized into binary bins. CABAC can further compress the bins into bits. Moreover, there are two coding methods based on context modeling. In particular, one of the methods adaptively updates the context model according to neighboring coded information. This method is called the 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 without adaptation is always used. This method is called the bypass method, and the bins coded by this method are called bypass bins.

[0055] ​For regular residual coding (RRC) blocks in VVC, the position of the last non-zero level is defined as the position of the last non-zero level along the coding scan order. The representation of the 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, they are coded using a bypass method. An RRC block can be composed of several pre-defined sub-blocks. The syntax element sb_coded_flag is used to indicate whether the levels of the current sub-block are all 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 the coefficients in the current sub-block will be zero. However, the sb_coded_flag of the last non-zero sub-block with the last non-zero level is derived as 1 from last_sig_coeff_x and last_sig_coeff_y according to the coding scan order without being coded into the bitstream. In addition, the sb_coded_flag of the top-left sub-block containing the DC position is also derived as 1 without being coded into the bitstream. The syntax element sb_coded_flag in the bitstream is coded by a context coding method. RRC will encode the sub-blocks one by one starting from the last non-zero sub-block in the order of the coding scan order as described above with reference to Figure 5 the reverse coding scan order.

[0056] 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 encode the level of each position in the reverse coding scan order. If remBinsPassl is greater than 4, a flag named sig_coeff_flag is first coded into the bitstream to indicate whether the level is zero or non-zero when the current level is coded. If this level is non-zero, abs_level_gtx_flag[n][0] (where n is the index of the current position in the scan order within the subblock) indicates whether the absolute level is 1 or greater than 1. If the absolute level is greater than 1, par_level_flag will be coded to indicate whether the level is odd or even in VVC, and there will be abs_level_gtx_flag[n][l]. The flags of par_level_flag and abs_level_gtx_flag[n][l] are also used together to indicate whether the level is 2, 3, or greater than 3. After each of the above syntax elements is coded as context coded bins, the value of remBinsPassl is decreased by 1.

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

[0058] Another residual coding method uses abs_level_gtxX_flag and the remaining level, such that the syntax elements of the level coding of the residual block can be parsed conditionally, and 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, such as 0, 1, 2, or N. If abs_level_gtxY_flag is 0, where Y is an integer between 0 and N-1, there is no abs_level_gtx(Y+1) flag. If abs_level_gtxY_flag is 1, there will be abs_level_gtx(Y+1) flag. In addition, if abs_level_gtxN_flag is 0, there is no remaining level. When abs_level_gtxN_flag is 1, there will be a remaining level, and it represents the value after removing (N+1) from the level. Typically, abs_level_gtxX_flag is coded using the context coding method, and the remaining level is coded using the bypass method, respectively.

[0059] Table 1. Residual coding based on abs_level_gtxX_flag and remainder

[0060] abs(level) 0 1 2 3 4 5 6 7 8 9 10 11 12 … abs_level_gtx0_flag 0 1 1 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx1_flag 0 1 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx2_flag 0 1 1 1 1 1 1 1 1 1 1 … abs_level_gtx3_flag 0 1 1 1 1 1 1 1 1 1 … Remainder 0 1 2 3 4 5 6 7 8 …

[0061] For a block coded in transform skip residual coding (TSRC) mode, TSRC encodes subblocks one by one starting from the top-left subblock along the coding scan order. Similarly, a syntax element sb_coded_flag is used to indicate whether all the residuals of the current subblock are equal to zero. All the syntax elements of sb_coded_flag for all the subblocks except the last one are coded into the bitstream when a certain condition occurs. If all the sb_coded_flag for all the subblocks before the last one are not equal to 1, sb_coded_flag is derived to be 1 for the last subblock and this 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 bits. If the current subblock has a non-zero level, TSRC encodes the level of each position along the coding scan order. If RemCcbs is greater than 4, the following syntax elements are 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 or non-zero. If the level is non-zero, coeff_sign_flag is coded to indicate whether the level is positive or negative. Then, abs_level_gtx_flag[n][0] (where n is the index of the current position along the scan order within the subblock) is coded to indicate whether the current absolute level of the current position is greater than 1. 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 decreased by 1.

[0062] After the above syntax elements for all positions within the current subblock are coded, if RemCcbs is still greater than 4, then another maximum of four abs_level_gtx_flag[n][j] are coded using the context coding method, where n is the index along the scan order of the current position within the subblock; j is between 1 and 4. After each abs_level_gtx_flag[n][j] is coded, the value of RemCcbs is decreased by 1. If RemCcbs is not greater than 4, then the syntax element abs_remainder is coded using the bypass method for the current position within the subblock, if necessary. For those positions for which the abs_remainder syntax element is coded entirely using the bypass method for the absolute level, the coeff_sign_flags are also coded using 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 bits and to ensure the worst case throughput.

[0063] Rice parameter derivation

[0064] In the current RRC design in VVC, two syntax elements (abs_remainder coded as bypass bits and dec_abs_level) can exist in the bitstream for the remaining levels. Both abs_remainder and dec_abs_level are binarized by a combination of TR and a limited EGk binarization process as specified in the VVC specification, which requires a Rice parameter to binarize a given level. To get the best Rice parameter, a local sum method is employed as described below.

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

[0066]

[0067] locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 )

[0068] where log2TbWidth is the base-2 logarithm of the width of the transform block and log2TbHeight is the base-2 logarithm of the height of the transform block. For abs_remainder, the variable baseLevel is 4, and for dec_abs_level, the variable baseLevel is 0. Given the local sum variable locSumAbs, the Rice parameter cRiceParam is derived as specified in Table 2.

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

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

[0071] History-based rice parameter derivation

[0072] If a coefficient is located at a TU boundary or is first decoded with the Rice method, the template calculation employed for the Rice parameter derivation can produce inaccurate coefficient estimates. For those coefficients, because some template positions can be located outside the TU and interpreted or initialized to the value 0, the template calculation is biased towards 0. Figure 6 An example of the template pattern for computing locSumAbs for a coefficient located near a TU boundary is shown. Figure 6 A CTU 602 partitioned into multiple CUs is shown, and each CU includes multiple TUs. For a TU 604, the location of the current coefficient is shown with a solid block, and the locations of its neighboring samples in the template pattern are shown with patterned blocks. The patterned blocks indicate the predetermined neighborhood of the current coefficient for computing the local sum variable locSumAbs.

[0073] In Figure 6 Because the current coefficient 606 is close to the boundary of the TU 604, some of its neighboring samples in the template pattern are outside the TU boundary, such as neighboring samples 608B and 608E. In the Rice parameter derivation described above, when computing the local sum variable locSumAbs, these out-of-boundary neighboring samples are set to 0, leading to inaccurate Rice parameter derivation. For high bit-depth (e.g., greater than 10 bits) samples, there can be a large number of neighboring samples outside the TU boundary. Setting these large number of samples to 0 will introduce more errors in the Rice parameter derivation.

[0074] To improve the accuracy of the Rice estimation according to the computation template, a method is proposed to update the local sum variable locSumAbs for the template positions outside the current TU with the history-derived values, instead of initializing to 0. An implementation of this method is shown below by excerpting Section 9.3.3.2 of the VVC specification text, with the suggested text underlined.

[0075] To maintain a history of neighboring coefficient / sample values, a history counter StatCoeff[cldx] is utilized for each color component, where cldx = 0, 1, 2 represent 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 to:

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

[0077] Here, 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. Before decoding a TU and updating the history counter, a replacement variable HistValue is initialized to:

[0078] HistValue[cldx] = 1 « StatCoeff[cldx]. (2)

[0079] The replacement variable HistValue is used as an estimate for neighboring samples outside the TU (e.g., neighboring samples have a horizontal or vertical coordinate outside the TU). The local sum variable locSumAbs is re-derived by the following pseudo code procedure, where changes are indicated with underlining:

[0080]

[0081] The history counter StatCoeff is updated once per TU by an exponentially moving average procedure from the first non-zero CAVLC coded transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]). When the first non-zero CAVLC coded transform coefficient in a TU is coded as abs_remainder, the history counter StatCoeff for color component cldx is updated as follows:

[0082] StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor( Log2( abs_remainder[cIdx] ) ) + 2 ) » 1 (3)

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

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

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

[0086] Wavefront parallel processing (WPP)

[0087] WPP is designed to provide a parallel coding 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 with WPP enabled is shown. In Figure 7 In this way, if palette coding is enabled at the end of each CTU row, no dependency between consecutive CTU rows at the partition boundary is broken except for the CABAC context variables and the palette predictor. To mitigate the potential loss of coding efficiency, the adapted CABAC context variables and the content of the palette predictor are 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.

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

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

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

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

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

[0093] Here, BitDepth specifies the bit depth of samples of a 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[cIdx] can be determined as follows:

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

[0095] Here, 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:

[0096]

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

[0098] HistValue [cIdx] = 1 « StatCoeff[cIdx]. (8)

[0099] The HistValue can be used to compute the local sum variable locSumAbs as described above. The HistValue can be updated once per TU from the first non-zero Golomb-Rice coded transform coefficient (abs_remainder[cldx] or dec_abs_level[cIdx]) by an exponentially moving average process. When the first non-zero Golomb-Rice coded transform coefficient in a TU is coded as abs_remainder, the history counter StatCoeff[cIdx] for color component cldx is updated as follows:

[0100] StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor( Log2( abs_remainder[cIdx] ) ) + 2 ) » 1. (9)

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

[0102] StatCoeff[cIdx] = ( StatCoeff[cIdx] + Floor( Log2( dec_abs_level[cIdx] ) ) ) » 1. (10)

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

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

[0105] According to this embodiment, the initial value of StatCoeff[cldx] for tile 804A can be determined according to equation (5) or equation (6). Prior to encoding the first TU in each of CTU row 1 through CTU row 4, the initial value of StatCoeff[cldx] is used to compute a replacement variable HistValue[cldx] using equation (8). For example, prior to encoding the first TU of CTU 0, the variable HistValue is computed using equation (8). This value of HistValue is used to determine a local sum variable locSumAbs of the coefficients in the first TU, which locSumAbs is further used to determine the Rice parameter for the respective coefficients of the first TU. In processing the first TU of the current CTU 0, the history counter StatCoeff can be updated according to equation (9) or equation (10). Prior to encoding the second TU in CTU 0, the current value of StatCoeff is used to determine HistValue for the second TU according to equation (8). A similar process is then employed for the second TU to determine the Rice parameter using HistValue and to update StatCoeff. For the first TU in CTU 1, HistValue is computed according to equation (8) using the last StatCoeff from the TUs in CTU 0. This process can be repeated until the last CTU (CTU 9) in the current CTU row 1 is processed.

[0106] For the second CTU row of tile 804A, the history counter StatCoeff is initialized according to equation (5) or equation (6) prior to encoding the first TU of CTU 10, which is the first CTU of the second CTU row. A similar process as described above with respect to CTU row 1 is performed for the TUs in the CTUs of the second CTU row. Likewise, the variable StatCoeff is initialized again according to equation (5) or equation (6) prior to encoding the first TU of each of CTU 20 and CTU 30.

[0107] Tile 804B can be processed in a similar manner. Before the first TU of each of CTU row 1’ to CTU row 4’ (i.e., CTU 0’, CTU 10’, CTU 20’, and CTU 30’) is encoded, the value of StatCoeff[cldx] is initialized according to equation (5) or equation (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 TUs in the first CTU and the remaining CTUs of the corresponding CTU row. In addition, the history counter StatCoeff can be updated at most once in each TU according to equation (9) or equation (10), and the updated value of StatCoeff is used to determine the HistValue for the next TU in the same CTU row.

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

[0109] The possible normative change for VVC shown underlined is specified as follows.

[0110]

[0111] Another possible normative change for VVC regarding clause 9.3.2.1 is specified as follows:

[0112]

[0113] Bit depth of video samples

[0114] VVC version 2 supports input video with bit depth greater than 10. Higher bit depth of video can provide higher visual quality of decoded video with lower compression distortion. To support high bit depth of input video, the semantics of 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.

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

[0116] BitDepth = 8 + sps_bitdepth_minus8 (x1)

[0117] QpBdOffset = 6 * sps_bitdepth_minus8 (x2)

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

[0119] When sps_video_parameter_set_id is greater than 0 and the SPS is included in the layer reference of the i-th (i is in the range of 0 to NumMultiLayerOLSS - 1, inclusive) multi-layer OLS specified by the VPS, it is a requirement of bitstream conformance that the value of sps_bitdepth_minus8 is less than or equal to the value of vps_ols_dpb_bitdepth_minus8[ i ].

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

[0121] NOTE 2 - For decoding the i-th multi-layer OLS, the decoder can safely allocate storage for the DPB according to the values of the syntax elements vps_ols_dpb_pic_width[ i ], vps_ols_dpb_pic_height[ i ], vps_ols_dpb_chroma_format[ i ], and vps_ols_dpb_bitdepth_minus8[ i ]

[0122] without knowing the values of the other syntax elements in the VPS.

[0123] From the above, based on the SPS syntax element sps_bitdepth_minus8, the bit depth BitDepth of the samples of the luma and chroma arrays can be derived according to equation (x1). Using the determined BitDepth value, the history counter StatCoeff, the replacement variable HistValue, and the Rice parameter can be derived as described above.

[0124] The VPS syntax element vps_ols_dpb_bitdepth_minus8[i] can be used to derive the size of the DPB. A coded bitstream can have 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 used when 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 period of time that is a predetermined time specified for a hypothetical reference decoder, and the decoded pictures are output after the predetermined time has elapsed.

[0125] To safely allocate storage for the DPB, the size of this 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.

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

[0127] if (vps_ols_dpb_chroma_format[i] == 0) / / Monochrome

[0128] picture_size = picture_size1;

[0129] else if (vps_ols_dpb_chroma_format[i] == 1) / / 4:2:0

[0130] picture_size = 1.5 * picture_size1;

[0131] else if (vps_ols_dpb_chroma_format[i] == 2) / / 4:2:2

[0132] picture_size = 2 * picture_size1;

[0133] else if (vps_ols_dpb_chroma_format[i] == 3 / / 4:4:4

[0134] picture_size = 3 * picture_size1 ;

[0135] The size of the DPB is determined accordingly 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 as 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 as 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 as 2 times the base picture size picture_size1. If the color subsampling of the color video frame is 4:4:4, the size of the frame is determined as 3 times the base picture size picture_size1. The size of the DPB can be determined as the number of frames to be stored in the DPB multiplied by the size of the frame according to the color subsampling.

[0136] Figure 9 An example of a process 900 of partitioning of an encoded video according to some embodiments of the present disclosure is shown. One or more computing devices (e.g., computing devices implementing video encoder 100) implement the operations shown in process 900 by executing suitable program code (e.g., program code implementing entropy encoding module 116). Process 900 is described with reference to some examples shown in the accompanying drawings for illustrative purposes. But other implementations are possible. Figure 9

[0137] At block 902, process 900 involves 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 Figure 6 As shown in the example of

[0138] ​​At block 904, including 906 to 914, the process 900 involves processing each CTU in the set of CTUs in the partition to encode the partition into bits. At block 906, the process 900 involves determining whether a parallel encoding mechanism has been 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 indicating that parallel encoding has been disabled and a value of 1 indicating that parallel encoding has been enabled. If it is determined that the parallel encoding mechanism has been enabled and that the current CTU is the first CTU of a CTU row, the process 900 involves setting a history counter StatCoeff to an initial value at block 908. As described above, if history-based Rice parameter derivation has been enabled, the initial value of the history counter can be set according to equation (5) or equation (6); otherwise, the initial value of the history counter is set to zero.

[0139] If it is determined that the parallel encoding mechanism has not been 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, the process 900 involves computing a Rice parameter for a TU in the CTU based on the history counter at block 910. As described above with reference to equation (1), the Rice parameter for the TU can be computed based on the history counter StatCoeff. Figure 6 to Figure 8 In detail, 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 a subsequently updated history counter in the current CTU.

[0140] At block 912, the process 900 involves encoding the TU in the CTU into a binary representation based on the computed Rice parameter (e.g., through a combination of TR and finite EGk as specified in the VVC specification). At block 914, the 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 CABAC as described above. At block 916, the process 900 involves outputting the encoded video bitstream.

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

[0142] At block 1002, the process 1000 involves accessing a bin string or a binary representation of 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 FIG. 2. As shown in the example of Figure 6 FIG. 3, each CTU includes one or more CUs, and each CTU includes a plurality of TUs for encoding.

[0143] At block 1004, including 1006 to 1014, 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. At block 1006, the process 1000 involves determining whether a parallel encoding mechanism has been 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 has been disabled and a value of 1 indicating that parallel encoding has been enabled. If it is determined that the parallel encoding mechanism has been enabled and that 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 described above, if history-based Rice parameter derivation has been enabled, the initial value of the history counter can be set according to equation (5) or equation (6); otherwise, the initial value of the history counter is set to zero.

[0144] If it is determined that the parallel encoding mechanism has not been enabled or that 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 computing a Rice parameter for a TU in the CTU based on the history counter at block 1010. As described in detail 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 computed 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 computed based on the history counter updated in the previous CTU or a subsequently updated history counter in the current CTU.

[0145] At block 1012, the process 1000 involves decoding the bin string or the binary representation of the TU in the CTU to coefficient values based on the computed Rice parameter (e.g., by a combination of TR and EGk as specified in the VVC specification). At block 1014, the process 1000 involves reconstructing pixel values of the TU in the CTU by, for example, dequantization and inverse transform as described above with reference to Figure 2 At block 1016, the process 1000 involves outputting the decoded partition of the video.

[0146] 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) is 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 permitted 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 (and thus aligned with) the dependencies between CTUs when performing parallel processing.

[0147] 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 one 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). For each CTU row except the first CTU row, a synchronization procedure of the Rice parameter derivation is applied before the first TU encoding. In the synchronization procedure, StatCoeff[cldx] is synchronized with the saved StatCoeffWpp[cldx] from the previous CTU row.

[0148] As described above, before the first TU in each CTU row is encoded, the variable HistValue is computed as follows:

[0149] HistValue[cldx] = 1 « StatCoeff[cldx]. (11)

[0150] If the current CTU row is the first CTU row of a partition, StatCoeff[cldx] can be initialized according to equation (5) or equation (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. StatCoeff can be updated once per TU by a process of exponential moving average as shown above with reference to equations (9) and (10) from the first non-zero Columb-Rice coded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]).

[0151] After encoding the last TU of the first CTU in the first CTU row, StatCoeff[cldx] can be saved as StatCoeffWpp[cldx] in the following storage step:

[0152] StatCoeffWpp[cldx] = StatCoeff[cldx]. (12)

[0153] Encoding of the remaining CTUs in the first CTU row can be performed in a similar manner as described above with respect to the first embodiment.

[0154] Prior to the first TU encoding in the second CTU row and any subsequent CTU rows, StatCoeff[cldx] can be obtained by a synchronization step:

[0155] StatCoeff[cldx] = StatCoeffWpp[cldx]. (13)

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

[0157] Possible VVC specification changes are specified as follows (changes are shown underlined).

[0158]

[0159] Alternative history-based rice parameter derivation

[0160] History-based Rice parameter derivation can be implemented in an alternative manner. In this alternative implementation, if a CTU is the first CTU in a partition (e.g., picture, slice, or tile), HistValue is initialized with an initial value of StatCoeff[cldx] as follows:

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

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

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

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

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

[0166] Once the history counter StatCoeff[cldx] is updated, HistValue is updated as shown in equation (17), and the updated HistValue is used for the derivation of the Rice parameter for the remaining abs_remainder and dec_abs_level syntax elements until this new StatCoeff[cldx] and HistValue[cldx] are updated again.

[0167] HistValue[cldx] = 1 « StatCoeff[cldx]. (17)

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

[0169] Change the clause 7.3.11.11 (Residual coding syntax) as follows (added parts are shown underlined):

[0170]

[0171]

[0172] To resolve the dependency conflict between parallel coding and the alternative history-based Rice parameter derivation, StatCoeff[cldx] and HistValue[cldx] for 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.

[0173] The present embodiment can also be implemented using storage synchronization procedures. For example, in the storage procedure, StatCoeff[cldx] and HistValue[cldx] can be saved in storage variables (e.g., StatCoeffWpp[cldx] as shown in equation (18) and HistValueWpp[cldx] as shown in equation (19)) after processing the last TU of the first CTU in each CTU row.

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

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

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

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

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

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

[0180] As described above, StatCoeff[cldx] can be updated once per TU from the first non-zero Golomb-Rice coded transform coefficient (abs_remainder[cldx] or dec_abs_level[cldx]) as shown in equation (15) or equation (16). Once the history counter StatCoeff[cldx] is updated, HistValue is updated according to equation (17), and the updated HistValue is used for the derivation of the Rice parameter for the remaining abs_remainder and dec_abs_level syntax elements until this new StatCoeff[cldx] and HistValue are updated again.

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

[0182]

[0183]

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

[0185] At block 1102, process 1100 involves 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 Figure 6 As shown in examples of

[0186] At block 1104, which includes blocks 1106-1118, process 1100 involves processing each CTU of the set of CTUs in the partition to encode the partition into bits. At block 1106, process 1100 involves determining whether a parallel encoding mechanism has been 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 indicating that parallel encoding has been disabled and a value of 1 indicating that parallel encoding has been enabled. If it is determined that the parallel encoding mechanism has been enabled and that the current CTU is the first CTU of a CTU row, process 1100 involves determining whether the current CTU row is the first CTU row in the partition at block 1107. If so, process 1100 involves setting a history counter StatCoeff to an initial value at block 1108. As described above, the initial value of the history counter can be set according to equation (5) or equation (6). If the current CTU row is not the first CTU row in the partition, process 1100 involves setting the history counter StatCoeff to a value stored in a history counter storage variable as shown in equation (13) or equation (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).

[0187] ​​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 value of the history counter is set at block 1108 or block 1109, process 1100 involves calculating the Rice parameters of the TUs in the CTU based on the history counter (and also based on the replacement variable HistValue if the replacement variable HistValue is also reset) at block 1110. As described above (e.g., with reference to Figure 8 Or in an alternative Rice parameter derivation), if the value of the history counter is reset in block 1108 or block 1109, the Rice parameters of the TUs in the CTU are calculated based on the reset history counter or the subsequently updated history counter. If the history counter is not reset in block 1108 or block 1109, the Rice parameters of the TUs in the CTU are calculated based on the history counter updated in the previous CTU or the subsequently updated history counter in the current CTU.

[0188] At block 1112, the process 1100 involves encoding the TUs in the CTU into binary representations based on the calculated Rice parameters (e.g., through a combination of TR and limited EGk as 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 bitstream of the video. For example, the encoding may be performed using CABAC as described above.

[0189] At block 1116, process 1100 involves determining whether parallel encoding is enabled and whether the CTU is the first CTU of the current CTU row. If so, 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 equation (18). In some examples, such as when utilizing alternative Rice parameter derivation, the value of the replacement variable HistValue may also be stored in a storage variable as shown in equation (19). At block 1120, process 1100 involves outputting the encoded video stream.

[0190] In some cases, a CTU in a non-first CTU row may be located at a partition boundary, for example, there is no CTU in the partition above the first CTU in the second CTU row. In these cases, the history counter of the CTU may be set to an initial value instead of a stored value. In this case, the history counter may be set to an initial value instead of a stored value. Figure 11 A new block 1107' is added between block 1107 and block 1109 to determine whether the CTU is at the boundary of a partition (e.g., the CTU does not have an upper adjacent 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 a stored value. Figure 11 The rest of the blocks can remain the same.

[0191] Figure 12 An example of a process 1200 for decoding a partition of a video is shown in accordance with some embodiments of the present disclosure. One or more computing devices implement the operations shown in Figure 12 by executing program code implementing the operations shown in Figure 12 by executing program code implementing the operations shown in

[0192] At block 1202, the process 1200 involves accessing a bin 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 was 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 Figure 6 As shown in the example of

[0193] At block 1204, which includes 1206 to 1218, the process 1200 involves processing the bin string for each CTU in the set of CTUs in the partition to generate decoded samples for the partition. At block 1206, the process 1200 involves determining whether a parallel encoding mechanism has been enabled and whether the current CTU is the first CTU of a CTU row. Parallel encoding can be indicated by a flag, with a value of 0 indicating that parallel encoding has been disabled and a value of 1 indicating that parallel encoding has been enabled. If it is determined that the parallel encoding mechanism has been enabled and that the current CTU is the first CTU of a CTU row, the process 1200 involves determining whether the current CTU row is the first CTU row in the partition at block 1207. If so, the process 1200 involves setting a history counter StatCoeff to an initial value at block 1208. As described above, the initial value of the history counter can be set in accordance with equation (5) or equation (6). If the current CTU row is not the first CTU row in the partition, the process 1200 involves setting the history counter StatCoeff to the value stored in the history counter storage variable as shown in equation (13) or equation (20) at block 1209. 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 of as shown in equation (21).

[0194] ​If it is determined that the parallel coding mechanism is not enabled or the current CTU is not the first CTU of a CTU row, or the value of the history counter is set after block 1208 or block 1209, process 1200 involves calculating the Rice parameter for the TUs in the CTU based on the history counter (and also the replacement variable HistValue if it is also reset) at block 1210. As described above (e.g., with reference to Figure 8 Alternatively, in an alternative Rice parameter derivation, if the value of the history counter is reset at block 1208 or block 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 block 1209, the Rice parameter for the TUs in the CTU is calculated based on the history counter updated in the previous CTU or a subsequently updated history counter in the current CTU.

[0195] At block 1212, process 1200 involves decoding the binary string and the binary representation of the TUs in the CTU into coefficient values based on the calculated Rice parameters (e.g., through the combination of TR and finite EGk specified in the VVC specification). At block 1214, process 1200 involves reconstructing the pixel values of the TUs in the CTU through, for example, the inverse quantization and inverse transform shown above with reference to Figure 2

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

[0197] In another embodiment, WPP or other parallel coding mechanism and history-based Rice parameter derivation are prevented from coexisting in a bitstream. 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:

[0198] 7.3.2.22 Sequence parameter set range extension syntax (additions shown underlined)

[0199]

[0200] ​

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

[0202]

[0203] Although in the above description, in the accompanying drawings (for example, Figure 6 ), TU is described and shown in FIG, but the same technology can be applied to transform block (TB). In other words, in the embodiments introduced above (including the drawings), TU can also represent TB.

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

[0205] Any suitable computing system may be used to perform the operations described herein. For example, Figure 13 Shows that it is possible to Figure 1 The video encoder 100 or Figure 2 13. In some embodiments, the computing device 1300 may include a processor 1312 that is communicatively coupled to a memory 1314 and executes computer-executable program code and / or accesses information stored in the memory 1314. The processor 1312 may include a microprocessor, an application-specific integrated circuit (ASIC), a state machine, or other processing device. The processor 1312 may include any number of processing devices, including one processing device. Such a processor may include or may be in communication with a computer-readable medium storing instructions that, when executed by the processor 1312, cause the processor to perform the operations described herein.

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

[0207] 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 illustrated computing device 1300 has an input / output (I / O) interface 1318 that 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. This communicative coupling can be achieved by any suitable means, such as via connections through a printed circuit board, via connections through a cable, via wireless transmission of communications, etc. Non-limiting examples of input devices 1320 include a touchscreen (e.g., one or more cameras to image a touch area or one or more pressure sensors to detect changes in pressure 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.

[0208] The computing device 1300 can execute program code that configures the processor 1312 to perform one or more operations described above with reference to the video encoder 100 or the video decoder 200. This 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. Figure 1 to Figure 12

[0209] 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 adapters, modems, etc. The computing device 1300 can transmit messages in electronic or optical signals through the network interface device 1324.

[0210] General considerations

[0211] Many specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, it will be appreciated that the claimed subject matter can be practiced without these specific details. In other instances, well-known methods, devices, or systems have not been described in detail so as not to obscure the claimed subject matter.

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

[0213] 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 dedicated computing device that implements one or more embodiments of the present invention. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings herein included in the software to be used to program or configure a computing device.

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

[0215] As used herein, "adapted to" or "configured to" is open and inclusive language that does not exclude devices adapted or configured to perform additional tasks or steps. Furthermore, the use of "based on" is open and inclusive, as a process, step, calculation, or other action that is "based on" one or more listed conditions or values ​​may actually be based on additional conditions or values ​​beyond those listed. The headings, lists, and numbering included herein are for ease of explanation only and are not limiting.

[0216] Although the subject matter has been described in detail with reference to specific embodiments thereof, it is understood that those skilled in the art, after obtaining an understanding of the foregoing, can readily provide modifications, variations, and equivalents of such embodiments. Therefore, it should be understood that the present disclosure is presented for purposes of illustration and not limitation, and does not exclude the inclusion of such modifications, variations, and / or additions as would be apparent to one of ordinary skill in the art.

Claims

1. A method for decoding a video from a video bitstream encoded using Versatile Video Coding (VVC), characterized in that, The method comprises: determining a bit depth of samples of the video based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8; determining a size of a decoded picture buffer (DPB) based on a video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8, wherein a value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in a range of 0 to 8; allocating storage space with the determined size of the DPB; decoding the video bitstream based on the determined bit depth, obtaining and storing decoded pictures in the DPB; and outputting the decoded pictures; wherein decoding the video bitstream based on the determined bit depth comprises: accessing a binary string representing a partition of the video, the partition comprising a 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 and in response to determining that parallel coding has been enabled and the CTU is a first CTU of a current CTU row, determining whether the current CTU row is a first CTU row in the partition; in response to determining that the current CTU row is the first CTU row in the partition, setting a history counter for a color component used to calculate a Rice parameter to an initial value based on the determined bit depth; in response to determining that the current CTU row is not the first CTU row in the partition, setting the history counter for the color component to a value stored in a history counter storage variable; decoding the CTU, including: calculating the Rice parameter for a TU in the CTU based on the value of the history counter; decoding the binary string corresponding to the TU in the CTU into coefficient values of the TU based on the calculated Rice parameter; and determining pixel values of the TU in the CTU from the coefficient values; and after decoding the CTU, in response to determining that parallel coding has been enabled and the CTU is the first CTU of the current CTU row, storing a current value of the history counter in the history counter storage variable.

2. The method of claim 1, wherein, decoding the video bitstream, obtaining and storing decoded pictures in the DPB comprises: decoding a first portion of the video bitstream, obtaining and storing a first set of pictures in the DPB; and decoding a second portion of the video bitstream into a second set of pictures by using the first set of pictures in the DPB as reference pictures.

3. The method of claim 1, wherein, further comprising: reordering one or more decoded pictures in the DPB according to an output order; and outputting the one or more decoded pictures according to the output order.

4. The method of claim 1, wherein, further comprising: keeping one or more decoded pictures in the DPB for a period of time; and outputting the one or more decoded pictures after the period of time has elapsed. ​ 5. A non-transitory computer-readable medium having stored thereon program code executable by one or more processing devices to perform: Based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, a bit depth of samples of a video is determined, wherein the value of an SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8; a size of a decoded picture buffer (DPB) of a video is determined based on a video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8 included in a video bitstream of the video, wherein the video bitstream is encoded using Versatile Video Coding (VVC), and the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in a range of 0 to 8; allocating storage space having the determined size of the DPB; decoding the video bitstream based on the determined bit depth, obtaining and storing decoded pictures in the DPB; and outputting the decoded pictures; wherein decoding the video bitstream based on the determined bit depth comprises: accessing a binary string representing a partition of the video, the partition including a 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 and in response to determining that parallel coding has been enabled and the CTU is a first CTU of a current CTU row, determining whether the current CTU row is a first CTU row in the partition; in response to determining that the current CTU row is the first CTU row in the partition, setting a history counter for a color component used to calculate a Rice parameter to an initial value based on the determined bit depth; in response to determining that the current CTU row is not the first CTU row in the partition, setting the history counter for the color component to a value stored in a history counter storage variable; decoding the CTU, including: calculating the Rice parameter for a TU in the CTU based on the value of the history counter; based on the calculated Rice parameter, decoding the binary string corresponding to the TU in the CTU into coefficient values for the TU; and determining pixel values for the TU in the CTU from the coefficient values; and after decoding the CTU, in response to determining that parallel coding has been enabled and the CTU is the first CTU of the current CTU row, storing a current value of the history counter in the history counter storage variable.

6. The non-transitory computer-readable medium of claim 5, wherein, the decoding the video bitstream, obtaining and storing decoded pictures in the DPB comprises: decoding a first portion of the video bitstream, obtaining and storing a first set of pictures in the DPB; and decoding a second portion of the video bitstream into a second set of pictures using the first set of pictures in the DPB as reference pictures.

7. The non-transitory computer-readable medium of claim 5, wherein, the operations further comprise: reordering one or more decoded pictures in the DPB according to an output order; and outputting the one or more decoded pictures according to the output order.

8. The non-transitory computer-readable medium of claim 5, wherein, the operations further comprise: retaining one or more decoded pictures in the DPB for a period of time; and outputting the one or more decoded pictures after the period of time.

9. The non-transitory computer-readable medium of claim 5, wherein, The operations further include: determining a bit depth of samples of the video based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8, wherein decoding the video bitstream is performed based on the determined bit depth.

10. A system, characterized by comprise: a processing device; and a non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations of: determining a bit depth of samples of a video based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8, wherein decoding a video bitstream of the video is performed based on the determined bit depth. comprise: a processing device; and a non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations of: determining a bit depth of samples of a video based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8, wherein decoding a video bitstream of the video is performed based on the determined bit depth. wherein decoding the video bitstream based on the determined bit depth comprises: accessing a bin string representing a partition of the video, the partition comprising a 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 and in response to determining that parallel coding has been enabled and the CTU is a first CTU of a current CTU row, determining whether the current CTU row is a first CTU row in the partition; in response to determining that the current CTU row is the first CTU row in the partition, setting a history counter for a color component used to calculate a Rice parameter to an initial value based on the determined bit depth; in response to determining that the current CTU row is not the first CTU row in the partition, setting the history counter for the color component to a value stored in a history counter storage variable; decoding the CTU, including: calculating the Rice parameter for a TU in the CTU based on the value of the history counter; decoding the bin string corresponding to the TU in the CTU to coefficient values of the TU based on the calculated Rice parameter; and determining pixel values of the TU in the CTU from the coefficient values; and After decoding the CTU, in response to determining that parallel coding has been enabled and the CTU is the first CTU of the current CTU row, storing a current value of the history counter in the history counter storage variable.

11. The system of claim 10, wherein, The decoding the video bitstream to obtain and store decoded pictures in the DPB includes: decoding a first portion of the video bitstream to obtain and store a first set of pictures in the DPB; and decoding a second portion of the video bitstream to a second set of pictures using the first set of pictures in the DPB as reference pictures.

12. The system of claim 10, wherein, The operations further include: reordering one or more decoded pictures in the DPB according to an output order; and outputting the one or more decoded pictures according to the output order.

13. The system of claim 10, wherein, The operations further include: retaining one or more decoded pictures in the DPB for a period of time; and outputting the one or more decoded pictures after the period of time has elapsed.

14. The system of claim 10, wherein, The operations further include: determining a bit depth of samples of the video based on a sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein a value of the SPS syntax element sps_bitdepth_minus8 is in a range of 0 to 8, wherein the decoding the video bitstream is performed based on the determined bit depth.

Images