Bitstream decoding method, encoding method, and non-volatile machine-readable storage medium

Abstract

FIELD: video encoding.SUBSTANCE: increased efficiency of video encoding is achieved by determining the bit depth of image samples based on the sequence parameter set (SPS) syntax element. The decoded picture buffer (DPB) size is determined based on the video parameter set (VPS) syntax element. A binary string representing a breakdown of an image containing a set of code tree units (CTUs) is accessed. For each CTU, before decoding the CTU and in response to a determination that the CTU is the first CTU of the current CTU row, it is determined whether the current CTU row is the first CTU row in the breakdown. If the current CTU row is the first CTU row in the breakdown, the history counter for the color component for calculating Rice parameters is set to the initial value based on the specified bit depth. Otherwise, set the history counter for the colour component to the value stored in the history counter storage variable. Rice parameters are calculated for transformation nodes (TUs) in CTUs based on the history counter value.EFFECT: increasing the efficiency of video encoding.7 cl, 13 dwg, 2 tbl

Description

Cross-reference to related applications

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

[0002] The present invention generally relates to computer-implemented methods and systems for video processing. In particular, the present invention provides a bitstream decoding method, an encoding method, and a non-transitory computer-readable storage medium. State of the art

[0003] Ubiquitous camera-equipped devices such as smartphones, tablets, and computers have made it even easier to capture videos and images. However, the data volume of even a short video can be significantly large. Video coding technology (including video encoding and decoding) enables video data to be compressed into smaller sizes, thereby enabling the storage and transmission of various types of videos. Video coding has been used in a wide range of applications, such as digital television broadcasting, video transmission over the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing), DVD and Blu-ray discs, and more. To reduce the storage space required for video storage and / or network bandwidth consumption for video transmission, it is desirable to improve the efficiency of video coding schemes. The essence of the invention

[0004] Some embodiments include deriving history-based Rice parameters for parallel wavefront processing in video coding.

[0005] In the first embodiment, a method for decoding a bitstream encoded using universal video coding (VVC) is presented, wherein the method includes: determining the bit depth of image samples based on the sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein the value of the SPS syntax element sps_bitdepth_minus8 is in the range from 0 to 8; determining the size of a buffer for a decoded picture (DPB) based on the video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8, wherein the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in the range from 0 to 8; allocating a storage space with a determined size of the DPB; obtaining and storing a decoded picture in the DPB by decoding the bitstream based on the determined bit depth; and outputting the decoded picture.

[0006] In a preferred embodiment, obtaining and storing a decoded image in a DPB by decoding a bitstream comprises: obtaining and storing a first set of images in a DPB by decoding a first portion of a bitstream; and decoding a second portion of the bitstream into a second set of images by using the first set of images in the DPB as reference images.

[0007] In a preferred embodiment, the method further includes: rearranging one or more decoded images in the DPB according to the output order; and outputting the one or more decoded images according to the output order.

[0008] In a preferred embodiment, the method further includes: storing one or more decoded images in the DPB for a certain period of time; and outputting the one or more decoded images after the certain period of time has elapsed.

[0009] In a preferred embodiment, decoding a bitstream based on a determined bit depth comprises: accessing a binary string representing a partition of an image, wherein the partition comprises a plurality of coding tree nodes (CTUs) forming one or more rows of the CTUs; for each CTU of the plurality of CTUs in the partition, before decoding the CTU, determining that parallel encoding capability is provided and that the CTU is the first CTU of the current row of the CTUs among the one or more rows of the CTUs in the partition; in response to determining that parallel encoding capability is provided and that the CTU is the first CTU of the current row of the CTUs in the partition, setting a history counter for a color component for calculating Rician parameters to an initial value based on the determined bit depth; decoding the CTU, comprising: calculating Rician parameters for transform nodes (TUs) in the CTUs based on the history counter;decoding a binary string corresponding to a plurality of TUs in a CTU into coefficient values ​​of the set of TUs based on the calculated Rice parameters; and determining pixel values ​​for the set of TUs in the CTU from the coefficient values; and outputting a decoded image breakdown containing the decoded set of CTUs in the breakdown.

[0010] In a preferred embodiment, decoding a bitstream based on a determined bit depth comprises: accessing a binary string representing a partition of an image, wherein the partition comprises a plurality of coding tree nodes (CTUs) forming one or more rows of CTUs; for each CTU of the plurality of CTUs in the partition, before decoding the CTU and in response to determining that parallel encoding capability is provided and that the CTU is the first CTU of the current row of CTUs among the one or more rows of CTUs in the partition, determining whether the current row of CTUs is the first row of CTUs in the partition; in response to determining that the current row of CTUs is the first row of CTUs in the partition, setting a history counter for a color component for calculating Rice parameters to an initial value based on the determined bit depth;in response to determining that the current row of the CTU is not the first row of the CTU in the breakdown, setting a history counter for the color component to a value stored in a history counter storage variable; decoding the CTU, comprising: calculating Rician parameters for transform nodes (TUs) in the CTU based on the history counter value; decoding a binary string corresponding to a plurality of TUs in the CTU into coefficient values ​​of the plurality of TUs based on the calculated Rician parameters; and determining pixel values ​​for the plurality of TUs in the CTU from the coefficient values; and after decoding the CTU, in response to determining that parallel encoding is enabled and that the CTU is the first CTU of the current row of the CTU, storing the current history counter value in the history counter storage variable;

[0011] In the second aspect of the present invention, a coding method using VVC is provided, comprising: determining the bit depth of samples of an image to be coded; determining the value of an SPS syntax element sps_bitdepth_minus8, wherein the value of the SPS syntax element sps_bitdepth_minus8 is in the range from 0 to 8, and encoding the value of the SPS syntax element sps_bitdepth_minus8 into a bit stream; determining the value of a VPS syntax element vps_ols_dpb_bitdepth_minus8, wherein the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in the range from 0 to 8, and encoding the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 into a bit stream; determining the size of the DPB based on the VPS syntax element vps_ols_dpb_bitdepth_minus8; allocating a storage space with the determined size DPB; receiving and storing an image in DPB; and encoding the image based on a specified bit depth.

[0012] In a preferred embodiment, obtaining and storing an image in a DPB comprises: obtaining and storing a first set of images in the DPB; encoding the first set of images into a first portion of a bitstream; and encoding a second set of images into a second portion of the bitstream by using the first set of images in the DPB as reference images.

[0013] In a preferred embodiment, encoding an image based on a certain bit depth comprises: performing a partition of an image, wherein the partition comprises a plurality of CTUs forming one or more rows of CTUs; for each CTU of the plurality of CTUs in the partition, before encoding the CTU, determining that parallel encoding is possible and that the CTU is the first CTU of a current row of CTUs among the one or more rows of CTUs in the partition, in response to determining that parallel encoding is possible and that the CTU is the first CTU of a current row of CTUs in the partition, setting a history counter for a color component for calculating Rician parameters to an initial value based on the certain bit depth; encoding the CTU, comprising: calculating Rician parameters for the TUs in the CTUs based on the value of the history counter; encoding coefficient values ​​corresponding to the TUs in the CTUs into a binary string based on the calculated Rician parameters;and transferring the binary string TU to CTU in a bit stream.

[0014] In a preferred embodiment, encoding an image based on a certain bit depth comprises: performing a partition of an image, wherein the partition comprises a plurality of CTUs forming one or more rows of CTUs; for each CTU of the plurality of CTUs in the partition, before encoding the CTU, determining that parallel encoding is possible and that the CTU is the first CTU of the current row of CTUs among the one or more rows of CTUs in the partition, determining whether the current row of CTUs is the first row of CTUs in the partition; in response to determining that the current row of CTUs is the first row of CTUs in the partition, setting a history counter for a color component for calculating Rice parameters to an initial value based on the certain bit depth; in response to determining that the current row of CTUs is not the first row of CTUs in the partition, setting the history counter for the color component to a value, to a value stored in a history counter storage variable;encoding a CTU comprising: calculating Rician parameters for a TU in the CTU based on a value of a history counter; encoding values ​​of coefficients corresponding to the TU in the CTU into a binary string based on the calculated Rician parameters; and transmitting the binary string of the TU in the CTU into a bit stream; and after encoding the CTU, in response to determining that parallel encoding is enabled and that the CTU is the first CTU in the current CTU row, storing the current value of the history counter in a history counter storage variable.

[0015] In a third embodiment, a non-volatile computer-readable storage medium is provided that stores a bit stream and a computer program that, when executed by a processor, causes the processor to execute the above-mentioned encoding method with generation of the bit stream.

[0016] These illustrative embodiments are not intended to limit or define the invention, but rather to provide examples to aid in its understanding. Additional embodiments are discussed in the detailed description, and further description is provided therein. Brief description of graphic materials

[0017] The features, embodiments and advantages of the present invention will be more clearly understood when the following detailed description is read with reference to the accompanying drawings.

[0018] Fig. 1 is a block diagram showing an example of a video encoder configured to implement the embodiments presented in this document.

[0019] Fig. 2 is a block diagram showing an example of a video decoder configured to implement the embodiments presented in this document.

[0020] Fig. 3 illustrates an example of splitting a node of a coding tree of an image in a video according to some embodiments of the present invention.

[0021] Fig. 4 illustrates an example of partitioning a coding node of a coding tree node according to some embodiments of the present invention.

[0022] Fig. 5 shows an example of a coding block with a predetermined order of processing elements of the coding block.

[0023] Fig. 6 shows an example of a template sample for calculating the local sum variable for a coefficient located near the boundary of transformation nodes.

[0024] Fig. 7 shows an example of a tile for which parallel wavefront processing is enabled.

[0025] Fig. 8 shows an example of a frame, tiles, and code tree nodes contained in the frame for which a history counter is calculated according to some embodiments of the present invention.

[0026] Fig. 9 illustrates an example of a split encoding process for video according to some embodiments of the present invention.

