COEFFICIENT AND RESIDUAL CODING FOR VIDEO CODING

Abstract

Methods, devices, and non-transient, computer-readable storage media are provided for video decoding. In one method, a decoder receives a rice extension flag from the Sequence Parameter Set (SPS) indicating whether an extension of the rice parameter derivation for abs_remainder and dec_abs_level binarization is enabled. In a second method, the decoder can receive an enabled rice adaptation flag from the Sequence Parameter Set (SPS) indicating whether the rice parameter derivation for abs_remainder and dec_abs_level binarization is initialized at the beginning of each transform unit (TU) with accumulated statistics from previous TUs.

Description

COEFFICIENT AND RESIDUAL CODING FOR VIDEO CODING FIELD OF THE INVENTION This disclosure relates to video coding and compression. More specifically, this disclosure relates to improvements and simplifications of coefficient and residual coding for video coding. BACKGROUND OF THE INVENTION Several video coding techniques can be used to compress video data. Video coding is performed according to one or more video coding standards. Examples of video coding standards include Versatile Video Coding (VVC), Joint Scan Test Model (JEM), High Efficiency Video Coding (H.265 / HEVC), Advanced Video Coding (H.264 / AVC), Moving Picture Expert Group (MPEG) coding, and similar standards. Video coding typically uses predictive methods (e.g., inter-prediction, intra-prediction, and similar methods) that take advantage of the redundancy present in video images or sequences. A major goal of video coding techniques is to compress video data in a way that uses a lower bit rate while avoiding or minimizing degradation to video quality. BRIEF DESCRIPTION OF THE INVENTION Examples in this disclosure provide methods and apparatus for video encoding. Pursuant to a first aspect of this disclosure, a method for video decoding is provided. The method may include: receiving, by means of a decoder, a rice extension flag from the Sequence Parameters (SPS) set indicating whether a rice parameter derivation extension for abs_remainder and dec_abs_level binarization has been enabled. The abs_remainder parameter indicates a first syntax element that is a remaining portion of level information from a coefficient encoded with the Golomb-rice code and derivation-encoded bins in a second pass when the number of remaining context-encoded bins is greater than or equal to 4 while encoding a first pass.The dec_abs_level parameter indicates a second syntax element that is an actual coefficient directly coded in the second pass using the GolombRice code and derivation-coded bins when the remaining number of context-coded bins is less than 4 while coding the first pass. Pursuant to a second aspect of this disclosure, a method for video decoding is provided. The method may include: receiving, via a decoder, a rice-adaptive indicator from the Sequence Parameter Set (SPS) that indicates whether the derivation of the rice parameter for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each transform unit (TU) with cumulative statistics from previous TUs. The abs_remainder parameter indicates a first syntax element that is a remaining portion of the level information of a coefficient encoded with Golomb-rice code and derivation-encoded bins in a second pass when the number of remaining context-encoded bins is greater than or equal to 4 while encoding a first pass.The dec_abs_level parameter indicates a second syntax element which is an ncnn in / pznz / B / Yi current coefficient directly encoded on the second pass using the Golomb-Rice code and derivation-encoded bins when the remaining number of context-encoded bins is less than 4 while encoding the first pass. It should be understood that the above general descriptions and detailed descriptions below are merely illustrative and explanatory and are not intended to limit the present disclosure. BRIEF DESCRIPTION OF THE FIGURES The accompanying figures, which are incorporated in and form a part of this specification, illustrate examples consistent with this disclosure and, together with the description, serve to explain the principles of disclosure. FIG. 1 is a block diagram of an encoder, according to an example in this disclosure. FIG. 2 is a block diagram of a decoder, according to an example in this disclosure. FIG. 3A is a diagram illustrating block splits in a multi-type tree structure, according to an example in this disclosure. FIG. 3B is a diagram illustrating block partitions in a multi-type tree structure, according to an example in this disclosure. FIG. 3C is a diagram illustrating block partitions in a multi-type tree structure, according to an example in this disclosure. FIG. 3D is a diagram illustrating block partitions in a multi-type tree structure, according to an example in this disclosure. FIG. 3E is a diagram illustrating block partitions in a multi-type tree structure, according to an example in this disclosure. FIG. 4 is an illustration of a residual encoding structure for transform blocks, according to an example in this disclosure. FIG. 5 is an illustration of a residual encoding structure for transform jump blocks, according to an example in this disclosure. FIG. 6 is a method for encoding a video signal, according to an example in this disclosure. FIG. 7 is a method for encoding a video signal, according to an example in this disclosure. FIG. 8 is a diagram illustrating a computer environment coupled with a user interface, according to an example in this disclosure. FIG. 9 illustrates a method for video encoding, according to an example in this disclosure. FIG. 10 illustrates a method for video encoding, according to an example in this disclosure. FIG. 11 illustrates a method for video encoding, according to an example in this disclosure. ncnn in / cznz / B / Yi FIG. 12 illustrates a method for video encoding, according to an example in this disclosure. FIG. 13 is a block diagram illustrating an exemplary system for encoding and decoding video blocks according to an example in this disclosure. FIG. 14 is a block diagram illustrating an exemplary video encoder according to an example in this disclosure. FIG. 15 is a block diagram illustrating an exemplary video decoder according to an example in this disclosure. FIG. 16 illustrates a low-delay transform hop residual coding (TSRC) method according to an example in this disclosure. FIG. 17 illustrates a method for video decoding, according to an example in this disclosure. FIG. 18 illustrates a method for video decoding, according to an example in this disclosure. DETAILED DESCRIPTION OF THE INVENTION Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying figures. The following description refers to the accompanying figures, in which the same numbers in different figures represent the same or similar elements unless otherwise stated. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the disclosure. Instead, they are merely examples of apparatus and methods consistent with aspects related to the description as considered in the appended claims. The terminology used herein is for the purpose of describing particular forms only and is not intended to limit this disclosure. As used herein and in the accompanying claims, the singular forms “a,” “one,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “and / or” as used herein shall also be understood to mean and include any or all possible combinations of one or more of the listed concepts. It is understood that, although the terms “first,” “second,” “third,” etc., may be used herein to describe various information, the information should not be limited by these terms. These terms are used only to distinguish one category of information from another. For example, without departing from the scope of this disclosure, first information should be referred to as second information; and similarly, second information should also be referred to as first information. As used herein, the term “if” may be understood to mean “when” or “once” or “in response to a judgment,” depending on the context. Figure 1 shows a general diagram of a block-based video encoder for VVC. Specifically, Figure 1 shows a typical encoder 100. The encoder 100 has video input 110, motion compensation 112, motion estimation 114, intra / inter mode decision 116, block predictor 140, adder 128, transform 130, quantization 132, information related to the prediction 142, intra prediction 118, image buffer 120, inverse quantization 134, inverse transform 136, adder 126, memory 124, loop filter 122, entropy coding 138, and bitstream 144. In the 100 encoder, a video frame is divided into a plurality of video blocks for processing. For each given video block, a prediction is formed based on either an inter-prediction or an intra-prediction approach. A prediction residual, representing the difference between a current video block (video input part 110) and its predictor (block predictor part 140), is sent to a transform 130 from the adder 128. The transform coefficients are then sent from the transform 130 to a quantization 132 for entropy reduction. The quantized coefficients are then fed to an entropy coding 138 to generate a compressed video bitstream. As shown in FIG. 1, prediction-related information 142 from an intra / inter-mode decision 116, such as video block splitting information, motion vectors (MVs), reference frame index, and intra-prediction mode, is also fed through the entropy coding 138 and saved in a compressed bitstream 144. The compressed bitstream 144 includes a video bitstream. In the encoder 100, the decoder-related circuitry is also required to reconstruct pixels for prediction purposes. First, a prediction residual is reconstructed using Inverse Quantization 134 and Inverse Transform 136. This reconstructed prediction residual is then combined with a Block Predictor 140 to generate unfiltered reconstructed pixels for a current video block. Spatial prediction (or “intra prediction”) uses pixels from samples of adjacent blocks already encoded (which are called reference samples) in the same video frame as the current video block to predict the current video block. Temporal prediction (also referred to as "inter-prediction") uses reconstructed pixels from previously encoded video images to predict the current video block. Temporal prediction reduces the inherent temporal redundancy in the video signal. The temporal prediction signal for a given encoding unit (CU) or encoding block is typically signaled by one or more MVs, which indicate the amount and direction of movement between the current CU and its temporal reference. Additionally, if multiple reference images are supported, a reference image index is also sent, which is used to identify which reference image in the reference image storage the temporal prediction signal originates from. Motion estimation 114 takes video input 110 and a signal from image buffer 120 and outputs a motion estimation signal to motion compensation 112. Motion compensation 112 takes video input 110, a signal from image buffer 120, and the motion estimation signal from motion estimation 114 and outputs a motion compensation signal to intra / inter mode decision 116. After the temporal and / or spatial prediction is performed, an intra / inter-mode decision 116 in the encoder 100 chooses the best prediction mode, for example, based on the ncnn i η / ρζηζ / Β / γι rate distortion optimization method. The block predictor 140 is then subtracted from the current video block, and the resulting prediction residual is decorrelated using the transform 130 and quantization 132. The resulting quantized residual coefficients are inversely quantized by inverse quantization 134 and inversely transformed by the inverse transform 136 to form the reconstructed residual, which is then added back to the prediction block to form the reconstructed CU signal.Furthermore, in loop filtering 122, such as an unblocking filter, an adaptive sample deviation (SAO) and / or adaptive loop filter (ALF) can be applied to the rebuilt CU before it is placed in the image buffer reference storage 120 and used to encode future video blocks. To form the output video bitstream 144, the encoding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy encoding unit 138 to be further compressed and packaged to form the bitstream. Figure 1 provides the block diagram of a generic block-based hybrid video coding system. The input video signal is processed block by block (called coding units (CUs)). In VTM-1.0, a CU can be up to 128x128 pixels. However, unlike HEVC, which partitions blocks solely based on quaternary trees, in VVC, a coding tree unit (CTU) is separated into CUs to accommodate local variations based on the quaternary / binary / ternary tree structure. By definition, a coding tree block (CTB) is an NxN block of samples for some value of N, such that dividing a component into CTBs is partitioning.The CTU includes a luma sample CTB, two corresponding chroma sample CTBs for an image with three sample arrays, or a sample CTB for a monochrome image or an image encoded using three separate color planes and syntax structures. Additionally, the concept of a multiple partitioning unit type in HEVC is eliminated; that is, the separation of CU, prediction unit (PU), and transform unit (TU) no longer exists in VVC. Instead, each CU is always used as the basic unit for both prediction and transformation without further partitioning. In the multiple-type tree structure, a CTU is first partitioned by a quaternary tree structure. Then, each leaf node of the quaternary tree can be further partitioned by a binary and ternary tree structure, as shown in the figures.3A, 3B, 3C, 3D, and 3E, there are five types of separation: quaternary partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning. FIG. 3A shows a diagram illustrating the quaternary block partitioning in a multi-tree structure, according to the present description. FIG. 3B shows a diagram illustrating the vertical block binary partitioning in a multi-type tree structure, according to the present disclosure. FIG. 3C shows a diagram illustrating the horizontal binary partitioning of the block in a multi-type tree structure, according to this disclosure. FIG. 3D shows a diagram illustrating the vertical ternary partitioning of the block in a ncnn in / pznz / B / Yi multi-type tree structure, according to the present disclosure. FIG. 3E shows a diagram illustrating the horizontal ternary partitioning of the block into a multiple-type tree structure, according to the present description. In FIG. 1, spatial and / or temporal prediction can be performed. Spatial prediction (or “intra-prediction”) uses pixels from samples of adjacent, already encoded blocks (called reference samples) in the same portion / image of video to predict the current video block. Spatial prediction reduces the spatial redundancy inherent in the video signal. Temporal prediction (also referred to as “inter-prediction” or “motion-compensated prediction”) uses reconstructed pixels from already encoded video images to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in the video signal. The temporal prediction signal for a given CU is generally signaled by one or more motion vectors (MVs), which indicate the amount and direction of motion between the current CU and its temporal reference.Also, if multiple reference images are supported, a reference image index is additionally sent, which is used to identify which reference image in the reference image store the temporal prediction signal originates from. After spatial and / or temporal prediction, the mode decision block in the encoder chooses the best prediction mode, for example, based on the velocity distortion optimization method. The prediction block is then subtracted from the current video block; and the prediction residual is decorrelated using transform and quantization. The quantized residual coefficients are inversely quantized and inversely transformed to form the reconstructed residual, which is then added back to the prediction block to form the reconstructed CU signal.Additionally, in loop filtering, such as unblocking filtering, adaptive sample deviation (SAO) and adaptive loop filtering (ALF) can be applied to the rebuilt CU before it is placed in the reference image store and used to encode future video blocks. To form the output video bitstream, encoding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy encoding unit to be further compressed and packaged to form the bitstream. Figure 2 shows a general block diagram of a video decoder for VVC. Specifically, Figure 2 shows a block diagram of the typical decoder 200. The decoder 200 has bit stream 210, entropy decoding 212, inverse quantization 214, inverse transform 216, adder 218, intra / inter mode selection 220, intra prediction 222, memory 230, loop filter 228, motion compensation 224, picture buffer 226, prediction-related information 234, and video output 232. Decoder 200 is similar to the reconstruction-related section residing in encoder 100 of FIG. 1. In decoder 200, an incoming video bitstream 210 is first decoded by Entropy Decoding 212 to derive quantized coefficient levels and prediction-related information. The quantized coefficient levels are then processed through Inverse Quantization 214 and Inverse Transform 216 to obtain a reconstructed prediction residual. A block predictor mechanism, implemented in a Selector of ncnn in / cznz / B / Yi Intra / lnter mode 220 is configured to perform either an Intra Prediction 222 or a Motion Compensation 224, based on decoded prediction information. A series of unfiltered reconstructed pixels is obtained by summing the reconstructed prediction residual from the Inverse Transform 216 and a predictive output generated by the block predictor mechanism, using an adder 218. The reconstructed block can further pass through a Loop Filter 228 before being stored in an Image Buffer 226, which functions as a reference image store. The reconstructed video in Image Buffer 226 can be sent to operate a display device, as well as used to predict future video blocks. In situations where the Loop Filter 228 is turned on, a filtering operation is performed on these reconstructed pixels to derive a final reconstructed Video Output 232. Figure 2 provides a general block diagram of a block-based video decoder. The video bitstream is first entropy-decoded in the entropy-decoding unit. The prediction and encoding mode information is sent either to the spatial prediction unit (if intra-coded) or the temporal prediction unit (if inter-coded) to form the prediction blocks. The residual transform coefficients are sent to the inverse quantization unit and the inverse transform unit to reconstruct the residual block. The prediction block and the residual block are then aggregated together. The reconstructed block may further undergo loop filtering before being stored in the reference image store.The reconstructed video in the reference image store is then sent out to operate a deployment device, as well as used to predict future video blocks. Transform Coefficient Encoding in VVC In VVC transform coefficient encoding, a variable, remBinsPassl, is first set to the maximum number of allowed context-coded bins (MCCBs). During the encoding process, the variable is decremented by one each time a context-coded bin is signaled. Even if remBinsPassl is greater than or equal to four, a coefficient is first signaled using the syntax of sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag, all using context-coded bins in the first pass. The remaining portion of the coefficient level information is encoded using the syntax element abs_remainder with Golomb-rice code and derivation-coded bins in the second pass.When remBinsPassl becomes less than 4 while encoding the first pass, a current coefficient is not encoded in the first pass, but directly encoded in the second pass using the dec_abs_level syntax element with Golomb-Rice code and derivation-encoded bins. The derivation process for the dec_abs_level[] parameter from Rice is described in Table 1A. After all the level encoding mentioned above, the sign flags for all scan positions with sig_coeff_flag equal to 1 are finally encoded as derivation bins. This process is described in Figure 4. remBinsPassl is reset for each TB. The transition from using context-coded bins for sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag to using derivation-coded bins for the remaining coefficients only happens at most once per TB.For a coefficient subblock ncnn i η / ρζηζ / Β / γι, if remBinsPassl is smaller than 4 before encoding its first coefficient, the integer coefficient subblock is encoded using derivation-encoded bins. FIG. 4 shows an illustration of residual encoding structure for transform blocks. Table 1 A. Rice parameter derivation process for abs_remainder[] and dec_abs_level[] ncnn in / cznz / B / Yi Inputs to this process are the base level baseLevel, the color component index cldx, the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight. The output of this process is the Rice parameter cRiceParam. Due to the AbsLevel[x][y] array for the transform block with component index cldx and upper left luma location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode: locSumAbs=0 if (xC < (1 « log2TbWidth) - 1) { locSumAbs += AbsLevel[xC + 1][yC] if (xC < (1 « log2TbWidth) - 2) locSumAbs += AbsLevel[xC + 2][yC] if (yC < (1 « log2TbHeight) - 1) locSumAbs += AbsLevel[xC + 1][yC + 1]} if (yC < (1 « log2TbHeight) - 1) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < (1 « log2TbHeight) - 2) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) Because of the variable locSumAbs, the Rice parameter cRiceParam is derived as specified in Table 1B below. When baseLevel is equal to 0, the variable ZeroPos[n] is derived as follows: ZeroPos[n]=(QState<2? 1:2) « cRiceParam Table 1B. Specification 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 Residual encoding for Transformer Hop Mode in VVC In transform hopping mode, the statistical characteristics of the residual signal differ from those of the transform coefficients, and no energy compaction was observed around the low-frequency components. The residual encoding is modified to account for different residual signal characteristics of transform hopping (spatial). FIG. 5 shows an illustration of residual encoding structure for transform jump blocks. General restriction information The GCI structure contains several types of restriction syntax elements, including: Flags for general bitstream restrictions, such as indicating that only intra-coding is being used, that all layers are encoded independently, or that the bitstream contains only one AU; Fields restricting the bit depth and chroma format of the encoded images; Flags indicating that certain types of NAL units are not allowed to be present within the bitstream; Flags restricting the ways in which images can be partitioned into slices, tiles, and sub-images within the bitstream; Flags restricting the size of CTUs, as well as the size and type of partition trees; Flags restricting the use of particular intra-coding tools; Flags restricting the use of particular inter-coding tools;Indicators that restrict residual coding, quantification, and transform tools; and Indicators that restrict aspects of loop filters. The purpose of the GCI syntax structure is to enable the simple discovery of configuration information about the features required for bitstream decoding and to allow the signaling of interoperability points that impose restrictions beyond those specified by Profile, Row, and Level (PTL), with finer granularity than allowed by previous video coding standards. Similar to subprofiles, the use of the GCI syntax structure could enable interoperability defined for decoder implementations that do not support all the features of a VVC profile but address the needs of particular applications.Decoder implementations can examine GCI syntax elements to check if a bitstream avoids the use of particular features, in order to determine how to configure the decoding process and identify whether the bitstream is decodable by the decoder. Decoder implementations that support all the features of a VVC profile can ignore the GCI syntax element values, since such decoders will be able to decode any bitstream that makes up the specified PTL. Residual coding for transform hop In accordance with aspect twenty-seven of the description, the use of variable sets of binary keywords is proposed to encode certain syntax elements, for example, abs_remainder, in transform jump residual coding. The selection is determined according to certain encoded information from the current block, for example, a quantization parameter or encoding bit depth associated with the TB / CB and / or the slice / profile, and / or according to a new flag associated with the TB / CB / slice / image / sequence level, for example, extended_precision_processing_flag. Different methods can be used to derive the variable sets of binary keywords, with some exemplary methods listed below. First, the same procedure for determining the keyword for `abs_remainder` as used in the current VVC was employed, but always with a fixed `rice` parameter (e.g., 2, 3, 4, 5, 6, 7, or 8) selected. The fixed value could differ under different conditions according to certain encoded information from the current block, such as quantization parameter, frame type (e.g., I, P, or B), component ID (e.g., luma or chroma), color format (e.g., 420, 422, or 444), or encoding bit depth associated with the TB / CB and / or the portion / profile, and / or according to a syntax element associated with the TB / CB / portion / image / sequence level, such as `rice_parameter_value`. A specific example is where TH1 to TH4 are predefined thresholds that satisfy (TH1 <TH2<TH3<TH4), y K0 a K4 son parámetros de rice predefinidos. Es importante notar que la misma lógica puede ser implementada de manera diferente en la práctica.For example, certain equations, or a lookup table, can also be used to derive the same rice parameters, from a BitDepth value of a current CU / Sequence. Second, fixed-length binarization. Third, truncated Rice binarization Fourth, truncated Binary (TB) binarization process. Fifth, k-th order of the Exp-Golomb binarization process (EGk). Sixth, limited k-th order of Exp-Golomb binarization. An example of a corresponding decoding process based on the VVC project is illustrated below. Changes to the VVC project are shown in Table 1 in bold and italic font, and deleted content is shown in italics. It is important to note that the same logic may be implemented differently in practice. For example, certain equations, or a lookup table, may also be used to derive the same parameters from rice. Table 1. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If transform_skip_flag[xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for Rice parameter cRiceParam is specified as follows. if(BitDepth <11) { rice parameter = 1} else it(BitDepth <13) { rice parameter = 4} else iffBitDepth <15) { rice parameter = 6} else { rice parameter = 8} Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC.yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In another example, it is proposed to use only a fixed value for the rice parameter in the encoding of the abs_remainder syntax element when the new flag, for example, extended_precision_processing_flag, is equal to 1. The corresponding decoding process based on the VVC Project is illustrated below, with changes in bold and italics and deleted content shown in italics. Changes to the VVC Project are shown in Table 2 in bold and italics. Table 2. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If extended_precision_processing_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to O, the derivation process for Rice parameter cRiceParam is specified as follows. if(BitDepth <11) { rice parameter = 1} else if(BitDepth <13) { rice parameter = 4} else if(BitDepth <15) { rice parameter = 6} else { rice parameter = 8} - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi In yet another example, when the new indicator, for example, extended_precision_processing_flag, is equal to 1, the Rice parameter cRiceParam is set to n, where n is a positive number (for example, 2, 3, 4, 5, 6, 7, or 8). The set value may be different under different conditions. An example of the corresponding decoding process based on the VVC Project is illustrated below, with changes in bold and italics and deleted content shown in italics. The changes for the VVC Project are shown in Table 3 in bold and italics. Table 3. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If extended_precision_processing_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh ts residual coding disabled flag is equal to 0, the Rice parameter cRiceParam is set equal to 7. - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh ts_residual_coding disabled-flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, when BitDepth is greater than or equal to the predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), the Rice parameter cRiceParam is set to n, where n is a positive number, e.g., 4, 5, 6, 7, or 8. The fixed value may be different under different conditions. An example of the corresponding decoding process based on the VVC Project is illustrated below, where TH is a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), with changes in bold and italics and removed content shown in italics. Changes to the VVC Project are shown in Table 4 in bold and italics. Table 4. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If BitDepth is greater than TH, transform_skip_flag[ xO ][ yO ][ cldx] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 7. - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi In yet another example, a control flag is signaled in the portion header to indicate whether Rice parameter signaling for transform jump blocks is enabled or disabled. When the control flag is signaled as enabled, an additional syntax element is signaled for each transform jump portion to indicate the Rice parameter for that portion. When the control flag is signaled as disabled (for example, set to "0"), no additional syntax element is signaled at the lowest level to indicate the Rice parameter for the transform jump portion, and a default Rice parameter (for example, 1) is used for the entire transform jump portion.An example of the corresponding decoding process based on Project VVC is illustrated below, where TH is a predefined value (e.g., 0, 1, 2), with changes shown in bold and italic font and deleted content shown in italic font. Changes to Project VVC are shown in Table 5 in bold and italic font. It is important to note that the sh_ts_residual_coding_rice_index can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, or of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Portion Header Syntax Table 5. Residual encoding syntax ncnn in / pznz / B / Yi slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hiding_used_flag) sh_ts_residual_coding_disabled_flag u(1) if(!sh_ts_residual_coding_disabled_flag) { sh_ ts_ residual_ coding_ rice_ flag u(1) if(sh_ts_residual_coding_rice_flag ) sh_ts_residual_coding_rice_index ue(v)} sh_ts_residual_coding_rice_flag equal to 1 specifies that sh_ts_residual_coding_rice_index might be present in the current portion. sh_ts_residual_coding_rice_flag equal to 0 specifies that sh_ts_residual_coding_rice_index is not present in the current portion. When sh_ts_residual_coding_rice_flag is not present, the value of sh_ts_residual_coding_rice_flag is inferred to be 0. Sh_ts_residual_coding_rice_ Index specifies the rice parameter used for the residual_ts_coding() syntax structure. Table 6. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If sh_ts_residual_coding_rice_flag is equal to 1, transform_skip_flag[ xO ][ yO][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (sh_ts_residual_coding_rice_ index+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary algorithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / cznz / e / Yi In yet another example, a control flag is set in the sequence parameter set (or in the range extension syntax of the sequence parameter set) to indicate whether Rice parameter signaling for transform jump blocks is enabled or disabled. When the control flag is set to enabled, an additional syntax element is signaled for each transform jump portion to indicate the Rice parameter for that portion. When the control flag is set to disabled (for example, set to 0), no additional syntax element is signaled at the lowest level to indicate the Rice parameter for the transform jump portion, and a default Rice parameter (for example, 1) is used for the entire transform jump portion. An example of the corresponding decoding process based on the VVC Project is illustrated below, where TH is a predefined value (e.g., 0, 1, 2). Changes from the VVC Project are shown in Table 7 in bold and italic font, and deleted content is shown in italic font. It is important to note that sh_ts_residual_coding_r¡cejdx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. RBSP Syntax of the Sequence Parameter Set Table 7. Residual coding syntax seq_parameter_set_rbsp() { Descriptor sps_sign_data_hiding_enabled_flag u(1) sps_ts_residual_coding_ríce_present_in_sh_flag uW sps_virtual_boundaries_enabled_flag u(1)} `ncnn in / cznz / B / Yi sps_ts_residual_coding_rice_present_in_sh_flag` equal to 1 specifies that `sh_ts_residual_coding_rice_present_in_sh_flag` could be present in SH syntax structures referencing SPS. `sps_ts_residual_coding_rice_present_in_sh_flag` equal to 0 specifies that `sh_ts_residual_coding_rice_present_in_sh_flag` is not present in SH syntax structures referencing SPS. When `sps_ts_residual_coding_rice_present_in_sh_flag` is not present, the value of `sps_ts_residual_coding_rice_present_in_sh_flag` is inferred to be 0. Portion Header Syntax Table 8. Residual coding syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_h¡d¡ng_used_flag ) sh_ts_residual_cod¡ng_d¡sabled_flag u(l) if((!sh_ts_residual_coding_disabled_flag) && sps_ts_residual_coding_rice_enabled_flag ) sh_ts_residual_coding_rice_idx ue(v)} sh_ts_residual_coding_rice_idx specifies the rice parameter used for the residual_ts_coding() syntax structure. Table 9. Rice parameter derivation process The Rice parameter cRiceParam is derived as follows: - If sps_ts_residual_coding_rice_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (sh_ts_residual_coding_rice_ idx+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In one or more examples in the disclosure, it is proposed to disable the presence of Rice's parameter for residual transform skip coding if the transform skip is disabled. In one specific example, to achieve this design purpose, it is proposed to use `sps_transform_skip_enabled_flag` to condition the presence of `sps_ts_residual_coding_rice_present_in_sh_flag`. For example, when the `sps_transform_skip_enabled_flag` flag is zero (i.e., the transform skip is disabled in the current image), `sps_ts_residual_coding_rice_present_in_sh_flag` is not signaled but inferred to be 0. When the `sps_transform_skip_enabled_flag` flag is one, `sps_ts_residual_coding_rice_present_in_sh_flag` is additionally signaled. The change to the current VVC Work Project is shown in italicized font below. ncnn in / cznz / B / Yi if( sps_transform_skip_enabled_flag) sps_ts_residual_coding_rice_present_in_sh_flag u(1) In another specific example, to fulfill this design purpose, it is proposed to add a bitstream conformance requirement related to sps_transform_skip_enabled_flag for sps_ts_residual_coding_rice_present_in_sh_flag. For example, it is a bitstream conformance requirement that the value of sps_ts_residual_coding_rice_present_in_sh_flag will be equal to 0 when sps_transform_skip_enabled_flag is equal to 0. The change to VVC Working Project is shown in italics below. Sequence parameter set range extension semantics: sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_present_in_sh_flag can be present in slice_header() syntax structures referencing SPS. sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 specifies that sh_ts_residual_coding_rice_present_in_sh_flag is not present in slice_header() syntax structures referencing SPS. When sps_ts_residual_coding_rice_present_in_sh_flag is not present, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be 0. It is a bitstream conformance requirement that the value of sps_ts_residual_coding_rice_present_in_sh_flag will be equal to 0 when sps_transform_skip_enabled_flag is equal to 0. In yet another example, when the transform skip flag (sps_transform_skip_enabled_flag) is set to enabled, a control flag is also set on the sequence parameter (or in the range extension syntax of the sequence parameter set) to indicate whether Rice parameter signaling for transform skip blocks is enabled or disabled. When the control flag is set to enabled, a syntax element is also set for each transform skip portion to indicate the Rice parameter for that portion. When the control flag is set to disabled (for example, set to 0), no additional syntax element is set at the lowest level to indicate the Rice parameter for the transform skip portion, and a default Rice parameter (for example, 1) is used for every transform skip portion.An example of the corresponding decoding process based on the VVC Project is illustrated below. Changes to the VVC Project are shown in italics. RBSP sequence parameter set syntax. ncnn in / pznz / B / Yi seq_parameter_set_rbsp() { Descriptor sps_sign_data_hiding_enabled_flag u(1) if( sps_transform_skip_enabled_flag ) sps_ts_residual_coding_rice_present_in_sh_flag sps_virtual_boundaries_enabled_flag u(1)} sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx could be present in SH syntax structures referencing SPS. sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 specifies that sh_ts_residual_coding_rice_idx_minus1 is not present in SH syntax structures referencing SPS. When sps_ts_residual_coding_rice_present_in_sh_flag is not present, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be 0. Portion Header Syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hid¡ng_used_flag ) sh_ts_residual_coding_disabled_flag u(1) ¡f((!sh_ts_residual_coding_disabled_flag) && sps_ts_residual_coding_rice_present_in_sh_flag) sh_ ts_residual_coding_rice_idx_minus 1} sh_ts_residual_coding_rice_idx_minus1 plus 1 specifies the parameter of rice used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_idx_minus1 is not present, the value of sh_ts_residual_coding_rice_idx_minus1 is inferred to be equal to 0. 9.3.3.11 Binarization process for abs_remainder[] The input to this process is a request for a binarization for the syntax element abs_remainder[n], the color component index cldx, the current sub-block index i, and the luma location (x0,y0) specifying the upper left sample of the current luma transform block relative to the upper left luma sample of the image, the current coefficient scan location (xC,yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight. The output of this process is the binarization of the syntax element. The variables lastAbsRemainder and lastRiceParam are derived as follows: - If this process is invoked for the first time for the current sub-block index i, lastAbsRemainder and lastRiceParam are both set equal to 0. - Otherwise (if this process is not invoked for the first time for the current sub-block index i), lastAbsRemainder and lastRiceParam are set equal to the values ​​of abs_remainder[n] and cRiceParam, respectively, that were derived during the last invocation of the binarization process for the syntax element abs_remainder[n] as specified in this clause. The rice parameter cRiceParam is derived as follows: - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to sh_ts_residual_coding_ricejdx_minus1+1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in clause 9.3.3.2 with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block width log2TbHeight as inputs. In yet another example, a syntax element is signaled for each transform jump portion to indicate the Rice parameter for that portion. An example of the corresponding decoding process based on the VVC Project is illustrated later. The changes in the VVC Project are shown in Table 10 in bold and italic font. It is important to note that sh_ts_residual_coding_rice_idx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, or of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Portion Header Syntax Table 10. Residual coding syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hiding_used_flag) sh_ts_residual_coding_disabled_flag u(1) if(!sh_ts_residual_coding_disabled_flag) sh_ts_residual_coding_ríce_idx ue(v)} sh_ts_residual_coding_rice_idx specifies the parameter of rice used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_idx is not present, the value of sh_ts_residual_coding_rice_idx is inferred to be 0. Table 11. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to sh ts residual coding rice idx+l. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the scan location of the current coefficient (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, a control flag is signaled in the range extension syntax of the image parameter set to indicate whether Rice parameter signaling for transform jump blocks is enabled or disabled. When the control flag is signaled as enabled, an additional syntax element is signaled to indicate the Rice parameter for that image. When the control flag is signaled as disabled (for example, set to “0”), no additional syntax element is signaled at the lowest level to indicate the Rice parameter for the transform jump portion, and a default Rice parameter (for example, 1) is used for the entire transform jump portion. An example of the corresponding decoding process based on the VVC Project is illustrated later, where TH is a predefined value (for example, 0, 1, 2).Changes to the VVC Project are shown in Table 12 in bold and italic font. It is important to note that pps_ts_residual_coding_rice_idx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Syntax of Range Extensions of the Image Parameter Set Table 12. Residual coding syntax pps_range_extensions() { Descriptor pps _ts_residual_coding_rice _flag u(l) if(pps_ts_residual_coding_rice_Jlag ) pps_ts_residual_coding_rice_idx ue(v)} A value of pps_ts_residual_coding_rice_flag equal to 1 specifies that pps_ts_residual_coding_rice_index might be present in the current image. A value of pps_ts_residual_coding_rice_flag equal to 0 specifies that pps_ts_residual_coding_rice_idx is not present in the current image. When pps_ts_residual_coding_rice_flag is not present, the value of pps_ts_residual_coding_rice_flag is inferred to be 0. pps_ts_residual_coding_rice_idx specifies the rice parameter used for the residual_ts_coding() syntax structure. Table 13. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If pps_ts_residual_coding_rice_flag is equal to 1, - transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (pps_ts_residual_coding_rice_ idx+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, color component index cldx, luma location (xO, yO), current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, it is proposed to use only one variant rice parameter for encoding the abs_remainder syntax element. The value of the applied rice parameter can be determined according to certain encoded information from the current block, such as block size, quantization parameter, bit depth, transform types, etc. In one specific mode, it is proposed to adjust the rice parameter based on the encoding bit depth and quantization parameter applied to a CU. The corresponding decoding process based on the VVC project is illustrated below. Changes to the VVC project are shown in Table 14 in bold and italic font, and deleted content is shown in italics. It is important to note that the same logic may be implemented differently in practice.For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. ncnn in / cznz / B / Yi Table 14. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: S / transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. if(BitDepth <11) {rice parameter = 1} else if(BitDepth<13) {¡f(QPcu<-15){ rice parameter = 6} else if(QPcu <-10) { rice parameter = 5} else if(QPcu <0) { rice parameter = 4} else if(QPcu<10) { ríce parameter = 3} else { ríce parameter = 2}} else if(BitDepth<15) {if(QPcu <-25) { ríce parameter = 7} else iffQPcu <-15) { rice parameter = 6} else if(QPcu <-10) { ríce parameter = 5} else { rice parameter = 4}} else { if(QPcu <-30) { ríce parameter = 8} else if(QPcu <-25) { ríce parameter =7} else if(QPcu <-15) { rice parameter = 6} else if(QPcu <-10) { ríce parameter = 5} else { ríce parameter = 4}} Otherwise, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO,yO), the current coefficient scan location (xC,yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where TH is a predefined threshold (e.g., 33 or 34). Changes to the VVC Project are shown in Table 15 in bold and italic font, and deleted content is shown in italics. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same parameters from rice. Table 15. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If transform_skip_flag[xO ][ yO][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, 8, Floor( (TH - BitDepth -QPcu) / 6 ) ) - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the logarithm of the transform block height log2TbHeight as inputs. In yet another example, the corresponding decoding process based on the VVC project is illustrated as follows, where THa and THb are predefined thresholds (e.g., THa=8, THb=33 or 34). Changes to the VVC Project are shown in Table 16 in bold and italic font, and deleted content is shown in italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 16. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: If transform_skip_flag[ xO ][ yO ][ cldx] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, BitDepth - THa, Floorf (THb - BitDepth -QPcu) / 6 ) ) Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbW¡dth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi In yet another example, it is proposed to use only one variant rice parameter for encoding the syntax element of `abs_remainder` when the new flag, for example, `extended_precision_processing_flag`, is equal to 1. The variant value can be determined according to certain encoded information of the current block, such as block size, quantization parameter, bit depth, transform types, and so on. In one specific mode, it is proposed to adjust the rice parameter based on the encoding bit depth and the quantization parameter applied to a CU. The corresponding decoding process based on the VVC Project is illustrated later. The changes to the VVC Project are shown in Table 17 in bold and italic font. It is important to note that the same logic may be implemented differently in practice.For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 17. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: If extended_precision_processing_flag is equal to 1, transform skip flagf xO ][ yO ][ cldx ] is equal to 1 and sh ts residual coding disabled flag is equal to 0, the derivation process for Rice parameter cRiceParam is specified as follows. ifQPcu <-30) { rice parameter = 8} else iffQPcu <-25) { rice parameter = 7} else iffQPcu <-15) { rice parameter = 6} else iffQPcu <-10) { rice parameter = 5} else iffQPcu <0) { rice parameter = 4} else iffQPcu <10) { rice parameter = 3} else iffQPcu <15) { rice parameter = 2} else { rice parameter = 1} If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnn in / pznz / R / Yi In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where TH is a predefined threshold (e.g., 18, 19). The changes to the VVC Project are shown in Table 18 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 18. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If extended_precision_processing_flag is equal to 1, transform_skip_flag[ xO ][ yO][ cldx ] is equal to 1 and sh_ts_resldual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, 8, (TH - QP) / 6 ) - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, the corresponding decoding process based on the VVC Project is illustrated below, where THay and THb are predefined thresholds (e.g., THa=8, THb=18 or 19). Changes to the VVC Project are shown in Table 19 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. ncnfrLn / eznz / e / Yi Table 19. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If extended_precision_processing_flag is equal to 1, transform_skip_flag[xO][yO][cldx] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to O, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, BitDepth - THa, (THb - QP) / 6) - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. Figure 6 shows a method for video encoding. The method can be applied to an encoder, for example. In step 1610, the encoder receives a video input. The video input could be a live stream, for example. In step 1612, the encoder obtains a quantization parameter based on the video input. The quantization parameter can be calculated using the encoder's quantization unit. In step 1614, the encoder derives a rice parameter based on at least one predefined threshold, an encoding bit depth, and the quantization parameter. The rice parameter is used for syntax signaling of abs_remainder and dec_abs_level. In step 1616, the encoder encodes a video bitstream using entropy based on the rice parameter.The video bitstream, for example, can be encoded by entropy to generate a compressed video bitstream. In yet another example, it is proposed to use only a fixed value (e.g., 2, 3, 4, 5, 6, 7, or 8) for the rice parameter in the syntax element encoding for abs_remainder when BitDepth is greater than 10. The fixed value can be different under different conditions according to certain encoded information in the current block, such as a quantization parameter. The corresponding decoding process based on the VVC Project is illustrated below, where TH is a predefined threshold (e.g., 18, 19). Changes to the VVC Project are shown in Table 20 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. ncnn in / cznz / B / Yi Table 20. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If BitDepth is greater than 10, transform_skip_fiag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, 8, (TH - QP) / 6 ) If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where THa and THb are predefined thresholds (e.g., THa=8, THb=18 or 19). Changes to the VVC Project are shown in Table 21 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 21. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: If BitDepth is greater than 10, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, BitDepth - THa, (THb - QP) / 6) If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / cznz / e / Yi In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where TH is a predefined threshold (e.g., 33 or 34). Changes to the VVC Project are shown in Table 22 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 22. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: - If BitDepth is greater than 10, transform_skip_flag[ xO][ yO][ cldx] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, 8, (TH - BitDepth -QPcu) / 6) - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where THa and THb are predefined thresholds (e.g., THa=8, THb=33 or 34). The changes to the VVC Project are shown in Table 23 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 23. Rice parameter derivation process The rice parameter cRiceParam is derived as follows: If BitDepth is greater than 10, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the rice parameter cRiceParam is specified as follows. Rice parameter = Clip3( 1, BitDepth THa, (THb - BitDepth -QPcu) / 6) If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the primary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnn in / pznz / B / Yi It is important to mention that in the illustrations above, the equations used to calculate the specific rice parameters are only used as examples to illustrate the proposed ideas. For someone familiar with modern video coding techniques, other mapping functions (or equivalently, mapping equations) are already applicable to the proposed idea (i.e., determining the transform-hop mode rice parameter based on the encoding bit and applied quantization parameter). Meanwhile, it should be mentioned that in the current VVC design, the value of the applied quantization parameter is allowed to change at the group level of the encoding block. Therefore, the proposed rice parameter adjustment scheme can provide flexible adaptation of the transform-hop mode rice parameters at the group level of the encoding block. Signaling information for Regular Residual Coding and Transformer Jump Residual Coding In accordance with aspect twenty-eight of the disclosure, it is proposed to signal a binary keyword rice parameter to encode certain syntax elements, e.g., abs_remainder in transform hop residual coding, offset and deviation parameters for derivation of the rice parameter used for abs_remainder / dec_abs_level in regular residual coding, and to determine whether to signal according to certain encoded information of the current block, e.g., quantization parameter or encoding bit depth associated with TC / CB and / or slice / profile, and / or according to a new flag associated with the TB / CB / slice / picture / sequence level, e.g., sps_residual_coding_info_present_in_sh_flag. In one example, a control flag is set in the portion header to indicate whether Rice parameter signaling for transform jump blocks and shift and / or offset parameter signaling for deriving the Rice parameter in transform blocks are enabled or disabled. When the control flag is set to enabled, one additional syntax element is set for each transform jump portion to indicate the Rice parameter for that portion, and two additional syntax elements are set for each transform portion to indicate the shift and / or offset parameters for deriving the Rice parameter for that portion.When the control flag is flagged as disabled (e.g., set to “0”), the syntax element at the lowest level to indicate the Rice parameter for the transform jump portion is no longer flagged, and a default Rice parameter (e.g., 1) is used for the entire transform jump portion. Similarly, the syntax element at the lowest level to indicate the shift and offset parameters for deriving the Rice parameter for the transform portion is no longer flagged, and default offset and / or offset parameters (e.g., 0) are used for the entire transform portion. An example of the corresponding decoding process based on the VVC Project is illustrated below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC Project are shown in Table 24 in bold and italic font.It is important to note that the sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_index can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Figure 7 shows a method for video encoding. The method can be applied, for example, to an encoder. In step 1710, the encoder receives a video input. In step 1712, the encoder signals a binary keyword rice parameter for encoding syntax elements. The encoding syntax elements can include `abs_remainder` in transform hop residual encoding. In step 1714, the encoder entropy-encodes a video bitstream based on the rice parameter and the video input. Portion Header Syntax Table 24. Residual coding syntax ncnn i Π / Ρ7Π7 / Β / ΥΙ slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hid¡ng_used_flag ) sh_ts_residual_coding_disabled_flag u(1) sh_residual_coding_rice_flag u(1) if(sh_ts_residual_coding_rice_flag) { sh_residual_coding_rice_shift ue(v) sh_residual_coding_rice_offset ue(v) if(!sh_ts_residual_coding_disabled_flag) sh_ts_residual_coding_rice_index ue(v)} sh_residual_coding_rice_flag igual a 1 especifica que sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, y sh_residual_coding_r¡ce_¡ndex podrían estar presentes en la porción actual. sh_residual_coding_rice_flag igual a 0 especifica que sh_residual_cod¡ng_r¡ce_sh¡ft, sh_residual_coding_rice_offset, y sh_residual_coding_rice_index no están presentes en la porción actual. sh_residual_coding_rice_shift specifies the shift parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ]. When sh_residual_coding_rice_shift is not present, the value of sh_residual_coding_rice_shift is inferred to be 0. sh_residual_coding_rice_offset specifies the offset parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ]. When sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be equal to 0. sh_ts_residual_coding_rice_index specifies the parameter of rice used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_index is not present, the value of sh_ts_residual_coding_rice_index is inferred to be 0. Table 25. Rice parameter derivation process Binarization process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: - If sh_residual_coding_rice_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (sh_ts_residual_coding_rice_index+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi Table 26. Rice parameter derivation process Rice parameter derivation process for abs_remainder[ ] and dec abs level[ ] The inputs to this process are the base level (baseLevel), the color component index (cldx), the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the scan location of the current coefficient (xC, yC), the binary logarithm of the transform block width (log2TbWidth), the binary logarithm of the transform block height (log2TbHeight), sh_residual_coding_rice_shiñ, and sh_residual_coding_rice_offset The output of this process is the Rice parameter cRiceParam. Due to the AbsLevel[ x ][ y ] array for the transform block with component index cldx and upper left luma location (xO, yO ), the locSumAbs variable is derived as specified by the following pseudocode: ; 1 ) locSumAbs += AbsLevel xC +1 ][ yC +1 ]} if ( yC < ( 1 « log2TbHeight ) - 1 ) { locSumAbs += AbsLevelj xC ][ yC + 1 ] if( yC < ( 1 « log2TbHeight ) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} locSumAbs = Clip3( 0 , 31 , (( locSumAbs + sh_residual_coding_rice_offset)» sh_residual_coding_rice_shift) - baseLevel * 5 ) . Due to the locSumAbs variable, the Rice parameter cRiceParam is derived specified in Table 1B. cRiceParam = cRiceParam+ sh_residual_coding_rice_shift When baseLevel is equal to 0, the variable ZeroPos[ n ] is derived as follows: ZeroPos [ n ] = ( QState < 2 ? 1 : 2 ) « cRiceParam In another example, a control flag is set in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether Rice parameter signaling for transform jump blocks and shift and / or offset parameter signaling for deriving the Rice parameter in transform blocks are enabled or disabled. When the control flag is set to enabled, one additional syntax element is set for each transform jump portion to indicate the Rice parameter for that portion, and two additional syntax elements are set for each transform portion to indicate the shift and / or offset parameters for deriving the Rice parameter for that portion.When the control flag is flagged as disabled (e.g., set to “0”), the syntax element at the lowest level no longer flags the Rice parameter for the transform jump portion, and a default Rice parameter (e.g., 1) is used for the entire transform jump portion. Similarly, the syntax element at the lowest level no longer flags the shift and / or offset parameters for deriving the Rice parameter for the transform portion, and default shift and / or offset parameters (e.g., 0) are used for the entire transform portion. An example of the corresponding decoding process based on the VVC Project is illustrated below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC Project are shown in Table 27 in bold and italic font.It is important to note that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. RBSP Syntax for Sequence Parameter Set Table 27. Residual encoding syntax ncnn i η / R7R7 / B / γι seq_parameter_set_rbsp() { Descriptor sps_sign_data_hid¡ng_enabled_flag u(1) sps_residual_coding_info_present_in_sh_flag u(1) sps_virtual_boundaries_enabled_flag u(1)} sps_residual_coding_info_present_in_sh_flag equal to 1 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx could be present in SH syntax structures referencing SPS. sps_residual_coding_info_present_in_sh_flag equal to 0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx are not present in SH syntax structures referencing SPS. When sps_residual_coding_info_present_in_sh_flag is not present, the value of sps_residual_coding_info_present_in_sh_flag is inferred to be 0. Portion Header Syntax Table 28. Residual coding syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hid¡ng_used_flag) sh_ts_residual_coding_d¡sabled_flag u(1) if(sps_ts_residual_coding_ríce_enabled _flag) { sh_residual_coding_rice_shift ue(v) sh_residual_coding_rice_offset ue(v) ¡f(!sh_ts_residual_cod¡ng_disabled_flag) sh_ts_residual_coding_rice_index ue(v)}} sh_residual_coding_rice_shift specifies the shift parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ]. When sh_residual_coding_rice_shift is not present, the value of sh_residual_coding_rice_shift is inferred to be 0. sh_residual_coding_rice_offset specifies the offset parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ]. When sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be 0. sh_ts_residual_coding_rice_idx specifies the parameter of rice used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_index is not present, the value of sh_ts_residual_coding_rice_index is inferred to be 0. Table 29. Rice parameter derivation process Binarization process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: - If sps_ts_residual_coding_info_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (sh_ts_residual_coding_rice_idx+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi Table 30. Rice parameter derivation process Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ] The inputs to this process are the base level baseLevel, the color component index cldx, the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, the binary logarithm of the transform block height log2TbHeight, sh_residual_coding_rice_shift, and sh_residual_coding_rice_offset. The output of this process is the Rice parameter cRiceParam. Due to the array AbsLevel[ x ][ y ] for the transform block with component index cldx and upper left luma location ( xO, yO ), the variable locSumAbs is derived as specified by the following pseudocode: locSumAbs = 0 if( xC < (1 « log2TbWidth) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < (1 « log2TbWidth) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < (1 « log2TbHeight) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ]} if( yC < (1 « log2TbHeight) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < (1 « log2TbHeight) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} locSumAbs = Clip3( 0, 31, f (1ocSumAbs+ sh_residual_coding_rice_offset)>> sh_residual_coding_rice_shift) - baseLevel * 5 ) Due to the variable locSumAbs, the Rice parameter cRiceParam is derived as specified in Table 1B. cRiceParam = cRiceParam+ sh_residual_coding_rice_shift When baseLevel is equal to 0, the variable ZeroPosj n ] is derived as follows: ZeroPos[ n ] = ( QState < 2 ? 1:2) « cRiceParam ncnfrLn / pznz / e / Yi In yet another example, one syntax element is signaled for each transform jump portion to indicate the Rice parameter of that portion, and two syntax elements are signaled for each transform portion to indicate the shift and / or offset parameters for deriving the Rice parameter of that portion. An example of the corresponding decoding process based on the VVC Project is illustrated as follows. Changes to the VVC Project are shown in Table 31 in bold and italic font. It is important to note that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Portion Header Syntax Table 31. Residual coding syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hid¡ng_used_flag) sh_ts_residual_coding_disabled_flag u(1) if(!sh_ts_residual_coding_disabled_flag) sh_ts_residual_coding_rice_idx ue(v) sh_residual_coding_rice_shift ue(v) sh_residual_coding_rice_offset ue(v)} sh_ts_residual_coding_rice_idx specifies the rice parameter used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_idx is not present, the value of sh_ts_residual_coding_rice_idx is inferred to be 0. sh_residual_coding_rice_offset specifies the offset parameter used for the derivation process of the Rice parameters abs_remainder[ ] and dec_abs_level[ ]. When sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be equal to 0. sh_ts_residual_coding_rice_idx specifies the parameter of rice used for the residual_ts_coding() syntax structure. When sh_ts_residual_coding_rice_index is not present, the value of sh_ts_residual_coding_rice_index is inferred to be equal to 0. Table 32. Rice parameter derivation process Binarization process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to sh ts residual coding rice idx+1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs Table 33. Rice parameter derivation process Rice parameter derivation process for abs_remainder[ ] and dec abs Jevelf ] The inputs to this process are the base level baseLevel, the color component index cldx, the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the scan location of the current coefficient (xC, yC), the binary logarithm of the transform block width log2TbWidth, the binary logarithm of the transform block height log2TbHeight, sh_residual_coding_rice_shift, and sh_residual_coding_rice_offset. The output of this process is the Rice parameter cRiceParam. Due to the AbsLevel[ x ][ y ] array for the transform block with component index cldx and upper left luma location (xO, yO), the locSumAbs variable is derived as specified by the following pseudocode: locSumAbs = 0 if(xC < (1 «log2TbWidth) - 1) { locSumAbs += AbsLevel[ xC +1 ][ yC ] if( xC < (1«log2TbWidth) - 2) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC <2TbWidth) 1 locSumAbs += AbsLevel[ xC +1 ][ yC +1 ]} if( yC < (1 «log2TbHeight) - 1) { locSumAbs += AbsLevel[ xC ][ yC +1 ] if( yC < (1 «log2TbHeight) - 2) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} locSumAbs = Clip3( 0,31, ((locSumAbs+ sh_residual_coding_rice_offset)» sh_residual_coding_rice_shift) - baseLevel * 5) Due to the locSumAbs variable, the Rice cRiceParam parameter is derived specified in Table 1B. cRiceParam = cRiceParam+ sh_residual_coding_rice_sh¡ft When baseLevel is equal to 0, the variable ZeroPos[ n ] is derived as follows: ZeroPos[ n ] = (QState < 2 ? 1: 2) « cRiceParam In yet another example, a control flag is set in the syntax for the image parameter's set range extensions to indicate whether Rice parameter signaling for transform jump blocks and offset and / or deviation parameter signaling for Rice parameter derivation in transform blocks are enabled or disabled. When the control flag is set to enabled, one syntax element is further set to indicate the Rice parameter for transform jump residual encoding of that image, and two additional syntax elements are set for regular residual encoding to indicate the offset and / or deviation parameters for Rice parameter derivation of that image.When the control flag is flagged as disabled (e.g., set to “0”), the syntax element at the lowest level to indicate the Rice parameter for transform jump residual encoding is no longer flagged, and a default Rice parameter (e.g., 1) is used for all transform jump residual encoding. Furthermore, the syntax element at the lowest level to indicate the shift and / or offset parameters for deriving the Rice parameter for regular residual encoding is no longer flagged, and default shift and / or offset parameters (e.g., 0) are used for all regular residual encoding. An example of the corresponding decoding process based on the VVC project is illustrated below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC Project are shown in Table 34 in bold and italic font.It is important to note that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_residual_coding_ricejdx can be encoded in different ways and / or can have the maximum value. For example, u(n), an unsigned integer using n bits, and of(n), a fixed-pattern bit string using n bits written (from left to right) with the leftmost bit first, can also be used to encode / decode the same syntax element. Syntax of Image Parameter Set Range Extensions Table 34. Syntax of the residual encoding ncnn in / cznz / B / Yi pps_range_extensions() { Descriptor pps residual coding info flag u(1) if(pps_ts_residual_coding_rice_flag ) pps_residual_coding_rice_shift ue(v) pps_resídual_codíng_rice_offset ue(v) pps_ts_residual_coding_rice_idx ue(v)} pps_residual_coding_info_flag equal to 1 specifies that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_index might be present in the current image. pps_residual_coding_info_flag equal to 0 specifies that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_index are not present in the current image. When pps_residual_coding_info_flag is not present, the value of pps_residual_coding_info_flag is inferred to be 0. pps_residual_coding_rice_shift specifies the shift parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ]. When pps_residual_coding_rice_shift is not present, the value of pps_residual_coding_rice_shift is inferred to be equal to 0. pps_residual_coding_rice_offset specifies the offset parameter used for the Rice parameter derivation process for abs_remainder[ ] and dec_absjevel[ ]. When pps_residual_coding_rice_offset is not present, the value of pps_residual_coding_rice_offset is inferred to be equal to 0. pps_ts_residual_coding_rice_idx specifies the rice parameter used for the residual_ts_coding() syntax structure. When pps_ts_residual_coding_ricejndex is not present, the value of pps_ts_residual_coding_ricejndex is inferred to be 0. Table 35. Rice parameter derivation process Blanking process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: - If pps_ts_residual_coding_rice_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to (pps_ts_residual_coding_rice_ idx+TH). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[ ] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO ), the current coefficient scan location (xC, yC ), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / cznz / e / Yi Table 36. Rice parameter derivation process Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ] Inputs to this process are the base level baseLevel, the color component index cldx, the luma location ( xO, yO ) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the scan location of the current coefficient ( xC, yC ), the binary logarithm of the transform block width log2TbWidth, the binary logarithm of the transform block height log2TbHeight, pps residual coding rice shift, and pps_residual_coding_rice_offset. The output of this process is the Rice parameter cRiceParam. Due to the array AbsLevel[ x ][ y ] for the transform block with component index cldx and upper left luma location ( xO, yO ), the variable locSumAbs is derived as specified by the following pseudocode: locSumAbs = 0 if( xC < (1 « log2TbWidth) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < (1 « log2TbWidth) - 2) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < (1 « log2TbHeight) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ]} if( yC < (1 « log2TbHeight) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < (1 « log2TbHeight) - 2) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} locSumAbs = Clip3( 0, 31, f (1ocSumAbs+ pps_residual_coding_ríce_offset)» pps residual coding ríce shift) - baseLevel *5) Due to the variable locSumAbs, the Rice parameter cRiceParam is derived as specified in Table 1B. cRiceParam = cRiceParam+ pps_residual_coding_rice_shift When baseLevel is equal to 0, the variable ZeroPos[ n ] is derived as follows: ZeroPos[ n ] = ( QState < 2 ? 1:2) « cRiceParam ncnfrLn / eznz / e / Yi According to aspect twenty-nine of the description, it is proposed to use different rice parameters to encode certain syntax elements, for example abs_remainder in transform jump residual coding, offset and deviation parameters for derivation of the rice parameter used for abs_remainder / dec_abs_level in regular residual coding, and to determine which to use according to certain encoded information of the current block, for example quantization parameter or encoding bit depth associated with TB / CB and / or the portion / profile, and / or according to a new flag associated with the TB / CB / portion / image / sequence level, for example sps_residual_coding_info_presentjn_sh_flag. In one example, a control flag is set in the portion header to indicate whether the Rice parameter derivation process for transform jump blocks and the process for deriving the shift and / or deviation parameters for the Rice parameter in transform blocks are enabled or disabled. When the control flag is set to enabled, the Rice parameter can differ under different conditions according to certain encoded information in the current block, such as the quantization parameter and bit depth. Similarly, the shift and / or deviation parameters for deriving the Rice parameter in regular residual encoding can differ under different conditions according to certain encoded information in the current block, such as the quantization parameter and bit depth.When the control indicator is signaled as disabled (e.g., set to “0”), a default Rice parameter (e.g., 1) is used for the entire leap portion of the transform, and default shift and / or offset parameters (e.g., 0) are used for the entire transform portion. An example of the corresponding decoding process based on the VVC Project is illustrated later, where THa and THb are predefined thresholds (e.g., THa=8, THb=18 or 19). Changes to the VVC Project are shown in Table 37 in bold and italic font. It is important to note that the same logic may be implemented differently in practice. For example, certain equations, or a lookup table, may also be used to derive the same Rice parameters. Portion Header Syntax Table 37. Residual coding syntax slice_header() { Descriptor if( sps_transform_skip_enabled_flag && !sh_dep_quant_used_flag && !sh_sign_data_hiding_used_flag) sh ts residual coding disabled flag u(1) sh_residual_coding_rice_flag u(1) sh_residual_coding_rice_flag equal to 1 specifies that the bit-depth-dependent rice parameter derivation process is used in the current portion. sh_residual_coding_rice_flag equal to 0 specifies that the bit-depth-dependent rice parameter derivation process is not used in the current portion. Table 38. Rice parameter derivation process Binarization process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: - If sh_residual_coding_rice_flag is equal to 1, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to O, the Rice parameter cRiceParam is set equal to Clip3( 1, BitDepth - THa, (THb - QP) / 6 ). - If transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set to 1. - Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. ncnfrLn / eznz / e / Yi Table 39. Rice parameter derivation process Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ] Inputs to this process are the base level baseLevel, the color component index cldx, the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the scan location of the current coefficient (xC, yC), the binary logarithm of the transform block width log2TbWidth, the binary logarithm of the transform block height log2TbHeight, sh_residual_coding_rice_flag. The output of this process is the Rice parameter cRiceParam. Due to the AbsLevel[ x ][ y ] array for the transform block with component index of cldx and upper left luma location (xO, yO), the locSumAbs variable is derived as specified by the following pseudocode: ShiftRice = sh_residual_coding_rice_flag ? ( BitDepth > 10 ) ? Floor ( Log2 ( 4 * ( BitDepth - 10 )) ): 0 : 0 OffsetRice = sh_residual_coding_rice_onion ? ( ShiftRice > 0 ) ? (1«(ShiftRice1)):0:0 locSumAbs = 0 if( xC < (1«log2TbWidth) - 1) { locSumAbs += AbsLevel[ xC +1 ][ yC ] if(xC < (1 «log2TbWidth) - 2) locSumAbs += AbsLevelj xC + 2 ][ yC ] if( yC < (1 «log2TbHeight) - 1) locSumAbs += AbsLevelj xC+1][yC+1]}; if( yC < (1«log2TbHeight) - 1) { locSumAbs += AbsLevel[ xC ][ yC +1 ] if( yC < (1«log2TbHeight) - 2) locSumAbs += AbsLevelj xC ][ yC + 2 ]}; locSumAbs = Clip3( 0.31, ((locSumAbs + OffsetRice)» ShiftRice) - baseLevel*5) Due to the locSumAbs variable, the Rice parameter cRiceParam is derived as specified in Table 1B. cRiceParam = cRiceParam + ShiftRice When baseLevel is equal to 0, the variable ZeroPos[ n ] is derived as follows: ZeroPos[ n | = ( QState < 2 ? 1 : 2 ) « cRiceParam In yet another example, the corresponding decoding process based on the VVC Project is illustrated as follows, where TH is a predefined threshold (e.g., 18, 19). Changes to the VVC Project are shown in Table 40 in bold and italic font. It is important to note that the same logic can be implemented differently in practice. For example, certain equations, or a lookup table, can also be used to derive the same rice parameters. Table 40. Rice parameter derivation process Binarization process for abs_remainder[ ] The rice parameter cRiceParam is derived as follows: If BitDepth is greater than 10, transform_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the derivation process for the Rice parameter cRiceParam is specified as follows. rice parameter = Clip3( 1, 8, (TH - QP) / 6) If transiórm_skip_flag[ xO ][ yO ][ cldx ] is equal to 1 and sh_ts_residual_coding_disabled_flag is equal to 0, the Rice parameter cRiceParam is set equal to 1. Alternatively, the rice parameter cRiceParam is derived by invoking the rice parameter derivation process for abs_remainder[] as specified in Table 1A with the baseLevel variable set equal to 4, the color component index cldx, the luma location (xO, yO), the current coefficient scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight as inputs. Rice parameter derivation process for abs_remainder[ ] and dec_abs_level[ ] Inputs to this process are the base level baseLevel, the color component index cldx, the luma location (xO, yO) specifying the upper left sample of the current transform block relative to the upper left sample of the current image, the scan location of the current coefficient (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight. The output of this process is the Rice parameter cRiceParam. Due to the AbsLevel[ x ][ y ] array for the transform block with component index cldx and upper left luma location (xO, yO ), the locSumAbs variable is derived as specified by the following pseudocode: ShiftRice = (BitDepth > 10) ? Floor(Log2(4 *(Bitdepth - 10))): 0 OffsetRice = ( BitDepth > 10 ) ? ( ShiftRice > 0 ) ? (1«(ShiftRice -1)) :0:0 locSumAbs = 0 if( xC < (1 « log2TbWidth) - 1 ) { locSumAbs += AbsLevel[ xC +1 ][ yC ] if( xC < (1 « log2TbWidth) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if(; yC < (1 « log2TbHeight) - 1) ncnn in / pznz / B / Yi locSumAbs += AbsLevel[ xC+1][yC+1]}; ¡f(yC < (1«log2TbHeight)-1) { locSumAbs+=AbsLevelIJxC][yC+1] if(yC <(1«log2TbHeight)-2) locSumAbs+=AbsLevel[xC][yC+2]}; locSumAbs = Clip3( 0.31,(( locSumAbs + RiceOffice)» ShiftRice) - baseLevel*5) Due to the locSumAbs variable, the Rice parameter cRiceParam is derived as specified in Table 1B. cRiceParam = cRiceParam + ShiftRice When baseLevel is equal to 0, the variable ZeroPos[ n ] is derived as follows: ZeroPos [ n ] = ( QState < 2 ? 1 : 2 ) « cRiceParam According to another aspect of the description, it is proposed to add the restriction that the value of these coding tool indicators provides the same general restriction controls as the others in the general restriction information. For example, `sps_ts_residual_coding_rice_present_in_sh_flag` equal to 1 specifies that `sh_ts_residual_coding_ricejdx` could be present in SH syntax structures referencing SPS. `sps_ts_residual_coding_rice_present_in_sh_flag` equal to 0 specifies that `sh_ts_residual_coding_ricejdx` is not present in SH syntax structures referencing SPS. In accordance with this disclosure, it is proposed to add the syntax element `gci_no_ts_residual_coding_rice_constraint_flag` to the general constraint information syntax to provide the same general constraint controls as the other flags. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added portions are highlighted in italics. general_constraint_info() { Descriptor gci_no_ts_residual_coding_rice_constraint_flag u(1)} gci no ts residual coding rice constraint flag equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag will be equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 0 does not impose such a constraint. In another example, `pps_ts_residual_coding_rice_flag` equal to 1 specifies that `pps_ts_residual_coding_rice_index` might be present in the current image. `pps_ts_residual_coding_rice_flag` equal to 0 specifies that `pps_ts_residual_coding_rice_index` is not present in the current image. In accordance with this disclosure, it is proposed to add the syntax element `gci_no_ts_residual_coding_rice_constraint_flag` to the general constraint information syntax to provide the same general constraint controls as other flags. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added portions are highlighted in italics. ncnn i Π / Ρ7Π7 / Β / ΥΙ general_constraint_info() { Descriptor gci_no_ts_residual_coding_rice_constraint_flag u(1)} gci_no_ts_residual_coding_rice_constraint_flag equal to 1 specifies that pps_ts_residual_coding_rice_flag will be equal to gci_ _no_ _ts_ residual_coding_rice_ _constraint_ flag equal to 0 does not impose such a restriction. 0. In yet another example, sps_rice_adaptation_enabled_flag equal to 1 indicates that the Rice parameter for binarization of abs_remainder[ ] and dec_abs_level can be derived by means of a formula. The formula may include RiceParam = RiceParam + shiftVal and shiftVal = (localSumAbs < Tx[ 0 ] ) ? Rx[ 0 ] : ((localSumAbs < Tx[ 1 ]) ? Rx[ 1 ] : ((localSumAbs < Tx[ 2 ]) ? Rx[ 2 ] : ((localSumAbs < Tx[ 3 ]) ? Rx[ 3 ] : Rx[4]))), where the lists Tx[ ] and Rx[ ] are specified as follows: Tx[ ] = { 32, 128, 512, 2048}> >(1523) Rx[ ] = { 0, 2, 4, 6, 8} According to the description, the proposed solution is to add the syntax element, `gci_no_rice_adaptation_constraint_flag`, to the general constraint information syntax to provide the same general constraint controls as other indicators. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added sections are highlighted in italics. general_constraintjnfo() { Descriptor gci_no_rice_adaptation_constraint_flag} gci_no_rice_adaptation_constraint_flag equal to sps_rice_adaptation_enabled_flag will be equal to 0. a 1 specifies that gci_no_rice_adaptation_constraint_flag equal to 0 does not impose this restriction. Because the proposed rice parameter adaptation scheme is used only for transform skip residual coding (TSRC), the proposed method can only be effective when TSRC is enabled. Accordingly, in one or more of the described modes, it is proposed to add a bitstream constraint that requires the value of gci_no_rice_adaptation_constraint_flag to be one when transform skip mode is disabled from the general constraint information level, for example, when the value of gci_no_transform_skip_constraint_flag is set to one. In yet another example, `sps_range_extension_flag` equal to 1 specifies that the syntax structure `sps_range_extension()` is present in the SPS RBSP syntax structure. `sps_range_extension_flag` equal to 0 specifies that this syntax structure is not present. Based on this description, it is proposed to add the syntax element `gc_no_range_extension_constraint_flag` to the general constraint information syntax to provide the same general constraint controls as other indicators. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added sections are highlighted in italics. general_constraint_info() { Descriptor gci_no_range_extension_constraint_flag u(1)} gci_no_range_extension_constraint_flag equal to 1 specifies that sps_range_extension_flag will be equal to 0. gci_no_range_extension_constraint_flag equal to 0 does not impose such a restriction. Figure 9 shows a method for video encoding according to an example in this disclosure. The method can be, for example, applied to a decoder. In Step 1902, the decoder can receive a Sequence Parameter Set (SPS) range extension flag indicating whether a syntax structure, sps_range_extension, is present in the Head Portion (SH) Raw Byte Sequence Payload (RBPS) syntax structures at a value of the SPS range extension flag. In Step 1904, in response to determining that the value of the SPS range extension indicator is equal to 1, the decoder can determine that sps_range_estension is present in the SH RBSP syntax structures. In Step 1906, in response to determining that the range extension indicator value is equal to 0, the decoder can determine that sps_range_extension is not present in the SH RBSP syntax structures. In yet another example, sps_cabac_bypass_alignment_enabled_flag equal to 1 specifies that the value of ivICurrRange can be aligned before deriving the decoding of the syntax elements sb_coded_flag[][], abs_remainder[], dec_abs_level[n], and coeff_sign_flag[]. sps_cabac_bypass_alignment_enabled_flag equal to 0 specifies that the value of ivICurrRange is not aligned before deriving the decoding. Based on this description, it is proposed to add the syntax element gci_no_cabac_bypass_alignment_constraint_flag to the general constraint information syntax to provide the same general constraint controls as other indicators. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added parts are highlighted in italics. general_constraint_info() { Descriptor gci_no_cabac_bypass_alignment_constraint_flag} gci_no_cabac_bypass_alignment_constraint_flag equal to 1 specifies that sps_cabac_bypass_alignment_enabled_flag will be equal to 0. gci_no_cabac_bypass_alignment_constraint_flag equal to 0 does not impose such a restriction. Figure 10 shows a method for video encoding according to an example in this description. The method can be applied, for example, to a decoder. In Step 2002, the decoder can receive an alignment-enabled indicator from the Sequence Parameter Set (SPS) indicating whether an index, ivICurrRange, is aligned before decoding the syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flagn based on a value of the enabled SPS alignment. In step 2004, in response to determining that the value of the SPS alignment-enabled indicator is equal to 1, the decoder can determine that ivICurrRange is aligned before proceeding to decoding. In step 2006, in response to determining that the value of the SPS alignment-enabled indicator is equal to 0, the decoder may determine that ivICurrRange is not aligned before proceeding to decoding. In yet another example, `extended_precision_processing_flag` equal to 1 specifies that extended dynamic range can be used for transform coefficients and transform processing. `extended_precision_processing_flag` equal to 0 specifies that extended dynamic range is not used. Based on the description, it is proposed to add the syntax element `gci_no_extended_precision_processing_constraint_flag` to the general constraint information syntax to provide the same general constraint controls as other indicators. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added parts are highlighted in italics. general_constraint_info() { Descriptor gci_no_extended_precision_processing_constraint_flag} ncnn ι n / cznz / B / Yi gci_no_extended_precision_processing_constraint_flag equal to 1 specifies that extended_precision_processing_flag will be equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 0 does not impose this restriction. Figure 11 shows a method for video encoding according to an example from the present description. The method can be applied, for example, to a decoder. In step 2102, the decoder can receive an extended precision processing indicator that indicates whether an extended dynamic range is adopted for transform coefficients and during transform processing based on a value of the extended precision processing indicator. In step 2104, in response to determining that the value of the extended precision processing indicator equals 1, the decoder can determine that the extended dynamic range is adopted for the transform coefficients and during transform processing. In step 2106, in response to determining that the value of the extended precision processing indicator is 0, the decoder can determine that the extended dynamic range is not adopted for the transform coefficients or during transform processing. In yet another example, persistent_rice_adaptation_enabled_flag equal to 1 specifies that the derivation of the Rice parameter for the binarization of abs_remainder[ ] and dec_abs_level can be initialized at the beginning of each sub-block using accumulated mode-dependent statistics from previous sub-blocks. persistent_rice_adaptation_enabled_flag equal to 0 specifies that no previous sub-block state is used in the derivation of the Rice parameter. According to the disclosure, it is proposed to add the syntax element gci_no_persistent_rice_adaptation_constraint_flag to the general constraint information syntax to provide the same general constraint controls as other flags. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added parts are highlighted in italics. general_constralnt_lnfo() { Descriptor gci_no_persistent_rice_adaptation_constraint_flag} ncnn in / cznz / B / Yi gci_no_persistent_rice_adaptation_constraint_flag equal to 1 specifies that persistent_rice_adaptation_enabled_flag will be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to O does not impose such a restriction. Figure 12 shows a method for video encoding according to an example in this description. The method can be applied, for example, to a decoder. In step 2202, the decoder can receive a persistent rice adaptation enable flag indicating whether a rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each sub-block, adopting cumulative adoption-mode-dependent statistics from previous sub-blocks based on a value of the persistent rice adaptation enable flag. In step 2204, in response to determining that the value of the indicator enabled by persistent rice adaptation equals 1, the decoder can determine that the derivation of the rice parameter for binarization is initialized at the beginning of each sub-block that adopts cumulative mode-dependent statistics from previous sub-blocks. In step 2206, in response to determining that the value of the indicator enabled by persistent rice adaptation is 0, the decoder can determine that no previous sub-block state was adopted in the derivation of the rice parameter. In yet another example, `sps_rrc_rice_extension_flag` equal to 1 specifies that an extension of Rice parameter derivation for the binarization of `abs_remainder[]` and `dec_abs_level[]` is enabled. `sps_rrc_rice_extension_flag` equal to 0 specifies that the extension of Rice parameter derivation for the binarization of `abs_remainder[]` and `dec_abs_level[]` is disabled. According to the description, it is proposed to add the syntax element `gci_no_rrc_rice_extension_flag` to the general constraint information syntax to provide the same general constraint controls as other flags. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added parts are illustrated in italics later. general_constraint_info() { Descriptor gci_no_rrc_rice_extension_flag} ncnfrLn / eznz / e / Yi gci_no_rrc_rice_extension_flag equal to 1 specifies that sps_rrc_rice_extension_flag will be equal to 0. gci_no_rrc_rice_extension_flag equal to 0 imposes no restriction Figure 17 shows a method for video decoding according to an example in this disclosure. The method can be applied, for example, to a decoder. In step 2702, the decoder can receive a rice SPS extension flag indicating whether an extension of the rice parameter derivation for binarization of abs_remainder and dec_abs_level is enabled. In step 2704, in response to determining that a value of the rice SPS extension indicator equals 1, the decoder can determine that the rice parameter derivation extension for binarization is enabled. In step 2706, in response to determining that the value of the rice SPS extension indicator equals 0, the decoder can determine that the derivation extension of the rice parameter for binarization is disabled. In yet another example, `sps_persistent_rice_adaptation_enabled_flag` equal to 1 specifies that the derivation of the Rice parameter for the binarization of `abs_remainder[]` and `dec_abs_level[]` is initialized at the start of each TU using accumulated statistics from previous TUs. `sps_persistent_rice_adaptation_enabled_flag` equal to 0 specifies that no previous TU state was used in the derivation of the Rice parameter. Based on the description, it is proposed to add the syntax element `gci_no_persistent_rice_adaptation_enabled_flag` to the general constraint information syntax to provide the same general constraint controls as other indicators. An example of the decoding process in the VVC Project is illustrated later. Changes to the VVC Project are highlighted. Added parts are illustrated in italics later. general_constraint_info() { Descriptor gci_no_persistent_ríce_adaptation_enabled_flag u(1)} gci_no_persistent_rice_adaptation_enabled_flag equal to 1 specifies that sps_persistent_rice_adaptation_enabled_flag will be equal to 0. gci_no_persistent_rice_adaptation_enabled_flag equal to 0 does not impose this restriction Figure 18 shows a method for video decoding according to an example in this description. The method can be applied, for example, to a decoder. In step 2802, the decoder can receive an indicator enabled by the rice SPS adaptation, indicating whether the rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each transform unit with cumulative statistics from previous TUs. In step 2804, in response to determining that a value of the rice adaptation-enabled indicator SPS equals 1, the decoder can determine that the derivation of the rice parameter for binarization is initialized at the beginning of each TU with the accumulated statistics from previous TUs. In step 2806, in response to determining that the enabled indicator value of rice adaptation SPS equals 0, the decoder can determine that no previous TU state was adopted in the derivation of the rice parameter. The methods described above can be implemented using a device that includes one or more circuit assemblies, which may include application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components. The device may use the circuit assemblies in combination with the other hardware or software components to perform the methods described above. Each module, submodule, unit, or subunit described above may be implemented at least partially using one or more of the circuit assemblies. Rice parameter decision On the encoder side, TSRC coding may require multiple encoding passes to derive the optimal Rice parameter. This multi-pass coding may not be suitable for practical hardware encoder designs. To address this issue, a low-delay TSRD coding method is also proposed. According to the thirtieth aspect of the description, the Rice parameter is derived based on certain encoded information from the current portion, such as the quantization parameter and / or encoding bit depth associated with the portion / image / sequence, and / or a hash relation associated with the portion / image / sequence level. Different methods can be used to derive the Rice parameter, with some exemplary methods listed below. Note that the following methods can be applied independently or in combination. 1. The Rice parameter mentioned in the above modalities may be additionally dependent on the video resolution, including both temporal resolution (e.g., frame rate) and spatial resolution (e.g., image width and height) of the video. 2. The Rice parameter can vary at the sequence level, image level, slice level, and / or any predefined region. In one specific example, different Rice values ​​are used for images with different temporal layer IDs (which are related to the `nuh_temporal_id_plus1` specified in the VVC specification). Alternatively, the Rice parameter can include a value determined by the QP values ​​used at the sequence level, image level, slice level, and / or any predefined region. For example, `rice parameter = Clip3(1, 8, (TH - QP) / 6)`, where TH is a predefined threshold (e.g., 18, 19). 3. The Rice parameter can be set to a default value, for example, 1, according to the change in encoded information between the current and previous portions. In one specific example, the default Rice value is used for images when their temporal layer ID changes compared to the previous image. Alternatively, the default Rice value is used for images when AQ is larger than TH, where AQ is calculated as abs(QPcurrent QPprevious) and TH is a predefined threshold. The Rice parameter (for example, 0, 5). For example, the Rice parameter = 1 when the Intra Block Copy mode hash ratio in the current portion is larger than TH, where TH is a predefined threshold, for example, Max(4r(number of CTUs), 4200). 4. The Rice parameter for each portion is determined based on the abs_remainder values ​​encoded in the preceding portion, according to the encoding order. Specifically, after a portion is encoded, the number of bins for binarizing abs_remainder using different Rice parameters is computed. These bins are then used to determine the Rice parameter for the next portion. For example, the Rice parameter that achieves the minimum number of bins in the preceding portion will be selected for the current portion.For another example, if the current portion and its preceding portion use the same QP, the Rice parameter which achieves the minimum number of bins in the preceding portion will be selected for the current portion; otherwise, the number of bins generated using the default Rice parameter (i.e., 1) in the preceding portion is scaled by TH before being compared to other Rice parameters, and the Rice parameter which leads to the minimum number of bins will be selected for the current portion, where PH is a predefined threshold, e.g., 0.9. 5. The Rice parameter for each portion is determined based on the abs_remainder values ​​encoded in the preceding portion according to the encoding order. The Rice parameter can be adjusted based on changes in the encoded information between the current and previous portions. In a specific example, the Rice parameter that achieves the minimum number of bins in the preceding portion will be selected for the current portion. The Rice value can be adjusted when AQ is greater than TH, where AQ is calculated as abs(QPcurrent-QPprevious) and TH is a predefined threshold. The Rice parameter (e.g., 0.5) can be adjusted by adding a predefined deviation (e.g., +1, -1) or by scaling it using a predefined value. Figure 16 shows a flowchart of a low-delay transform hop residual (TSRC) coding method according to an example in this disclosure. The method can be, for example, applied to an encoder. In step 2602, the encoder can derive a rice parameter based on encoded information from a current portion of a video. The encoded information can include one or more of the following parameters: a quantization parameter or a coding bit depth associated with a portion, image, or video sequence in step 2604; or a hash relation associated with the portion, image, or video sequence in step 2606. It is noticeable that the methods of the previous encoder can be applied on the decoder side. In one specific example, the Rice parameter does not need to be signaled to the decoder, and the encoder / decoder uses the same method to derive the Rice parameter. Figure 8 shows an 1810 computing environment coupled with an 1860 user interface. The 1810 computing environment can be part of a data processing server. The 1810 computing environment includes an 1820 processor, 1840 memory, and an 1850 I / O interface. The 1820 processor typically controls the overall positions of the 1810 computing environment, such as operations associated with display, data acquisition, data communications, and image processing. The 1820 processor may include one or more processors to execute instructions to perform all or some of the steps in the methods described above. In addition, the 1820 processor may include one or more modules that facilitate interaction between the 1820 processor and other components. The processor may be a Central Processing Unit (CPU), a microprocessor, a single-chip machine, a GPU, or similar. The 1840 memory is configured to store various types of data to support the operation of the 1810 computing environment. The 1840 memory may include predefined 1842 software. Examples of such data include instructions for any applications or methods operated in the 1810 computing environment, video data sets, image data, and so on. The 1840 memory can be implemented using any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, and optical or magnetic disks. The 1850 I / O interface provides an interface between the 1820 processor and peripheral interface modules, such as a keyboard, a click wheel, dots, and the like. Dots may include, but are not limited to, a main dot, a start scan dot, and a stop scan dot. The 1850 I / O interface can be coupled with an encoder and decoder. In some embodiments, a non-transient computer-readable storage medium comprising a plurality of programs, such as those contained in memory 1840, executable by the processor 1820 in the computing environment 1810, is also provided to carry out the methods described above. For example, the non-transient computer-readable storage medium may be a ROM, RAM, or CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, or the like. The non-transient computer-readable storage medium has stored in it a plurality of programs for execution by means of a computing device having one or more processors, where the plurality of programs when executed by one or more processors, causes the computing device to perform the described arrida method for motion prediction. In some configurations, the 1810 computing environment can be implemented with one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gates (FPGAs), graphics processing units (GPUs), controllers, microcontrollers, microprocessors, or other electronic components, to carry out the above methods. Figure 13 is a block diagram illustrating an exemplary system 10 for encoding and decoding video blocks in parallel according to some implementations of this disclosure. As shown in Figure 13, the system 10 includes a source device 12 that generates and encodes video data to be subsequently decoded by a destination device 14. The source device 12 and the destination device 14 may comprise any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or the like. In some implementations, the source device 12 and the destination device 14 are equipped with wireless communication capabilities. In some implementations, the destination device 14 may receive encoded video data that will be decoded via a link 16. Link 16 may comprise any communication medium or device capable of moving the encoded video data from the source device 12 to the destination device 14. In one example, link 16 may comprise a communication medium that allows the source device 12 to transmit the encoded video data directly to the destination device 14 in real time. The encoded video data may be modulated according to a standard communication protocol, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines.The communication medium may be part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful in facilitating communication from the source device 12 to the destination device 14. In some other implementations, the encoded video data can be transmitted from an output interface 22 to a storage device 32. Subsequently, the encoded video data on the storage device 32 can be accessed by the destination device 14 through an input interface 28. The storage device 32 can include any of a variety of locally accessible data storage media such as a hard disk, Blu-ray discs, Digital Versatile Discs (DVDs), Compact Disc Read-Only Memories (CD-ROMs), flash memory, volatile or non-volatile memory, or any other digital storage medium suitable for storing the encoded video data.In a further example, storage device 32 could be a file server or other intermediate storage device capable of holding the encoded video data generated by source device 12. Destination device 14 can access the video data stored on storage device 32 by streaming or downloading. The file server could be any type of computer capable of storing the encoded video data and streaming it to destination device 14. Examples of file servers include a network server (for example, for a network site), a File Transfer Protocol (FTP) server, Network Attached Storage (NAS) devices, or a local disk drive.The destination device 14 can access the encoded video data through any standard data connection, including a wireless channel (e.g., a Wireless Fidelity (Wi-Fi) connection), a wired connection (e.g., Digital Subscriber Line (DSL), cable modem, etc.), or a combination of both suitable for accessing the encoded video data stored on a file server. The transmission of the encoded video data from the storage device 32 can be a live stream, a download stream, or a combination of both. As shown in Figure 13, the source device 12 includes a video source 18, a video encoder 20, and an output interface 22. The video source 18 may include a source such as a video capture device, for example, a video camera, a video file containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as the source video, or a combination of such sources. For example, if the video source 18 is a video camera from a security surveillance system, the source device 12 and the destination device 14 could be camera phones or video phones. However, the implementations described in this application may be applicable to video encoding in general and may be applied to wired and / or tethered applications. Computer-generated, pre-captured, or captured video can be encoded by the video encoder 20. The encoded video data can be transmitted directly to the destination device 14 via an output interface 22 of the source device 12. The encoded video data can also (or alternatively) be stored on the storage device 32 for later access by the destination device 14 or other devices for decoding and / or playback. The output interface 22 may also include a modem and / or a transmitter. The destination device 14 includes an input interface 28, a video decoder 30, and a display device 34. The input interface 28 may include a receiver and / or a modem and receive the encoded video data over link 16. The encoded video data communicated over link 16, or provided on the storage device 32, may include a variety of syntax elements generated by the video encoder 20 for use by the video decoder 30 in decoding the video data. Such syntax elements may be included within the encoded video data transmitted over a communication medium, stored on a storage medium, or stored on a file server. In some implementations, the target device 14 may include the display device 34, which may be an integrated display device and an external display device that is configured to communicate with the target device 14. The display device 34 displays the decoded video data to a user, and may comprise any of a variety of display devices such as a Liquid Crystal Display (LCD), a plasma display, an Organic Light Emitting Diode (OLED) display, or another type of display device. The video decoder 20 and video decoder 30 can operate in accordance with industry or proprietary standards, such as VVC, HEVC, MPEG-4 Part 10, AVC, or extensions of such standards. It is understood that this application is not limited to a specific video encoding / decoding standard and may apply to other video encoding / decoding standards. It is generally envisaged that the video encoder 20 of the source device 12 can be configured to encode video data in accordance with any of these current or future standards. Similarly, it is also generally envisaged that the video decoder 30 of the destination device 14 can be configured to decode video data in accordance with any of these current or future standards. The video encoder 20 and video decoder 30 may each be implemented as any of a variety of convenient encoder and / or decoder circuit assemblies, such as one or more microprocessors, Digital Signal Processors (DSPs), Application-Specific Integrated Circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When partially implemented in software, an electronic device may store instructions for the software on a suitable, non-transient, computer-readable medium and execute the instructions in hardware using one or more processors to perform the video encoding / decoding operations described herein.Each of the video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, each of which may be integrated as part of a combined encoder / decoder (CODEC) in a respective device. Figure 14 is a block diagram illustrating an exemplary video encoder 20 according to some implementations described herein. The video encoder 20 can perform intra- and inter-predictive encoding of video blocks within video frames. Intra-predictive encoding relies on spatial prediction to reduce or eliminate spatial redundancy in video data within a predetermined video frame or image. Inter-predictive encoding relies on temporal prediction to reduce or eliminate temporal redundancy in video data within adjacent video frames or images of a video sequence. It should be noted that the term “frame” can be used synonymously with the term “image” or “picture” in the field of video encoding. As shown in FIG. 14, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a Decoded Image Buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 4f further includes a motion estimation unit 42, a motion compensation unit 44, a partitioning unit 45, an intra-prediction processing unit 46, and an intra-block copy (BC) unit 48. In some implementations, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction.A loop filter 63, such as an unblocking filter, may be located between the adder 62 and DPB 64 for filter block boundaries to eliminate reconstructed video blocking artifacts. Another loop filter, such as a Sample Adaptive Deviation (SAO) filter and / or Adaptive Loop Filter (ALF), may also be used in addition to the unblocking filter to filter the output of the adder 62. In some examples, the loop filters may be omitted, and the decoded video block may be provided directly by the adder 62 to DPB 64. The video encoder 20 may take the form of a programmable or fixed hardware unit or may be divided among one or more programmable or fixed hardware units (illustrated). Video data memory 40 can store video data to be encoded by the components of video encoder 20. The video data in video data memory 40 can be obtained, for example, from video source 18, as shown in Figure 13. DPB 64 is a buffer that stores reference video data (e.g., reference frames or images) for use in video data encoding by video encoder 20 (e.g., in intra- or inter-predictive encoding modes). Video data memory 40 and DPB 64 can be formed by any of a variety of memory devices. In several examples, video data memory 40 may be on-chip with other components of video encoder 20, or off-chip relative to those components. As shown in FIG. 14, after receiving the video data, the partitioning unit 45 within the prediction processing unit 41 partitions the video data into video blocks. This partitioning can also include partitioning a video frame into portions, tiles (e.g., sets of video blocks), or other larger Coding Units (CUs) according to predefined separation structures such as a Quaternary Tree (QT) structure associated with the video data. The video frame is, or can be considered as, a two-dimensional gate or array of samples with sample values. A sample in the gate can also be referred to as a pixel or a pei. A number of samples in the horizontal and vertical directions (or axes) of the gate or image define a size and / or resolution of the video frame. The video frame can be divided into multiple video blocks by, for example, using QT partitioning.The video block is again, or can be considered, as a two-dimensional gate or sample array with sample values, albeit smaller than the video frame. A number of samples in the horizontal and vertical directions (or axes) of the video block defines its size. The video block can further be partitioned into one or more block partitions or sub-blocks (which can then form blocks), for example, by iteratively using QT partitioning, Binary Tree (BT) partitioning, or Triple Tree (TT) partitioning, or any combination thereof. It should be noted that the term “block” or “video block” as used herein can refer to a portion, particularly a rectangular (square or non-square) portion, of a frame or image.With reference, for example, to HEVC and VVC, the video block or block may be or correspond to a Coding Tree Unit (CTU), a CU, a Prediction Unit (PU) or a Transform Unit (TU) and / or may be or correspond to a corresponding block, for example, a Coding Tree Block (CTB), Coding Block (CB), a Prediction Block (PB) or a Transform Block (TB) and / or a sub-block. The prediction processing unit 41 can select one of a plurality of possible predictive coding modes, such as one of a plurality of intra-predictive coding modes or one of a plurality of inter-predictive coding modes, for the current video block based on error results (e.g., coding rate and distortion level). The prediction processing unit 41 can provide the resulting intra- or inter-prediction coded block to adder 50 to generate a residual block and to adder 62 to reconstruct the coded block for use as part of a subsequent reference frame. The prediction processing unit 41 also provides syntax elements, such as motion vectors, intra-mode indicators, partitioning information, and other such syntax information, to the entropy coding unit 56. In order to select an appropriate intra-predictive coding mode for the current video block, the intra-predictive processing unit 46 within the prediction processing unit 41 can perform intra-predictive coding of the current video block relative to one or more adjacent blocks in the same frame in which the current block is coded, thus providing spatial prediction. The motion estimation unit 42 and the motion compensation unit 44 within the prediction processing unit 41 perform inter-predictive coding of the current video block relative to one or more predictive blocks in one or more reference frames, thus providing temporal prediction. The video encoder 20 can perform multiple coding passes, for example, selecting an appropriate coding mode for each block of video data. In some implementations, the motion estimation unit 42 determines the interprediction mode for a current video frame by generating a motion vector. This vector indicates the displacement of a video block within the current video frame relative to a predictive block within a reference video frame, according to a predetermined pattern within a sequence of video frames. Motion estimation, performed by motion estimation unit 42, is the process of generating motion vectors, which estimate the motion for video blocks. A motion vector, for example, can indicate the displacement of a video block within a current video frame or the relative position of a predictive block within a reference frame relative to a current block being encoded within the current frame. The predetermined pattern can designate video frames in the sequence as P-frames or B-frames.The intra BC 48 unit can determine vectors, for example, block vectors, for intra BC encoding in a manner similar to the determination of motion vectors by the motion estimation unit 42 for inter prediction, or it can use the motion estimation unit 42 to determine the block vector. A predictive block for the video block can be, or correspond to, a reference block or reference block of a reference frame considered to closely match the video block to be encoded in terms of pixel difference, which is determined by the Sum of Absolute Difference (SAD), Sum of Squared Difference (SSD), or other difference metrics. In some implementations, the video encoder 20 can compute values ​​for sub-integer pixel positions of reference frames stored in DPB 64. For example, the video encoder 20 can interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Therefore, the motion estimation unit 42 can perform a motion search relative to whole-pixel and fractional-pixel positions and output a pixel-accurate motion vector. ncnn ι n / cznz / B / Yi The motion estimation unit 42 calculates a motion vector for a video block in an inter-prediction encoded frame by comparing the position of the video block to the position of a predictive block in a reference frame selected from a first reference frame list (List 0) or a second reference frame list (List 1), each of which identifies one or more reference frames stored in DPB 64. The motion estimation unit 42 sends the calculated motion vector to the motion compensation unit 44 and then to the entropy encoding unit 56. Motion compensation, performed by motion compensation unit 44, may involve searching for or generating a predictive block based on the motion vector determined by motion estimation unit 42. After receiving the motion vector for the current video block, motion compensation unit 44 may locate a predictive block to which the motion vector points in one of the reference frame lists, retrieve the predictive block from DPB 64, and send the predictive block to adder 50. Adder 50 then forms a residual video block of pixel difference values ​​by subtracting pixel values ​​from the predictive block provided by motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel difference values ​​that form the residual video block may include luma or chroma difference components, or both.The motion compensation unit 44 can also generate syntax elements associated with the video blocks of a video frame for use by the video decoder 30 in decoding the video blocks of the video frame. Syntax elements may include, for example, syntax elements that define the motion vector used to identify the predictive block, any indicators that indicate the prediction mode, or any other syntax information described herein. Note that the motion estimation unit 42 and the motion compensation unit 44 can be highly integrated, but are illustrated separately for conceptual purposes. In some implementations, the intra-BC 48 unit can generate vectors and search for predictive blocks in a manner similar to that described above in relation to the motion estimation unit 42 and the motion compensation unit 44, but with the predictive blocks being in the same frame as the current block being encoded and with the vectors being referred to as block vectors opposite to the motion vectors. Specifically, the intra-BC 48 unit can determine an intra-prediction mode to use for encoding a current block. In some examples, the intra-BC 48 unit can encode a current block using several intra-prediction modes, for example, during separate encoding passes, and test its performance through rate distortion analysis.The BC 48 intra unit can then select, from among the various tested intraprediction modes, one to use and generate an intra-mode indicator accordingly. For example, the BC 48 intra unit can calculate velocity distortion values ​​using velocity distortion analysis for the various tested intraprediction modes and select the intraprediction mode with the best velocity distortion characteristics as the appropriate mode to use. Velocity distortion analysis typically determines the amount of distortion (or error) between a coded block and the original block, the uncoded block that was encoded to produce the coded block, and the bit rate (i.e., the number of bits) used to produce the coded block.The BC 48 intra unit can calculate distortion and velocity ratios for the various coded blocks to determine which intra-prediction mode shows the best velocity distortion value for the block. In other examples, the intra-BC unit 48 may use the motion estimation unit 42 and the motion compensation unit 44, in whole or in part, to perform these intra-BC prediction functions according to the implementations described here. In any case, for intra-block copying, a predictive block may be a block that is considered to closely match the block to be encoded, in terms of pixel difference, which is to be determined by SAD, SSD, or another difference metric, and identification of the predictive block may include calculating values ​​for sub-integer pixel positions. If the predictive block is from the same frame according to intra-prediction, or a different frame according to inter-prediction, the video encoder 20 can form a residual video block by subtracting pixel values ​​from the predictive block from the pixel values ​​of the video block currently being encoded, forming pixel difference values. The pixel difference values ​​that form the residual video block can include both luma and chroma component differences. The intra-prediction processing unit 46 can intra-predict a current video block, as an alternative to the inter-prediction performed by the motion estimation unit 42 and the motion compensation unit 44, or the intra-block copy prediction performed by the intra-BC unit 48, as described above. Specifically, the intra-prediction processing unit 46 can determine an intra-prediction mode to use for encoding a current block. To do this, the intra-prediction processing unit 46 can encode a current block using several intra-prediction modes, for example, during separate encoding passes, and the intra-prediction processing unit 46 (or a mode selection unit, in some examples) can select an appropriate intra-prediction mode to use from the tested intra-prediction modes.The intra-prediction processing unit 46 can provide indicative information of the intra-prediction mode selected for the block to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intra-prediction mode in the bit stream. After the prediction processing unit 41 determines the predictive block for the current video block by means of inter-prediction or intra-prediction, the adder 50 forms a residual video block by subtracting the predictive block from the current video block. The residual video data in the residual block can be included in one or more TUs and is provided to the transform processing unit 52. The transform processing unit 52 transforms the residual video data into residual transform coefficients using a transform, such as a Discrete Cosine Transform (DCT) or a conceptually similar transform. The transform processing unit 52 can send the resulting transform coefficients to the quantization unit 54. The quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process can also reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be modified by adjusting a quantization parameter. In some examples, the quantization unit 54 can then perform an array scan including the quantized transform coefficients. Alternatively, the entropy coding unit 56 can perform the scan. Following quantization, the entropy coding unit 56 entropy-encodes the quantized transform coefficients into a video bitstream using, for example, Context-Adaptive Variable Length Coding (CAVLC), Context-Adaptive Binary Arithmetic Coding (CABAC), Syntax-Based Context-Adaptive Binary Arithmetic Coding (SBAC), Probability Interval Partitioning (PIPE) Entropy Coding, or another entropy-coding methodology or technique. The encoded bitstream can then be transmitted to the video decoder 30 as shown in FIG. 13, or stored on the storage device 32 as shown in FIG. 13 for subsequent transmission or retrieval by the video decoder 30. The entropy coding unit 56 can also entropy-encode the motion vectors and other syntax elements for the current video frame being encoded. The inverse quantization unit 58 and the inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain to generate a reference block for predicting other video blocks. As noted above, the motion compensation unit 44 can generate a motion-compensated predictive block from one or more reference blocks of the frames stored in DPB 64. The motion compensation unit 44 can also apply one or more interpolation filters to the predictive block to calculate sub-integer pixel values ​​for use in motion estimation. Adder 62 adds the reconstructed residual block to the motion-compensated predictive block produced by the motion compensation unit 44 to produce a reference block for storage in DPB 64. The reference block can then be used for the intra BC unit 48, the motion estimation unit 42, and the motion compensation unit 44 as a predictive block to interpredict another video block in a subsequent video frame. Figure 15 is a block diagram illustrating an exemplary video decoder 30 according to some implementations of the present application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, a summing unit 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra-prediction unit 84, and an intra-BC unit 85. The video decoder 30 can perform a decoding process that is generally the reciprocal of the encoding process described above with respect to the video encoder 20 in connection with Figure 14.For example, the motion compensation unit 82 can generate prediction data based on motion vectors received from the entropy decoding unit 80, while the intra-prediction unit 84 can generate prediction data based on intra-prediction mode indicators received from the entropy decoding unit 80. In some examples, a single unit of the Video Decoder 30 may be tasked with implementing the requirements of this application. Also, in some examples, the implementations described herein may be distributed among one or more of the Video Decoder 30 units. For example, the intra unit BC 85 can perform the implementations of this application, alone, or in combination with other units of the video decoder 30, such as the motion compensation unit 82, the intra prediction unit 84, and the entropy decoding unit 80. In some examples, the video decoder 30 may not include the intra unit BC 85, and the functionality of the intra unit BC 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82. Video data memory 79 can store video data, such as an encoded video bitstream, to be decoded by the other components of video decoder 30. The video data stored in video data memory 79 can be obtained, for example, from storage device 32, from a local video source such as a camera, via wired or wireless network video data communication, or by accessing physical data storage media (for example, a flash drive or hard disk). Video data memory 79 may include a Coded Picture Buffer (CPB) that stores encoded video data from an encoded video bitstream. DPB 92 of video decoder 30 stores reference video data for use in decoding video data by video decoder 30 (for example, in intra- or inter-predictive coding modes).The video data memory 79 and DPB 92 can be comprised of any of a variety of memory devices, such as dynamic random-access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and DPB 92 are depicted as two distinct components of the video decoder 30 in Figure 15. However, it will be apparent to someone skilled in the art that the video data memory 79 and DPB 92 can be provided by the same memory device or by separate memory devices. In some examples, the video data memory 79 may be on-chip with other components of the video decoder 30, or off-chip relative to those components. During the decoding process, video decoder 30 receives a bitstream of the encoded video representing video blocks from an encoded video frame and associated syntax elements. Video decoder 30 can receive the syntax elements at the video frame level and / or the video block level. The entropy decoding unit 80 of video decoder 30 entropy-decodes the bitstream to generate quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. The entropy decoding unit 80 then sends the motion vectors or intra-prediction mode indicators and other syntax elements to the prediction processing unit 81. When the video frame is encoded as an intra-predictive encoded frame (I) or for intra-encoded predictive blocks in other frame types, the intra-prediction unit 84 of the prediction processing unit 81 can generate prediction data for a video block of the current video frame based on a signaled intra-prediction mode and reference data from previously decoded blocks of the current frame. When the video frame is encoded as an inter-predictive encoded frame (i.e., B or P), the motion compensation unit 82 of the prediction processing unit 81 produces one or more predictive blocks for a video block of the current video frame based on the motion vectors and other syntax elements received from the entropy decoding unit 80. Each of the predictive blocks can be produced from a reference frame within one of the reference frame lists. The video decoder 30 can construct the reference frame lists, List 0 and List 1, using default construction techniques based on reference frames stored in DPB 92. In some examples, when the video block is encoded according to the intra BC mode described herein, the intra BC unit 85 of the prediction processing unit 81 produces predictive blocks for the current video block based on block vectors and other syntax elements received from the entropy decoding unit 80. The predictive blocks may be within a reconstructed region of the same image as the current video block defined by the video encoder 20. The motion compensation unit 82 and / or the intra BC unit 85 determines prediction information for a video block of the current video frame by analyzing motion vectors and other syntax elements, and then uses the prediction information to produce the predictive blocks of the current video block being decoded.For example, the motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra- or inter-prediction) used to encode video blocks of the video frame, an inter-prediction frame type (e.g., B or P), construction information for one or more of the reference frame lists for the frame, motion vectors for each inter-predictive encoded video block of the frame, inter-prediction status for each inter-predictive encoded video block, and other information to decode the video blocks in the current video frame. Similarly, the intra BC 85 unit can use some of the received syntax elements, for example, a flag, to determine that the current video block was predicted using intra BC mode, construction information of whose frame video blocks are within the reconstructed region and should be stored in DPB 92, the block vectors for each intra BC predicted video block of the frame, intra BC prediction status for each intra BC predicted video block of the frame, and other information to decode the video blocks in the current video frame. Motion compensation unit 82 can also perform interpolation using interpolation filters, as employed by video encoder 20 during the encoding of video blocks to calculate interpolated values ​​for sub-integer pixels of reference blocks. In this case, motion compensation unit 82 can determine the interpolation filters used by video encoder 20 from the received syntax elements and utilize those filters to produce predictive blocks. The inverse quantization unit 86 quantizes the quantized transform coefficients provided in the bitstream and entropy-decoded by the entropy-decoding unit 80 using the same quantization parameter calculated by the video encoder 20 for each video block in the video frame to determine a degree of quantization. The inverse transform processing unit 88 applies an inverse transform, for example, an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process, to the transform coefficients in order to reconstruct the remaining blocks in the pixel domain. After the motion compensation unit 82 or the intra-BC unit 85 generates the predictive block for the current video block based on the vectors and other syntax elements, the adder 90 reconstructs the decoded video block for the current video block by adding the residual block from the inverse transform processing unit 88 and a corresponding predictive block generated by the motion compensation unit 82 and the intra-BC unit 85. A loop filter 91, such as an unblocking filter, SAO filter, and / or ALF filter, may be located between the adder 90 and DPB 92 for further processing of the decoded video block. In some examples, the loop filter 91 may be omitted, and the decoded video block may be directly supplied by the adder 90 to the DPB 92.The video blocks decoded in a given frame are then stored in DPB 92, which stores reference frames used for subsequent motion compensation of upcoming video blocks. The DPB 92, or a separate memory device, can also store decoded video for later display on a display device, such as display device 34 in FIG. 13. The description in this disclosure is for illustrative purposes only and is not intended to be exhaustive or limited to the description provided herein. Many modifications, variations, and alternative implementations will be apparent to those skilled in the art who benefit from the teachings presented in the following descriptions and associated figures. The examples were chosen and described to explain the principles of the disclosure and to enable other practitioners to understand the disclosure for various implementations and to better utilize the underlying principles. Various implementations with different modifications are shown as they relate to the intended use. For example, it should be understood that the scope of the disclosure is not limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of this disclosure.

Claims

1. A method for video decoding, characterized in that it comprises: receiving, through a decoder, a rice extension flag from the Sequence Parameter Set (SPS) indicating whether a derivation extension of the rice parameter for binarization of abs_remainder and dec_abs_level is used, wherein abs remainder is encoded with the Golomb-Rice code and derivation-encoded bins in a second pass when the number of context-encoded bins remaining is greater than or equal to 4 while encoded in a first pass; and wherein dec_abs_level is directly encoded in the second pass using the Golomb-Rice code and derivation-encoded bins when the number of context-encoded bins remaining is less than 4 while encoded in the first pass.

2. The method for video decoding according to claim 1, further characterized in that it comprises: in response to determining that a value of a rice SPS extension indicator is equal to 1, determining, by means of the decoder, that the derivation extension of the rice parameter for binarization is enabled; and in response to determining that the value of the rice SPS extension indicator is equal to 0, determining, by means of the decoder, that the derivation extension of the rice parameter for binarization is disabled.

3. The method for video decoding according to claim 1, further characterized in that it comprises: receiving, by means of the decoder, a general restriction information (GCI) rice extension indicator, in GCI syntax to provide general control of the SPS rice extension indicator.

4. The method for video decoding according to claim 3, further characterized in that it comprises: in response to determining that a value of the rice GCI extension indicator is equal to 1, determining that a value of the rice SPS extension indicator is equal to 0.