[0027] Fig. 10 illustrates an example of a video split decoding process according to some embodiments of the present invention.

[0028] Fig. 11 illustrates another example of a split encoding process for video according to some embodiments of the present invention.

[0029] Fig. 12 illustrates another example of a split decoding process for video according to some embodiments of the present invention.

[0030] Fig. 13 shows an example of a computing system that can be used to implement some embodiments of the present invention. Detailed description

[0031] Various embodiments provide for history-based Rice parameter derivation for parallel wavefront processing in video coding. As discussed above, increasingly large amounts of video data are generated, stored, and transmitted. It is desirable to improve the efficiency of video coding technology so that less data is used to represent video without compromising the visual quality of the decoded video. One method for improving coding efficiency is entropy coding, which compresses the processed video samples into a binary bitstream using as few bits as possible. On the other hand, since video typically contains a large amount of data, it is desirable to reduce the processing time during coding (encoding and decoding). For this purpose, parallel processing can be used in video coding and decoding.

[0032] In entropy coding, video samples are binarized to form binary numbers, and coding algorithms such as context-adaptive binary arithmetic coding (CABAC) can further compress the binary numbers into bits. Binarization requires the calculation of a binarization parameter, such as the Rice parameter, used in a combination of the Truncated Rice (TR) binarization process and the Exponential Golomb-bounded k-order (EGk) method, as described in the Universal Video Coding (VVC) specification. History-based Rice parameter derivation is used to improve coding efficiency.In this history-based derivation of Rician parameters, the Rician parameter for a transformation node (TU) in the current code tree node (CTU) of a breakdown (e.g., an image, slice, or tile) is derived from a history counter (denoted as StatCoeff) calculated based on the coefficients in previous TUs in the current CTU and previous CTUs in the breakdown. The history counter is then used to derive a replacement variable (denoted as HistValue) to be used to derive the Rician parameter. The history counter can be updated during TU processing. In some examples, the replacement variable remains the same for the TU even if the history counter is updated.

[0033] The dependency between the current CTU and previous CTUs in the history counter calculation partition may conflict with, limit, or even prevent the use of parallel processing, leading to unstable or inefficient video coding. Various embodiments described herein address these issues by reducing or eliminating the dependency between certain CTUs in the partition, allowing parallel processing to speed up video processing, or by detecting and resolving conflicts before they occur. The following non-limiting examples are provided to illustrate certain embodiments.

[0034] In one embodiment, the dependency between multiple CTUs in different CTU rows when calculating the history counter is removed, thereby eliminating dependency conflicts during parallel processing. For example, the history counter can be reinitialized for each CTU row of the breakdown. Before calculating the Rician parameter for the first CTU in the CTU row, the history counter can be set to the initial value. The subsequent history counter can be calculated based on the history counter value in previous TUs in the same CTU rows. In this way, the dependency of multiple CTUs when deriving history-based Rician parameters is limited within the same CTU row and does not interfere with parallel processing between different CTU rows, while still benefiting from the coding efficiency achieved by deriving history-based Rician parameters. Furthermore, the process of deriving history-based Rician parameters is simplified and the computation complexity is reduced.

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

[0036] Some examples use an alternative history-based derivation of Rice parameters. In this alternative history-based derivation of Rice parameters, the replacement variable HistValue is updated as soon as the history counter StatCoeff is updated during TU processing. To avoid dependency conflicts during parallel coding, the dependency between CTUs in calculating the history counter can be similarly limited to no more than N CTUs. A store-synchronization process can be implemented similarly. After processing the last TU in the first CTU of a CTU row, each of the history counter and replacement variable can be stored in a storage variable. Then, before processing the first TU in the first CTU of the subsequent CTU row, the history counter and replacement variable can be synchronized with the stored value in the corresponding storage variable.

[0037] Thus, the inter-CTU dependency in two consecutive CTU rows during history counter calculation is constrained to be no greater than (i.e., aligned with) the inter-CTU dependency during parallel coding. As a result, history counter calculation does not interfere with parallel processing while still benefiting from the coding efficiency achieved by deriving Rice parameters from history.

[0038] Alternatively, parallel processing and history-based Rician parameter derivation are not allowed to coexist in a bitstream. For example, a video encoder can determine whether parallel processing is allowed. If parallel processing is allowed, history-based Rician parameter derivation is prohibited; otherwise, history-based Rician parameter derivation is allowed. Similarly, if the video encoder determines that history-based Rician parameter derivation is allowed, parallel processing is prohibited, and vice versa.

[0039] Using the Rician parameter defined as discussed above, the video encoder can binarize the residual prediction data (e.g., the quantized transform coefficients of the residuals) into binary numbers and use entropy coding algorithms to further compress the binary numbers into bits to be included in the video bitstream. On the decoder side, the decoder can decode the bitstream back into binary numbers and determine the Rician parameter using any method or any combination of the methods described above, and subsequently determine the coefficients from the binary numbers. The coefficients can be further dequantized and detransformed to reconstruct the video blocks for display.

[0040] In some embodiments, the bit depth of the video samples (for example, the bit depth used to determine the initial value of the StatCoeff history counter) may be determined according to the sps_bitdepth_minus8 sequence parameter set (SPS) syntax element. The value of the sps_bitdepth_minus8 SPS syntax element is in the range from 0 to 8. Similarly, the size of the decoded picture buffer (DPB) used to store decoded pictures may be determined based on the vps_ols_dpb_bitdepth_minus8 video parameter set (VPS) syntax element. The value of the vps_ols_dpb_bitdepth_minus8 VPS syntax element is in the range from 0 to 8. According to the determined DPB size, storage space may be allocated for the DPB. The determined bit depth and DPB may be used throughout the decoding of the video bitstream into pictures.

[0051] As described in this document, some embodiments provide improvements in video coding efficiency and computational efficiency by coordinating the derivation of history-based Rician parameters with parallel coding. This avoids conflicts between the derivation of history-based Rician parameters and parallel coding, thereby improving the stability of the coding process. Furthermore, by limiting the dependency between CTUs in the derivation of history-based Rician parameters to no more than the dependency in parallel coding, coding efficiency can still be achieved through the derivation of history-based Rician parameters without sacrificing the computational efficiency of the coding process. These methods may become an effective coding tool in future video coding standards.

[0042] With reference to the drawings, Fig. 1 is a block diagram showing an example of a video encoder 100 configured to implement the embodiments presented in this document. In the example shown in Fig. 1, the video encoder 100 comprises a partitioning unit 112, a transform unit 114, a quantization unit 115, an inverse quantization unit 118, an inverse transform unit 119, an in-loop filter unit 120, an intra-prediction unit 126, an intermediate prediction unit 124, a motion estimation unit 122, a buffer 130 for a decoded image, and an entropy encoding unit 116.

[0043] The input data of the video encoder 100 is an input video 102 containing a sequence of images (also called frames or pictures). In a block-based video encoder, for each of the images, the video encoder 100 uses a partitioning module 112 to partition the image into blocks 104, and each block contains a plurality of pixels. Blocks can be macroblocks, coding tree nodes, coding nodes, prediction nodes, and / or prediction blocks. One image can contain blocks of different sizes, and the block partitions of different video images can also differ. Each block can be encoded using different predictions, such as intra-prediction or intermediate prediction, or intra-intermediate hybrid prediction.

[0044] Typically, the first picture of the video signal is an intra-predicted picture, which is encoded using only intra-prediction. In the intra-prediction mode, a block of a picture is predicted using only data from the same picture. An intra-predicted picture can be decoded without information from other pictures. To perform intra-prediction, the video encoder 100 shown in Fig. 1 can use an intra-prediction unit 126. The intra-prediction unit 126 is configured to use reconstructed samples in reconstructed blocks 136 of adjacent blocks of the same picture to generate an intra-prediction block (prediction block 134). The intra-prediction is performed according to the intra-prediction mode selected for the block.Video encoder 100 then calculates the difference between block 104 and intra-prediction block 134. This difference is called residual block 106.

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

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

[0047] Quantization of coefficients / samples within a block can be performed independently, and this type of quantization method is used in some existing video compression standards, such as H.264 and HEVC. For a block of size N by M, a specific scan order can be used to transform the two-dimensional coefficients of the block into a one-dimensional array for coefficient quantization and encoding. Coefficient quantization within a block can use scan order information. For example, the quantization of a given coefficient in a block can depend on the status of the previous quantized value in the scan order. To further improve coding efficiency, more than one quantizer can be used. Which quantizer is used to quantize the current coefficient depends on the information preceding the current coefficient in the encoding / decoding scan order. This quantization approach is called dependent quantization.

[0048] The degree of quantization can be adjusted using quantization step sizes. For example, for scalar quantization, different quantization step sizes can be applied to achieve finer or coarser quantization. Smaller quantization step sizes correspond to finer quantization, while larger quantization step sizes correspond to coarser quantization. The quantization step size can be specified by the quantization parameter (QP). The quantization parameters are provided in the encoded video bitstream so that the video decoder can apply the same quantization parameters for decoding.

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

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

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

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

[0053] The intermediate prediction module 124 uses the motion vector(s) together with other intermediate prediction parameters to perform motion compensation to generate a prediction of the current block, i.e., the intermediate prediction block 134. For example, based on the motion vector(s), the intermediate prediction module 124 can determine the location of the prediction block(s) pointed to by the motion vector(s) in the corresponding reference image(s). If there is more than one prediction block, these prediction blocks are combined with certain weight values ​​to generate the prediction block 134 for the current block.

[0054] For intermediately predicted blocks, video encoder 100 may subtract intermediate prediction block 134 from block 104 to generate residual block 106. Residual block 106 may be transformed, quantized, and entropy-coded in the same manner as the residuals of the intra-predicted block discussed above. Similarly, reconstructed block 136 of the intermediately predicted block may be obtained by inverse quantization, inverse transformation of the residual, and subsequent combination with the corresponding prediction block 134.

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