5. A method for video decoding, characterized in that it comprises: receiving, by means of a decoder, an enabled rice adaptation indicator from the Sequence Parameter Set (SPS) indicating whether the rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each transform unit (TU) with cumulative statistics from previous TUs, wherein abs_remainder is encoded with the Golomb-Rice code and derivation-encoded bins in a second pass when the number of context-encoded bins remains greater than or equal to 4 while encoding in a first pass; and wherein dec_abs_level is directly encoded in the second pass using the Golomb-Rice code and derivation-encoded bins when the number of context-encoded bins remains less than 4 while encoding in the first pass.

6. The method for video decoding according to claim 5, further characterized in that it comprises: in response to determining that a value of the rice adaptation-enabled SPS indicator is equal to 1, determining, by means of the decoder, that the derivation of the rice parameter for binarization is initialized at the beginning of each TU with the accumulated statistics of previous TUs; and in response to determining that the value of the rice adaptation-enabled SPS indicator is equal to 0, determining, by means of the decoder, that no previous TU state was adopted in the derivation of the rice parameter.

7. The method for video decoding according to claim 5, further characterized in that it comprises: receiving, by means of the decoder, a General Restriction Information (GCI) rice adaptation enable indicator, in GCI syntax to provide overall control of the SPS rice adaptation enable indicator.

8. The method for video decoding according to claim 7, further characterized in that it comprises: in response to determining that a value of the GCI rice adaptation enabled indicator is equal to 1, determining that a value of the SPS rice adaptation enabled indicator is equal to 0.

9. A video decoding apparatus, characterized in that it comprises: one or more processors; and a memory coupled to one or more processors; wherein the one or more processors are configured to perform the method in any of claims 1 to 8 and store a bit stream to be decoded by means of the method in any of claims 1 to 8.

10. A non-transient computer-readable storage medium characterized in that it comprises the steps of the method in any of claims 1 to 8.

11. The non-transient computer-readable storage medium further characterized in that it stores a bit stream to be decoded by means of the method in any of claims 1 to 8.

Images