[0056] Fig. 2 shows an example of a video decoder 200 configured to implement the embodiments presented in this document. The video decoder 200 processes the encoded video 202 in a bitstream and generates decoded images 208. In the example shown in Fig. 2, the video decoder 200 comprises an entropy decoding unit 216, an inverse quantization unit 218, an inverse transform unit 219, an in-loop filter unit 220, an intra-prediction unit 226, an intermediate prediction unit 224, and a buffer 230 for the decoded image.

[0057] Entropy decoding unit 216 is configured to perform entropy decoding of encoded video 202. Entropy decoding unit 216 decodes quantized coefficients, coding parameters, including intra-prediction parameters and intermediate-prediction parameters, and other information. In some examples, entropy decoding unit 216 decodes the bitstream of encoded video 202 into binary representations and then transforms the binary representations into quantization levels for the coefficients. Then, the entropy-decoded coefficients are inversely quantized by inverse quantization unit 218 and subsequently inversely transformed by inverse transform unit 219 into the pixel domain. Inverse quantization unit 218 and inverse transform unit 219 operate similarly to inverse quantization unit 118 and inverse transform unit 119, respectively, as described above with respect to FIG. 1.The inversely transformed residual block may be added to the corresponding prediction block 234 to generate the reconstructed block 236. For blocks in which the transform is omitted, the inverse transform module 219 is not applied to these blocks. The dequantized samples generated by the inverse quantization module 118 are used to generate the reconstructed block 236.

[0058] The prediction block 234 of a specific block is generated based on the prediction mode of the block. If the block encoding parameters indicate that the block is intra-predictable, the reconstructed block 236 of the reference block in the same image can be supplied to the intra-prediction unit 226 to generate the prediction block 234 for the block. If the block encoding parameters indicate that the block is intermediate-predictable, the prediction block 234 is generated by the intermediate-prediction unit 224. The intra-prediction unit 226 and the intermediate-prediction unit 224 function similarly to the intra-prediction unit 126 and the intermediate-prediction unit 124 in FIG. 1, respectively.

[0059] As discussed above with respect to FIG. 1, intermediate prediction involves one or more reference pictures. Video decoder 200 generates decoded pictures 208 for the reference pictures by applying in-loop filter module 220 to reconstructed blocks of reference pictures. Decoded pictures 208 are stored in decoded picture buffer 230 for use by intermediate prediction module 224 and for output.

[0060] Referring to Fig. 3, Fig. 3 shows an example of dividing a coding tree node of an image in a video according to some embodiments of the present invention. As discussed above with respect to Figs. 1 and 2, in order to encode a video image, the image is divided into blocks, such as CTUs (coding tree nodes) 302 in VVC, as shown in Fig. 3. For example, CTUs 302 can be blocks of 128x128 pixels. CTUs are processed according to an order, such as the order shown in Fig. 3. In some examples, each CTU 302 in an image can be divided into one or more CUs (coding nodes) 402, as shown in Fig. 4, which can be further divided into prediction nodes or transform nodes (TUs) for prediction and transform. Depending on the coding schemes, CTU 302 can be divided into CUs 402 in different ways.For example, in VVC, CUs 402 can be rectangular or square and can be encoded without additional partitioning into prediction nodes or transformation nodes. Each CU 402 can be as large as its root CTU 302 or represent subdivisions of the root CTU 302 within a 4x4 block. As shown in Fig. 4, the partitioning of CTU 302 into multiple CUs 402 in VVC can be a quadtree-based partition, a binary tree-based partition, or a ternary tree-based partition. In Fig. 4, solid lines indicate a quadtree-based partition, and dotted lines indicate a binary or ternary tree-based partition.

[0061] As discussed above with respect to Figs. 1 and 2, quantization is used to reduce the dynamic range of block elements in a video signal so that fewer bits are used to represent the video signal. In some examples, before quantization, an element at a particular block position is called a coefficient. After quantization, the quantized value of the coefficient is called a quantization level or level. Quantization typically consists of dividing by a quantization step size and then rounding, while inverse quantization consists of multiplying by the quantization step size. This quantization process is also called scalar quantization. Quantization of coefficients within a block can be performed independently, and this type of independent quantization method is used in some existing video compression standards, such as H.264, HEVC, etc. Other examples use dependent quantization, such as in VVC.

[0062] For a block of size N by M, a specific scan order may be used to transform the two-dimensional coefficients of the block into a one-dimensional array for quantization and encoding of the coefficients, and the same scan order is used for both encoding and decoding. Fig. 5 shows an example of a coding unit (such as a transform node (TU)) with a predetermined scan order for processing the coefficients of the coding unit. In this example, the coding unit 500 has a size of 8 x 8, and processing starts from the lower right corner at a position and ends in the upper left corner If block 500 is a transformed block, then the predetermined order shown in Fig. 5 starts from the highest frequency to the lowest frequency. In some examples, block processing, such as quantization and binarization, starts from the first non-zero element of the block according to the predetermined scan order. For example, if the coefficients at locations - all are zero, and the coefficient in is non-zero, then processing begins at the coefficient in and is performed for each coefficient after in scanning order.

[0063] Residual coding

[0064] Residual coding is used to transform quantization levels into a bitstream during video encoding. After quantization, there are quantization levels for transformation unit (TU) coding unit. These Levels can be zero or nonzero values. Nonzero levels will be further binarized to form binary numbers if the levels are not binary. Context-adaptive binary arithmetic coding (CABAC) can further compress binary numbers into bits. Furthermore, there are two types of coding methods based on context modeling. Specifically, one method adaptively updates the context model according to adjacent encoded information. This method is called the context-aware coding method, and binary numbers encoded in this way are called context-encoded binary numbers. In contrast, the other method assumes that the probability of 1 or 0 is always 50% and therefore always uses fixed-context modeling without adaptation. This type of method is called the bypass method, and binary numbers encoded in this way are called bypassed binary numbers.

[0065] For the regular residual coding (RRC) block in VVC, the position of the last non-zero level is defined as the position of the last non-zero level in the coding scan order. The two-dimensional coordinate representation (last_sig_coeff_x and last_sig_coeff_y) of the last non-zero level contains 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, last_sig_coeff_y_suffix. The syntax elements last_sig_coeff_x_prefix and last_sig_coeff_y_prefix are first encoded using the context coding method. If last_sig_coeff_x_suffix and last_sig_coeff_y_suffix are present, they are encoded using the bypass method. An RRC block may consist of several predefined subblocks. The sb_coded_flag syntax element is used to indicate whether the current subblock has all levels equal to zero. If sb_coded_flag is 1, the current subblock contains at least one non-zero coefficient.If sb_coded_flag is 0, all coefficients in the current sub-block will be zero. However, sb_coded_flag for the last non-zero sub-block, which has the last non-zero level, is obtained as 1 from last_sig_coeff_x and last_sig_coeff_y according to the coding scan order without encoding into the bitstream. Moreover, sb_coded_flag for the upper-left sub-block, which contains the DC position, is also obtained as 1 without encoding into the bitstream. The sb_coded_flag syntax elements in the bitstream are encoded using the context coding method. RRC will encode sub-block by sub-block, starting from the last non-zero sub-block, with the reverse coding scan order, as discussed above with respect to Fig. 5.

[0066] To ensure worst-case throughput, a predefined value of remBinsPass1 is used to limit the maximum number of context-coded binaries. Within a sub-block, RRC will encode the level of each position with the reverse coding scan order. If remBinsPass1 is greater than 4, when coding the current level, a flag called sig_coeff_flag is first encoded into the bitstream to indicate whether the level is zero or non-zero. If the level is non-zero, abs_level_gtx_flag[n][0], where n is the index in the scan order of the current position within the sub-block, is used to indicate whether the absolute level is 1 or greater than 1. If the absolute level is greater than 1, par_level_flag will be encoded to indicate whether the level is an odd or even number in VVC, and then abs_level_gtx_flag[n][1] will be present.The par_level_flag and abs_level_gtx_flag[n][1] flags are also used together to indicate that the level is 2 or 3, or greater than 3. After encoding each of the above syntax elements as a context-encoded binary number, the value of remBinsPass1 will be decremented by one.

[0067] If the absolute level is greater than 3 or the remBinsPass1 value is not greater than 4, two more syntax elements, abs_remainder and dec_abs_level, can be encoded as bypass-encoded binary numbers for the remaining level after encoding the aforementioned binary numbers using context encoding. In addition, the sign of each level within the block will also be encoded to represent the quantization level, and they are encoded as bypass-encoded binary numbers.

[0068] Another residual encoding method uses abs_level_gtxX_flag and the residual level to enable conditional parsing of syntax elements for encoding the residual block level, and the corresponding binary conversion of the absolute level value is shown in Table 1. In this case, abs_level_gtxX_flag describes whether the absolute level value 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 from 0 to N-1, the abs_level_gtx(Y+1) flag will not be present. If abs_level_gtxY_flag is 1, the abs_level_gtx(Y+1) flag will be present. Moreover, if abs_level_gtxN_flag is 0, the residual level will not be present. When abs_level_gtxN_flag is 1, the remaining level will be present, and it represents the value after (N+1) are removed from the level.Generally, abs_level_gtxX_flag is encoded by context encoding method, and the residual level is encoded by bypass encoding method accordingly. Table 1. Residual encoding based on abs_level_gtxX_flag and residual. 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 …

[0069] For a block encoded in transform-skip residual coding (TSRC) mode, TSRC will encode subblock by subblock, starting from the upper-left subblock in coding scan order. Similarly, the sb_coded_flag syntax element is used to indicate whether the current subblock has all residuals equal to zero or not. All sb_coded_flag syntax elements for all subblocks are encoded into the bitstream, except for the last subblock when a certain condition occurs. If all sb_coded_flags are not equal to 1 for all subblocks before the last subblock, sb_coded_flag will be received as 1 for the last subblock, and this flag is not encoded into the bitstream. To ensure worst-case throughput, a predefined RemCcbs value is used to limit the maximum binary numbers with context encoding.If the current subblock has non-zero levels, TSRC will encode the level of each position using the coding scan order. If RemCcbs is greater than 4, the following syntax elements will be encoded using context coding. For each level, sig_coeff_flag is first encoded into the bitstream to indicate whether the level is zero or non-zero. If the level is non-zero, coeff_sign_flag will be encoded to indicate whether the level is positive or negative.

[0000] , where n is the index in the scan order of the current position within the sub-block, will be encoded to indicate whether the current absolute level of the current position is greater than 1 or not. If abs_level_gtx_flag[n][0] is nonzero, par_level_flag will be encoded. After encoding each syntax element above using the context encoding method, the value of RemCcbs will be decreased by one.

[0070] After encoding the above syntax elements for all positions within the current sub-block, if RemCcbs is still greater than 4, up to four more abs_level_gtx_flag[n][j] are encoded, where n is the index in the scan order of the current position within the sub-block; j is from 1 to 4 and will be encoded using the context encoding method. The value of RemCcbs will be decreased by one after encoding each abs_level_gtx_flag[n][j]. If RemCcbs is not greater than 4, the abs_remainder syntax element will be encoded in a back-off manner, if necessary, for the current position within the sub-block. For those positions where the absolute levels are entirely encoded by the abs_remainder syntax element using the back-off method, coeff_sign_flags are also encoded using the back-off method.Finally, there is a predefined counter remBinsPass1 in RRC or RemCcbs in TSRC to limit the total number of context-coded binaries and to ensure worst-case throughput.

[0071] Obtaining Rice parameters

[0072] In the current RRC implementation in VVC, two syntax elements, abs_remainder and dec_abs_level, encoded as bypass binary numbers, may be present in the bitstream for the remaining levels. Both abs_remainder and dec_abs_level are binarized using a combination of the Truncated Rice (TR) binarization process and the Exponential Golomb bounded order k (EGk), as specified in the VVC specification, which requires a Rice parameter for binarization of a given level. To obtain the optimal Rice parameter, a local sum method is used, as described below.

[0073] The AbsLevel[ xC ][ yC ] array represents an array of absolute values ​​of the transformation coefficient levels for the current transformation block for the color component index cIdx. Given the AbsLevel[ x ][ y ] array for the transformation block with the color component index cIdx and the upper-left luminance location (x0, y0), the local sum variable locSumAbs is obtained as indicated by the following pseudocode process: where log2TbWidth and log2TbHeight are the base-2 logarithms of the width and height of the transform block, respectively. The baseLevel variable is 4 and 0 for abs_remainder and dec_abs_level, respectively. Given the local sum variable locSumAbs, the Rice parameter cRiceParam is obtained as shown in Table 2. Table 2 - Description of cRiceParam based on locSumAbs locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0074] Obtaining Rice parameters from history

[0075] The pattern calculation used to obtain the Rician parameters may yield inaccurate coefficient estimates if the coefficients are located on the TU boundary or are first decoded using the Rician method. For these coefficients, the pattern calculation is biased towards 0 because some pattern positions may be located outside the TU and are interpreted or initialized as 0. Figure 6 shows an example of a pattern calculation for calculating locSumAbs for a coefficient located near the TU boundary. Figure 6 shows a CTU 602 divided into multiple CUs, and each CU contains multiple TUs. For TU 604, the position of the current coefficient is shown using a solid block, and the positions of its neighboring samples in the pattern calculation are shown using patterned blocks. The patterned blocks indicate a predefined neighborhood of the current coefficient, which is used to calculate the local sum variable locSumAbs.

[0076] In Fig. 6, since the current coefficient 606 is close to the TU boundary 604, some of its neighboring samples in the pattern are outside the TU boundary, such as neighboring samples 608B and 608E. When deriving the Rician parameters as described above, these neighboring samples outside the boundary are set to 0 when calculating the local sum variable locSumAbs, which leads to inaccuracy in deriving the Rician parameters. For samples with high bit depth (e.g., more than 10 bits), neighboring samples outside the TU boundary can be large numbers. Setting these large numbers to 0 will lead to more errors in deriving the Rician parameters.

[0077] To improve the accuracy of the Rice estimate based on the computed template, it was proposed that for template locations outside the current TU, the local sum variable locSumAbs is updated with the retrieved historical value instead of initializing to 0. An implementation of this method is shown below using the text fragment of the VVC description for section 9.3.3.2, with the proposed text underlined.

[0078] To maintain the history of adjacent coefficient / sample values, the per-color component history counter StatCoeff[cIdx] is used with cIdx = 0, 1, 2, representing the three color components Y, U, V, respectively. If the CTU is the first CTU in a layout (e.g., image, slice, or tile), StatCoeff[cIdx] is initialized as follows: In this case, BitDepth refers to the bit depth of the video luminance and chrominance array samples; Floor(x) represents the largest integer less than or equal to x; and Log2(x) represents the base 2 logarithm of x. Before updating the TU decoding and history counter, the HistValue replacement variable is initialized as: The HistValue replacement variable is used as the estimate of a neighboring sample that is outside the TU boundary (e.g., the neighboring sample has a horizontal coordinate or vertical coordinate outside the TU). The local sum variable locSumAbs is re-obtained as shown in the following pseudocode with the changes underlined:

[0079] The StatCoeff history counter is updated once per TU based on the first non-zero encoded Golomb-Rice transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]) using an exponential moving average process. When the first non-zero encoded Golomb-Rice transform coefficient in TU is encoded as abs_remainder, the StatCoeff history counter for the color component cIdx is updated as follows: When the first non-zero encoded coefficient of the Golomb-Rice transform in TU is encoded as dec_abs_level, the history counter StatCoeff for the color component cIdx is updated as follows: 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.

[0080] Wavefront Parallel Processing (WPP)

[0081] WPP serves to provide a parallel coding mechanism. When WPP is enabled in VVC, each CTU row of a frame or tile or slice represents a partitioning split. WPP is enabled / disabled by the SPS element sps_entropy_coding_sync_enabled_flag. Figure 7 shows an example of a tile for which WPP is enabled. In Figure 7, each CTU row of a tile is processed relative to its preceding CTU row with a delay of one CTU. Thus, no dependencies between consecutive CTU rows are broken at splitting boundaries, with the exception of CABAC context variables and a palette predictor if palette coding is enabled at the end of each CTU row. To reduce the potential loss of coding efficiency, the content of the adapted CABAC context variables and a palette predictor is propagated from the first coded CTU of the previous CTU row to the first CTU of the current CTU row. WPP does not change the scan order of the regular raster of the CTU set.

[0082] When WPP is enabled, multiple threads, up to the number of CTU rows in a partition (e.g., tile, slice, or frame), can process individual CTU rows in parallel. Using WPP in the decoder, each decoding thread processes one CTU row of the partition. Thread scheduling must be organized so that for each CTU, decoding of its upper neighbor CTU in the previous CTU row must be completed. A small additional overhead is added to WPP so that it can store the contents of all CABAC context variables and the palette predictor after encoding the first CTU in each CTU row except the last CTU row.

[0083] When the above-described history-based Rice parameter derivation is enabled for high-bit-depth and high-bit-rate video coding, the last StatCoeff in the previous CTU row will be propagated to the first TU in the current CTU row. As a result, this process will interfere with WPP and break WPP parallelism when WPP is enabled at the same time. The present invention proposes several methods to address this problem when parallel coding (e.g., WPP) is enabled.

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

[0085] As an example, the initial value of StatCoeff[cIdx] can be defined as follows: In this case, BitDepth refers to the bit depth of the luma or chroma array samples, and Floor(x) represents the largest integer less than or equal to x. As another example, the initial value of StatCoeff[cIdx] can be defined as: In this case, MIN_Stat, MAX_Stat are two given integers; QP is the initial QP for each slice; and Clip() is an operation defined as follows:

[0086] Before encoding the first TU of each CTU row of a breakdown (e.g. frame, tile, or slice), the replacement variable HistValue is calculated as follows: HistValue can be used to calculate the local sum variable locSumAbs, as described above. HistValue can be updated once per TU based on the first non-zero encoded Golomb-Rice transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]) using an exponential moving average process. When the first non-zero encoded Golomb-Rice transform coefficient in TU is encoded as abs_remainder, the history counter for the color component cIdx, StatCoeff[cIdx], is updated as follows: When the first non-zero encoded Golomb-Rice transform coefficient in TU is encoded as dec_abs_level, the history counter for color component cIdx, StatCoeff[cIdx], is updated as follows:

[0087] The updated StatCoeff[cIdx] is used to calculate 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.

[0088] Fig. 8 shows an example of frame 802 and the CTUs contained in this frame. In this example, frame 802 contains two tiles: tile 804A and tile 804B. Tile 804A contains four CTU rows—CTU rows 1-4. The first CTU row contains CTUs 0-CTU 9, the second CTU row contains CTUs 10-CTU 19, and so on. Similarly, tile 804B also contains four CTU rows—CTU rows 1'-4'. The first CTU row contains ten CTUs: CTUs 0'-CTU 9', the second CTU row contains CTUs 10'-CTU 19', and so on.

[0089] According to this embodiment, the initial value StatCoeff[cIdx] for the tile 804A can be determined according to equation (5) or (6). Before encoding the first TU of each CTU row among the CTU rows 1-4, the replacement variable HistValue[cIdx] is calculated using equation (8), using the initial value StatCoeff[cIdx]. For example, before encoding the first TU of CTU 0, the replacement variable HistValue is calculated using equation (8). This value HistValue is used to determine the local sum variable locSumAbs for the coefficients in the first TU, which is further used to determine the Rice parameters for the corresponding coefficients of the first TU. The history counter StatCoeff can be updated according to equation (9) or (10) when processing the first TU of the current CTU 0. Before processing the second TU in CTU 0, the current value of StatCoeff is used to determine the HistValue for the second TU according to equation (8).A similar process is then used for the second TU to determine the Rice parameters using HistValue and to update StatCoeff. For the first TU in CTU 1, HistValue is calculated according to equation (8) using the latest StatCoeff from the TU in CTU 0. This process can be repeated until the last CTU, CTU 9, in the current row of CTU 1 is processed.

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

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

[0092] Although Fig. 8 is described as a frame 802 containing two tiles 804A and 804B, the same process is applicable to other scenarios, such as a slice containing multiple tiles, a frame containing multiple slices, etc. In any of these scenarios, the value of the history counter StatCoeff[cIdx] is reset to the initial value before encoding the first TU in each CTU row of the breakdown (e.g., frame, tile, or slice) to eliminate the dependency of the CTU rows for obtaining the Rice parameters.

[0093] Possible changes to the VVC description shown as underlined are indicated as follows. The synchronization process for context variables is called as follows. - If availableFlagT is 1, the following applies. - The synchronization process for context variables, as specified in Error! Reference source not found. is called with TableStateIdx0Wpp and TableStateIdx1Wpp as input. - When sps_palette_enabled_flag is 1, the synchronization process for the palette predictor is called, as specified in 0. - When sps_persistent_Rice_adaptation_enabled_flag is 1, the synchronization process for obtaining Rice parameters is called, as specified in 9.3.2.x1. 9.3.2.x1 Synchronization process for obtaining Rice parameters This process synchronizes the values ​​of the StatCoeff arrays as follows: for( cIdx = 0; cIdx < 3; cIdx++ ) { StatCoeff [ cIdx ] = 2 * Floor( Log2( BitDepth − 10 ))}

[0094] Other possible changes to the VVC description are listed as follows for 9.3.2.1 - The StatCoeff[ i ] array with i = 0..2 is initialized as follows: StatCoeff[ i ] = sps_persistent_rice_adaptation_enabled_flag ? 2 * Floor( Log2( BitDepth - 10 ) : 0 - If the CTU is the first CTU in a slice or tile, the initialization process for context variables is called as specified in subsection 9.3.2.2, and the PredictorPaletteSize[ chType ] array with chType = 0, 1 is initialized to 0. - Otherwise, when sps_entropy_coding_sync_enabled_flag is 1 and CtbAddrX is CtbToTileColBd[ CtbAddrX ], the following applies.

[0095] Video sample bit depth

[0096] The bit depth of input video supported by VVC version 2 can exceed 10 bits. Higher video bit depth can provide higher visual quality of decoded video with less compression distortion. To support high bit depth of the input video, the semantics of the corresponding SPS (Sequence Parameter Set) syntax element sps_bitdepth_minus8 and VPS (Video Parameter Set) syntax element vps_ols_dpb_bitdepth_minus8[i] can be changed as follows: sps_bitdepth_minus8 specifies the bit depth of the luma and chroma array samples, BitDepth, and the offset value of the luma and chroma quantization parameter range, QpBdOffset, as follows: BitDepth = 8 + sps_bitdepth_minus8(x1)QpBdOffset = 6 * sps_bitdepth_minus8(x2)sps_bitdepth_minus8 must be in the range from 0 to 8, inclusive.When sps_video_parameter_set_id is greater than 0 and the SPS is referenced by a layer that is included in the i-th multilayer OLS specified by the VPS for any i in the range from 0 to NumMultiLayerOlss - 1, inclusive, the bitstream conformance requirement is that the value of sps_bitdepth_minus8 must be less than or equal to the value of vps_ols_dpb_bitdepth_minus8[ i ].vps_ols_dpb_bitdepth_minus8[ i ] points to the largest allowed value of sps_bitdepth_minus8 for all SPSs referenced by CLVSs in the CVS for the i-th multilayer OLS. The value of vps_ols_dpb_bitdepth_minus8[ i ] shall be in the range from 0 to 8, inclusive. NOTE 2 - To decode the i-th layered OLS, the decoder could 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 ].

[0097] As can be seen from the above, the bit depth of the luma and chroma array samples, BitDepth, can be obtained according to equation (x1) based on the syntax element SPSsps_bitdepth_minus8. Using the specified BitDepth value, the history counter StatCoeff, the replacement variable HistValue, and the Rice parameter can be obtained, as discussed above.

[0098] The VPSvps_ols_dpb_bitdepth_minus8[i] syntax element can be used to obtain the decoded picture buffer (DPB) size. Multiple video layers may exist for an encoded bitstream. The video parameter set is used to specify the corresponding syntax elements. For video decoding, the DPB can be used to store reference images so that previously encoded images can be used to generate prediction signals for use in encoding other images. The DPB can also be used to reorder decoded images so that they can be output and / or displayed in the correct order. The DPB can also be used to specify the output delay specified for a hypothetical reference decoder.Decoded images may be stored in the DPB for a predetermined period of time specified for a hypothetical reference decoder and output after the predetermined period of time.

[0099] 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. The DPB size will be determined by picture_size, respectively. In other words, the DPB size can be determined according to the chroma sampling format. If the video frames are monochrome frames, the frame size for buffering is determined as the basic picture size picture_size1. If the chroma subsampling of the color video frames is 4:2:0, the frame size is determined as 1.5 times the basic picture size picture_size1; if the chroma subsampling of the color video frames is 4:2:2, the frame size is determined as twice the basic picture size picture_size1; if the chroma subsampling of the color video frames is 4:4:4, the frame size is determined as three times the basic picture size picture_size1. The DPB size can be determined as the number of frames to be stored in the DPB multiplied by the frame size according to chroma subsampling.

[0100] Fig. 9 shows an example of a process 900 for encoding a video partition according to some embodiments of the present invention. One or more computing devices (e.g., a computing device implementing video encoder 100) implement the operations shown in Fig. 9 by executing corresponding software code (e.g., software code implementing entropy encoding module 116). For illustrative purposes, the process 900 is described with reference to some examples shown in the figures. However, other implementations are also possible.

[0101] In block 902, process 900 provides access to a video signal partition. The partition may be a video frame, slice, or tile, or any type of partition processed by the video encoder as a node during encoding. The partition contains a set of CTUs arranged in CTU rows, as shown in Fig. 8. Each CTU contains one or more CUs, and each CTU contains several TUs for encoding, as shown in the example in Fig. 6.

[0102] In block 904, which contains 906-914, the process 900 provides for processing each CTU from the set of CTUs in the breakdown to encode the breakdown into bits. In block 906, the process 900 provides for determining whether the parallel coding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. In some examples, parallel coding may be indicated by a flag with a value of 0 indicating that parallel coding is disabled and a value of 1 indicating that parallel coding is enabled. If it is determined that the parallel coding mechanism is enabled and the current CTU is the first CTU of the CTU row, the process 900 provides for setting the history counter StatCoeff to an initial value in block 908. As discussed above, the initial value of the history counter can be set according to equation (5) or (6) if the derivation of Rice parameters based on history is enabled; Otherwise, the initial value of the history counter is set to zero.

[0103] If it is determined that the parallel coding mechanism is not enabled or the current CTU is not the first CTU of the CTU row, or after setting the history counter in block 908, the process 900 provides for calculating the Rice parameters for a plurality of TUs in the CTU based on the history counter in block 910. As described in detail above with respect to Figs. 6-8, if the history counter is reset in block 908, the Rice parameters for the plurality of 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 908, the Rice parameters for the plurality of 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.

[0104] In block 912, process 900 encodes a plurality of TUs in a CTU into a binary representation based on the calculated Rice parameters, for example, by combining truncated Rice (TR) and limited k-th order EGK, as specified in the VVC description. In block 914, process 900 encodes the binary representation of the CTU into bits for inclusion in a video bitstream. Encoding can be performed, for example, using context-adaptive binary arithmetic coding (CABAC), discussed above. In block 916, process 900 outputs the encoded video bitstream.

[0105] Fig. 10 shows an example of a process 1000 for decoding a video according to some embodiments of the present invention. One or more computing devices implement the operations shown in Fig. 10 by executing corresponding software code. For example, a computing device implementing video decoder 200 can implement the operations shown in Fig. 10 by executing software code for entropy decoding module 216, inverse quantization module 218, and inverse transform module 219. For illustrative purposes, process 1000 is described with reference to some examples shown in the figures. However, other implementations are possible.

[0106] In block 1002, process 1000 provides access to a binary string or binary representation that represents a partition of a video signal. The partition may be a video frame, slice, or tile, or any type of partition processed by a video encoder as a node when performing encoding. The partition contains a set of CTUs arranged in CTU rows, as shown in Fig. 8. Each CTU contains one or more CUs, and each CTU contains several TUs for encoding, as shown in the example in Fig. 6.

[0107] In block 1004, which contains 1006-1014, process 1000 processes a binary string for each CTU from the set of CTUs in the breakdown to generate decoded samples for the breakdown. In block 1006, process 1000 determines whether the parallel coding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. Parallel coding can be indicated by a flag with a value of 0, indicating that parallel coding is disabled, and a value of 1, indicating that parallel coding is enabled. If it is determined that the parallel coding mechanism is enabled and the current CTU is the first CTU of the CTU row, process 1000 sets the StatCoeff history counter to the initial value in block 1008.As discussed above, the initial value of the history counter can be set according to equation (5) or (6) if history-based derivation of Rice parameters is enabled; otherwise, the initial value of the history counter is set to zero.

[0108] If it is determined that the parallel coding mechanism is not enabled or that the current CTU is not the first CTU of the CTU row, or after setting the history counter in block 1008, the process 1000 provides for calculating the Rice parameters for a plurality of TUs in the CTU based on the history counter in block 1010. As described in detail above with respect to Figs. 6-8, if the history counter is reset in block 1008, the Rice parameters for the plurality of 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 1008, the Rice parameters for the plurality of 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.

[0109] In block 1012, the process 1000 provides for decoding binary strings or binary representations of a plurality of TUs in a CTU into coefficient values ​​based on the calculated Rice parameters, for example, using a combination of truncated Rice (TR) and a limited k-th order EGK, as specified in the description of VVC. In block 1014, the process 1000 provides for restoring the pixel values ​​for the plurality of TUs in the CTU by, for example, inverse quantization and inverse transform, as discussed above with respect to Fig. 2. In block 1016, the process 1000 provides for outputting a decoded video breakdown.

[0110] In another embodiment, the inter-CTU dependency in calculating the StatCoeff history counter is aligned with the inter-CTU dependency in a parallel coding engine, such as WPP. For example, the StatCoeff history counter for a CTU row of a partition (e.g., a frame, tile, or slice) is calculated based on the values ​​of the coefficients in the first N or fewer CTUs in the previous CTU row, where N is the maximum delay between two consecutive CTU rows allowed in the parallel coding engine. Thus, the inter-CTU dependency in two consecutive CTU rows in calculating the StatCoeff history counter is constrained to be no greater than (and thus aligned with) the inter-CTU dependency when executing parallel processing.

[0111] This embodiment can be implemented using the store-synchronize process. For example, in the WPP described above, the delay between two consecutive CTU rows is one CTU, and thus N=1. In the store process, after encoding the last TU of the first CTU, in each CTU row (except for the last CTU row), StatCoeff[cIdx] can be stored in the storage variable StatCoeffWpp[cIdx]. For each CTU row, except for the first CTU row, a synchronization process is applied to obtain the Ricean parameters before the first TU encoding. In the synchronization process, StatCoeff[cIdx] is synchronized with the stored StatCoeffWpp[cIdx] from the previous CTU row.

[0112] As discussed above, before the first TU encoding in each CTU row, the HistValue variable is calculated as follows: If the current CTU row is the first CTU row of the breakdown, StatCoeff[cIdx] can be initialized according to equation (5) or (6). The calculated HistValue can be used to determine the local sum variable locSumAbs, which in turn is used to determine the Rice parameters for the set of TUs in the current CTU. StatCoeff can be updated once per TU based on the first non-zero encoded Golomb-Rice transform coefficient (abs_remainder[cIdx] or dec_abs_level[cIdx]) via the exponential moving average process, as described above with respect to equations (9) and (10).

[0113] After encoding the last TU of the first CTU in the first row of CTU, StatCoeff[cIdx] can be stored as StatCoeffWpp[cIdx] in the storage stage as follows: The encoding of the remaining CTUs in the first CTU row may be performed in a similar manner as described above with respect to the first embodiment.

[0114] Before the first TU encoding, in the second CTU row and any subsequent CTU row, StatCoeff[cIdx] can be obtained through the synchronization step: Using the obtained StatCoeff[cIdx] values, HistValue is calculated according to equation (11). The remaining process for the CTU row is the same as for the first CTU row.

[0115] Possible changes to the VVC description are indicated as follows (changes are shown underlined). 9.3.1 General When sps_persistent_Rice_adaptation_enabled_flag is 1, the persistence process for deriving Rice parameters using statistics accumulated with respect to previous TUs is applied as follows. - After the CTU syntax parsing in Section 7.3.11.2 and the last CU decoding process in the CTU in Section 8.1.2 are completed, sps_entropy_coding_sync_enabled_flag is 1 and CtbAddrX is CtbToTileColBd[ CtbAddrX ], the persistence process for deriving Rice parameters is invoked as specified in Section 9.3.2.x2. 9.3.2.1 General The synchronization process for context variables is invoked as follows. - If availableFlagT is 1, the following applies. -The synchronization process for context variables, as specified in Section 9.3.2.4, is called with TableStateIdx0Wpp and TableStateIdx1Wpp as input. -When sps_palette_enabled_flag is 1, the synchronization process for the palette predictor is called, as specified in Section 9.3.2.7.- When sps_persistent_Rice_adaptation_enabled_flag is 1, the synchronization process is called to obtain the Rice parameters as specified in section 9.3.2.x1. 9.3.2.x2 Store Process to Obtain Rice Parameters This process stores the values ​​of the StatCoeff arrays into the StatCoeffWpp arrays as follows: for( cIdx = 0; cIdx < 3; cIdx++ ) { StatCoeffWpp [ cIdx ] = StatCoeff [ cIdx ]} 9.3.2.x1 Synchronization Process to Obtain Rice Parameters This process synchronizes the values ​​of the StatCoeff arrays into the StatCoeffWpp arrays as follows: for( cIdx = 0; cIdx < 3; cIdx++ ) { StatCoeff [ cIdx ] = StatCoeffWpp[ cIdx ]}.

[0116] Alternative derivation of Rice parameters from history

[0117] Deriving Rice parameters from history can be implemented in an alternative way. In this alternative implementation, if the CTU is the first CTU in a breakdown (e.g., an image, slice, or tile), HistValue is initialized with the initial value StatCoeff[cIdx] as follows:

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

[0119] After the history counter StatCoeff[cIdx] is updated, HistValue will be updated as shown in Equation (17), and the updated HistValue will be used in obtaining the Rice parameter for the remaining syntax elements abs_remainder and dec_abs_level until the new StatCoeff[cIdx] and HistValue [cIdx] are updated again.

[0120] Based on the current VVC descriptions, possible description changes are indicated as follows.Change section 7.3.11.11 (Residual Coding Syntax) as follows (additions are underlined): residual_coding( x0, y0, log2TbWidth, log2TbHeight, cIdx ) { Descriptor … lastScanPos = numSbCoeff lastSubBlock = ( 1 << ( log2TbWidth + log2TbHeight - ( log2SbW + log2SbH ) ) ) - 1 HistValue = sps_persistent_rice_adaptation_enabled_flag ? ( 1 << StatCoeff[ cIdx ] ) : 0 updateHist = sps_persistent_rice_adaptation_enabled_flag ? 1 : 0 ... for( n = firstPosMode0; n > firstPosMode1; n- - ) { xC = ( xS << log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS << log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( abs_level_gtx_flag[ n ][ 1 ] ) { abs_remainder[ n ] ae(v) if( updateHist && abs_remainder[ n ] > 0 ) { StatCoeff[ cIdx ] = ( StatCoeff[ cIdx ] + Floor( Log2( abs_remainder[ n ] ) ) + 2 ) >> 1 updateHist = 0 HistValue = 1 << StatCoeff[ cIdx ] } } AbsLevel[ xC ][ yC ] = AbsLevelPass1[ xC ][ yC ] +2 * abs_remainder[ n ] } for( n = firstPosMode1; n >= 0; n- - ) { xC = ( xS << log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS << log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( sb_coded_flag[ xS ][ yS ] ) { dec_abs_level[ n ] ae(v) if( updateHist && dec_abs_level[ n ] > 0 ) { StatCoeff[ cIdx ] = ( StatCoeff[ cIdx ] + Floor( Log2( dec_abs_level[ n ] ) ) ) >> 1 updateHist = 0 HistValue = 1 << StatCoeff[ cIdx ] } } if( AbsLevel[ xC ][ yC ] > 0 ) { if( lastSigScanPosSb = = −1 ) lastSigScanPosSb = n firstSigScanPosSb = n } if( sh_dep_quant_used_flag ) QState = QStateTransTable[ QState ][ AbsLevel[ xC ][ yC ] & 1 ] } …….

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

[0122] This embodiment can also be implemented using the store-synchronize process. For example, in the store process, StatCoeff[cIdx] and HistValue[cIdx] can be stored in storage variables such as StatCoeffWpp[cIdx] and HistValueWpp[cIdx], as shown in Equations (18) and (19), respectively, after processing the last TU of the first CTU in each CTU row.

[0123] For each CTU row except the first CTU row, a synchronization process is applied to obtain the Rice parameters before the first TU encoding. For example, StatCoeff[cIdx] and HistValue[cIdx] are synchronized with the stored StatCoeffWpp[cIdx] and HistValueWpp[cIdx] from the previous CTU row, respectively, as shown in Equations (20) and (21). The synchronized variable HistValue is used to encode the first abs_remainder[cIdx] or dec_abs_level[cIdx] until HistValue is updated.

[0124] As discussed above, StatCoeff[cIdx] can be updated once per TU based on the first non-zero encoded coefficient of the Golomb-Rice transform (abs_remainder[cIdx] or dec_abs_level[cIdx]), as shown in Equation (15) or Equation (16). After the history counter of StatCoeff[cIdx] is updated, HistValue will be updated according to Equation (17), and the updated HistValue will be used to derive the Rice parameter for the remaining syntax elements abs_remainder and dec_abs_level until the new StatCoeff[cIdx] and HistValue [cIdx] are updated again.

[0125] Based on the current VVC descriptions, possible description changes indicated as underlined are indicated as follows. 9.3.1 General When sps_persistent_Rice_adaptation_enabled_flag is 1, the persistence process for deriving Rice parameters using statistics accumulated with respect to previous TUs is applied as follows. - After the CTU syntax parsing in Section 7.3.11.2 and the last CU decoding process in the CTU in Section 8.1.2 are completed, sps_entropy_coding_sync_enabled_flag is 1, and CtbAddrX is CtbToTileColBd[ CtbAddrX ], the persistence process for deriving Rice parameters is invoked as specified in Section 9.3.2.x2. 9.3.2.1 General The synchronization process for context variables is invoked as follows. - If availableFlagT is 1, the following applies. -The synchronization process for context variables, as specified in Section 9.3.2.4, is called with TableStateIdx0Wpp and TableStateIdx1Wpp as input. -When sps_palette_enabled_flag is 1, the synchronization process for the palette predictor is called, as specified in Section 9.3.2.7.-When sps_persistent_Rice_adaptation_enabled_flag is 1, the synchronization process is invoked to obtain the Rice parameters as specified in Section 9.3.2.x1. 9.3.2.x2 Store Process to Obtain Rice Parameters This process stores the values ​​of the StatCoeff and HistValue arrays into the StatCoeffWpp and HistValueWPP arrays as follows: for( cIdx = 0; cIdx < 3; cIdx++ ) { StatCoeffWpp [ cIdx ] = StatCoeff[ cIdx ] HistValueWpp [ cIdx ] = HistValue[ cIdx ]} 9.3.2.x1 Synchronization Process to Obtain Rice Parameters This process synchronizes the values ​​of the StatCoeff and HistValue arrays into the StatCoeffWpp and HistValueWpp arrays as follows: for( cIdx = 0; cIdx < 3; cIdx++ ) { StatCoeff [ cIdx ] = StatCoeffWpp[ cIdx ] HistValue[ cIdx ] = HistValueWpp[ cIdx ]}.

[0126] Fig. 11 shows an example of a process 1100 for encoding a video partition according to some embodiments of the present invention. One or more computing devices (e.g., a computing device implementing video encoder 100) implement the operations shown in Fig. 11 by executing corresponding software code (e.g., software code implementing entropy encoding module 116). For illustrative purposes, the process 1100 is described with reference to some examples shown in the figures. However, other implementations are possible.

[0127] In block 1102, process 1100 provides access to a video signal partition. The partition may be a video frame, slice, or tile, or any type of partition processed by the video encoder as a node during encoding. The partition contains a set of CTUs arranged in CTU rows, as shown in Fig. 8. Each CTU contains one or more CUs, and each CTU contains multiple TUs for encoding, as shown in the example in Fig. 6.

[0128] In block 1104, which contains 1106-1118, process 1100 processes each CTU from the set of CTUs in the breakdown to encode the breakdown into bits. In block 1106, process 1100 determines whether the parallel encoding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. In some examples, parallel encoding may be indicated by a flag with a value of 0 indicating that parallel encoding is disabled and a value of 1 indicating that parallel encoding is enabled. If it is determined that the parallel encoding mechanism is enabled and the current CTU is the first CTU of the CTU row, process 1100 determines, in block 1107, whether the current CTU row is the first CTU row in the breakdown. If so, process 1100 involves setting the history counter StatCoeff to an initial value in block 1108. As discussed above, the initial value of the history counter can be set according to equation (5) or (6).If the current CTU row is not the first CTU row in the breakdown, process 1100 includes setting, in block 1109, the history counter StatCoeff to the value stored in the history counter storage variable, as shown in equation (13) or (20). In some examples, such as when alternative Rice parameter retrieval is used, the value of the replacement variable HistValue may also be reset to the stored value, as shown in equation (21).

[0129] If it is determined that the parallel coding mechanism is not enabled, or that the current CTU is not the first CTU of the CTU row, or after setting the history counter value in block 1108 or 1109, process 1100 provides, in block 1110, for calculating Rice parameters for TUs in the CTU based on the history counter (and the HistValue replacement variable, if it is also reset). As described above (for example, with respect to FIG. 8 or in the alternative obtaining of Rice parameters), if the history counter value is reset in block 1108 or 1109, Rice parameters for a plurality of TUs in the CTU are calculated based on the reset history counter or a subsequently updated history counter. If the history counter is not reset in block 1108 or 1109, Rice parameters for a plurality of TUs in the CTU are calculated based on the history counter updated in the previous CTU or a subsequently updated history counter in the current CTU.

[0130] In block 1112, process 1100 encodes a plurality of TUs in a CTU into a binary representation based on the calculated Rice parameters, for example, by combining truncated Rice (TR) and limited k-th order EGK, as specified in the VVC description. In block 1114, process 1100 encodes the binary representation of the CTU into bits for inclusion in the video bitstream. Encoding can be performed, for example, using context-adaptive binary arithmetic coding (CABAC), discussed above.

[0131] In block 1116, process 1100 determines whether parallel encoding is enabled and whether the CTU is the first CTU of the current CTU row. If so, process 1100 stores the history counter value in the history counter storage variable, as shown in equation (12) or (18), in block 1118. In some examples, such as when alternative Rice parameter derivation is used, the value of the HistValue replacement variable may also be stored in the storage variable, as shown in equation (19). In block 1120, process 1100 outputs the encoded video bitstream.

[0132] In some scenarios, a CTU in a row other than the first CTU may be on a layout boundary. For example, the first CTU in the second CTU row does not have a CTU in the layout that is located on top of this CTU. In these scenarios, the history counter for this CTU may be set to the initial value instead of the saved value. In this case, a new block 1107' may be added in FIG. 11 between block 1107 and block 1109 to determine whether the CTU is on a layout boundary (e.g., the CTU does not have an upper neighboring CTU within the layout). If so, process 1100 proceeds to block 1108 to set the history counter to the initial value; if not, process 1100 proceeds to block 1109 to set the history counter to the saved value. The remaining blocks of FIG. 11 may remain the same.

[0133] Fig. 12 shows an example of a process 1200 for decoding a video according to some embodiments of the present invention. One or more computing devices implement the operations shown in Fig. 12 by executing suitable software code. For example, a computing device implementing video decoder 200 can implement the operations shown in Fig. 12 by executing software code for entropy decoding module 216, inverse quantization module 218, and inverse transform module 219. For illustrative purposes, process 1200 is described with reference to some examples shown in the figures. However, other implementations are possible.

[0134] In block 1202, process 1200 provides access to a binary string or binary representation that represents a partition of the video signal. The partition may be a video frame, slice, or tile, or any type of partition processed by the video encoder as a node when performing encoding. The partition contains a set of CTUs arranged in CTU rows, as shown in Fig. 8. Each CTU contains one or more CUs, and each CTU contains several TUs for encoding, as shown in the example in Fig. 6.

[0135] In block 1204, which contains 1206-1218, process 1200 processes a binary string for each CTU from the set of CTUs in the breakdown to generate decoded samples for the breakdown. In block 1206, process 1200 determines whether the parallel coding mechanism is enabled and whether the current CTU is the first CTU of the CTU row. Parallel coding can be indicated by a flag with a value of 0, indicating that parallel coding is disabled, and a value of 1, indicating that parallel coding is enabled. If it is determined that the parallel coding mechanism is enabled and the current CTU is the first CTU of the CTU row, process 1200 determines, in block 1207, whether the current CTU row is the first CTU row in the breakdown. If so, process 1200 includes setting, in block 1208, the history counter StatCoeff to the initial value.As discussed above, the initial value of the history counter can be set according to equation (5) or (6). If the current CTU row is not the first CTU row in the breakdown, process 1200 provides for setting, in block 1209, the history counter StatCoeff to the value stored in the history counter storage variable, as shown in equation (13) or (20). In some examples, for example, when alternative Rice parameter retrieval is used, the value of the replacement variable HistValue can also be reset to the stored value, as shown in equation (21).

[0136] If it is determined that the parallel coding mechanism is not enabled, or that the current CTU is not the first CTU of the CTU row, or after setting the history counter in block 1208 or 1209, the process 1200 provides, in block 1210, for calculating the Rice parameters for a plurality of TUs in the CTU based on the history counter (and the replacement variable HistValue, if its value is also set). As described above (for example, with respect to FIG. 8 or in the alternative obtaining of Rice parameters), if the value of the history counter is reset in block 1208 or 1209, the Rice parameters for the plurality of TUs in the CTU are calculated based on the reset history counter or the subsequently updated history counter. If the history counter values ​​are not reset in block 1208 or 1209, the Rice parameters for the plurality of 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.

[0137] In block 1212, process 1200 provides for decoding binary strings or binary representations of a plurality of TUs in a CTU into coefficient values ​​based on the calculated Rician parameters, for example, by means of a combination of truncated Rician (TR) and limited k-th order EGK, as indicated in the description of VVC. In block 1214, process 1200 provides for reconstructing pixel values ​​for a plurality of TUs in a CTU by means of, for example, inverse quantization and inverse transform, as discussed above with respect to Fig. 2.

[0138] In block 1216, process 1200 determines whether parallel encoding is enabled and the CTU is the first CTU of the current CTU row. If so, process 1200 stores the history counter value in the history counter storage variable, as shown in equation (12) or (18), in block 1218. In some examples, such as when alternative Rice parameter derivation is used, the value of the HistValue replacement variable may also be stored in the storage variable, as shown in equation (19). In block 1216, process 1200 outputs the decoded video breakdown.

[0139] In another embodiment, WPP or other parallel encoding mechanisms and history-based Rician parameter derivation are not allowed to coexist in a bitstream. For example, if WPP is allowed, history-based Rician parameter derivation may not be allowed. If WPP is not allowed, history-based Rician parameter derivation may be allowed. Similarly, if history-based Rician parameter derivation is allowed, WPP may not be allowed. As an example, the syntax change can be made as follows, 7.3.2.22 Sequence Parameter Set Range Extension Syntax (additions are underlined) sps_range_extension() { Descriptor sps_extended_precision_flag u(1) if( sps_transform_skip_enabled_flag ) sps_ts_residual_coding_rice_present_in_sh_flag u(1) sps_rrc_rice_extension_flag u(1) if(sps_entropy_coding_sync_enabled_flag) sps_persistent_rice_adaptation_enabled_flag u(1) sps_reverse_last_sig_coeff_enabled_flag u(1) }

[0140] As another example, the corresponding semantics will change as follows (changes are underlined). sps_entropy_coding_sync_enabled_flag equal to 1 indicates that the specific synchronization process for context variables is called before decoding the CTU that contains the first CTB of a row of the set of CTBs in each tile in each picture belonging to the SPS, and the specific storage process for context variables is called after decoding the CTU that contains the first CTB of a row of the set of CTBs in each tile in each picture belonging to the SPS. sps_entropy_coding_sync_enabled_flag equal to 0 indicates that it is not required to call the specific synchronization process for context variables before decoding the CTU that contains the first CTB of a row of the set of CTBs in each tile in each picture belonging to the SPS, and it is not required to call the specific storage process for context variables after decoding the CTU that contains the first CTB of a row of the set of CTBs in each tile in each picture belonging to the SPS.When sps_persistent_Rice_adaptation_enabled_flag is 1, sps_entropy_coding_sync_enabled_flag must be 0. sps_persistent_Rice_adaptation_enabled_flag equal to 1 indicates that the derivation of the Rice parameters for binarization of abs_remainder[ ] and dec_abs_level[ ] is initialized at the beginning of each TU using statistics accumulated from previous TUs. sps_persistent_Rice_adaptation_enabled_flag equal to 0 indicates that the previous TU state is not used when deriving the Rice parameters. If absent, the value of sps_persistent_Rice_adaptation_enabled_flag is assumed to be 0. When sps_entropy_coding_sync_enabled_flag is 1, the value of sps_persistent_Rice_adaptation_enabled_flag must be 0.

[0141] Although TUs are described and illustrated in figures (e.g., Fig. 6) in the above description, the same techniques can be applied to transformation units (TBs). In other words, in the embodiments presented above (including the figures), TUs can also represent a plurality of TBs.

[0142] An example of a computing system for implementing dependent quantization for video coding

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

[0144] Memory device 1314 may comprise any suitable non-transitory computer-readable storage medium. The computer-readable storage medium may comprise any electronic, optical, magnetic, or other information storage device capable of providing the processor with machine-readable instructions or other program code. Non-limiting examples of computer-readable storage media include a magnetic disk, a memory chip, ROM, RAM, ASIC, a configured processor, an optical storage device, magnetic tape, or other magnetic storage device, or any other storage medium from which the computer processor can read instructions. The instructions may include processor-dependent instructions generated by a compiler and / or interpreter from code written in any suitable programming language, including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

[0145] The computing device 1300 may also comprise a bus 1316. The bus 1316 may communicatively connect one or more components of the computing device 1300. The computing device 1300 may also provide a number of external or internal devices, such as input or output devices. For example, the computing device 1300 is shown with an input / output ("I / O") interface 1318, which can receive input data from one or more input devices 1320 or provide output data to one or more output devices 1322. One or more input devices 1320 and one or more output devices 1322 may be communicatively connected to the I / O interface 1318. The communicative connection may be implemented in any suitable manner (e.g., connection via a printed circuit board, connection via a cable, communication via wireless data transmission, etc.).Non-limiting examples of input devices 1320 include a touch screen (e.g., one or more cameras for visualizing the touch area or pressure sensors for detecting pressure changes caused by 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 display, an external monitor, a speaker, or any other device that can be used to display or otherwise present output data generated by the computing device.

[0146] The computing device 1300 can execute a program code that configures the processor 1312 to perform one or more of the operations described above with respect to Figs. 1-12. The program code can provide a video encoder 100 or a video decoder 200. The program code can be located in the memory 1314 or any suitable computer-readable storage medium and can be executed by the processor 1312 or any other suitable processor.

[0147] The computing device 1300 may also comprise at least one network interface device 1324. The network interface device 1324 may comprise any device or group of devices suitable for establishing a wired or wireless connection for transmitting data with one or more data networks 1328. Non-limiting examples of the network interface device 1324 include an Ethernet network adapter, a modem, and / or the like. The computing device 1300 can transmit messages in the form of electronic or optical signals via the network interface device 1324.

[0148] General Provisions

[0149] Numerous specific details are set forth in this document to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will appreciate that the claimed subject matter may be practiced without these specific details. In other instances, methods, apparatuses, or systems that would be familiar to those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0150] Unless otherwise stated, it should be taken into account that throughout this discussion of the description, the use of the terms "processing", "calculating", "computing", "determining" and "identifying" or the like, refers to the actions or processes of a computing device, such as one or more computers or similar electronic computing device or devices that manage or transform data represented in the form of physical electronic or magnetic quantities in memory devices, registers or other information storage devices, transmission devices or display devices of a computing platform.

[0151] The system or systems discussed herein are not limited to any particular architecture or hardware configuration. A computing device may include any suitable arrangement of components that provides a result conditioned by one or more input data. Suitable computing devices include multi-purpose computer systems based on microprocessors that have access to stored software that programs or configures the computing system from a general-purpose computing device to a specialized computing device implementing one or more embodiments of the present subject matter.Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the ideas contained in this document in software to be used in programming or configuring a computing device.

[0152] Embodiments of the methods disclosed in this document may be performed using such computing devices. The order of the blocks presented in the examples above may be changed, for example, blocks may be reordered, combined, and / or split into sub-blocks. Some blocks or processes may be executed in parallel.

[0153] The use of the phrases "adapted for" or "configured to" in this document is intended to be open-ended and inclusive, not excluding the use of devices adapted or configured to perform additional tasks or steps. Furthermore, the use of the phrase "based on" is intended to be open-ended and inclusive, as a process, step, calculation, or other action "based on" one or more stated conditions or values ​​may in practice be based on additional conditions or values ​​in addition to those stated. Headings, lists, and numbering included in this document are for ease of explanation only and are not limiting.

[0154] ​​Although the present subject matter has been described in detail with respect to specific embodiments thereof, it should be understood that those skilled in the art, having understood the above, can easily create variations, variants, and equivalents of such embodiments. Accordingly, it should be understood that the present invention has been presented for purposes of example, and not limitation, and does not exclude the inclusion of such modifications, variants, and / or additions to the present subject matter that will be obvious to a person skilled in the art.

Claims

1. A method for decoding a bitstream encoded using universal video coding (VVC), the method comprising: determining the bit depth of the image samples based on the sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein the value of the SPS syntax element sps_bitdepth_minus8 is in the range from 0 to 8; determining the decoded picture buffer (DPB) size based on the video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8, wherein the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in the range from 0 to 8; allocating storage space with a specific DPB size; obtaining and storing the decoded image in the DPB by decoding the bit stream based on the determined bit depth; and decoded image output, In this case, decoding of the bit stream based on a certain bit depth provides for: accessing a binary string representing a breakdown of an image, wherein the breakdown comprises a plurality of code tree units (CTUs) forming one or more CTU rows; for each CTU from the set of CTUs in the breakdown before decoding the CTU and in response to determining that parallel encoding is enabled and that the CTU is the first CTU of the current CTU row among one or more CTU rows in the breakdown, determining whether the current CTU row is the first CTU row in the breakdown; in response to determining that the current CTU row is the first CTU row in the breakdown, setting a history counter for the color component for calculating Rice parameters 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 breakdown, setting the history counter for the color component to the value stored in the history counter storage variable; CTU decoding, which includes: Calculating Rice parameters for transformation nodes (TUs) in CTUs based on the history counter value; decoding a binary string corresponding to a set of TUs in a CTU into values ​​of the coefficients of the set of TUs based on the calculated Rice parameters; and determining pixel values ​​for a set of TUs in a CTU from the coefficient values; and after decoding the CTU in response to determining that parallel encoding is enabled and that the CTU is the first CTU of the current CTU row, storing the current value of the history counter in the history counter storage variable.

2. The method according to paragraph 1, characterized in that obtaining and storing the decoded image in the DPB by decoding the bit stream includes: obtaining and storing a first set of images in the DPB by decoding a first portion of the bitstream; and decoding the second portion of the bitstream into a second set of images by using the first set of images in the DPB as reference images.

3. The method according to paragraph 1, characterized in that it additionally includes: reordering one or more decoded images in the DPB according to the output order; and outputting one or more decoded images according to the output order.

4. The method according to paragraph 1, characterized in that it additionally includes: storing one or more decoded images in the DPB for a specified period of time; and outputting one or more decoded images after a specified period of time.

5. A method of encoding using universal video coding (VVC), the method comprising: determining the bit depth of the image samples to be encoded; determining a value of the sequence parameter set (SPS) syntax element sps_bitdepth_minus8, wherein the value of the SPS syntax element sps_bitdepth_minus8 is in the range from 0 to 8, and encoding the value of the SPS syntax element sps_bitdepth_minus8 into a bitstream; determining the value of the video parameter set (VPS) syntax element vps_ols_dpb_bitdepth_minus8, wherein the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 is in the range from 0 to 8, and encoding the value of the VPS syntax element vps_ols_dpb_bitdepth_minus8 into a bitstream; Determining the decoded picture buffer (DPB) size based on the VPS syntax element vps_ols_dpb_bitdepth_minus8; allocating storage space with a specific DPB size; obtaining and storing the image in the DPB; and image encoding based on a specific bit depth, In this case, image coding based on a certain bit depth provides for: performing a partition of an image, wherein the partition comprises a plurality of code tree units (CTUs) forming one or more CTU rows; for each CTU from the set of CTUs in the breakdown prior to encoding the CTU and in response to determining that parallel encoding is permitted and that the CTU is the first CTU of the current CTU row among one or more CTU rows in the breakdown, determining whether the current CTU row is the first CTU row in the breakdown; in response to determining that the current CTU row is the first CTU row in the breakdown, setting a history counter for the color component for calculating Rice parameters 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 breakdown, setting the history counter for the color component to the value stored in the history counter storage variable; CTU coding, which provides for: Calculating Rice parameters for transformation nodes (TUs) in CTUs based on the history counter value; encoding the values ​​of the coefficients corresponding to the set of TUs in the CTU into a binary string based on the calculated Rice parameters; and signaling the binary string of the plurality of TUs in the CTU into a bit stream; and after encoding the CTU, in response to determining that parallel encoding is enabled and that the CTU is the first CTU of the current CTU row, storing the current value of the history counter in the history counter storage variable.

6. The method according to paragraph 5, characterized in that obtaining and storing an image in the DPB includes: obtaining and saving the first set of images in DPB; encoding the first set of images into a first portion of a bitstream; and encoding the second set of images into the second portion of the bitstream by using the first set of images in the DPB as reference images.

7. A non-volatile computer-readable storage medium storing a bit stream and a computer program that, when executed by a processor, causes the processor to execute the method of claim 5 or 6 for generating the bit stream.

Images