Residual and Coefficient Coding for Video Coding - Patent application

Abstract

A method, an apparatus, and a non-transitory computer-readable storage medium for video decoding are provided. In one method, a decoder determines an encoding bit depth of at least one sample in a bitstream, the decoder determines a value of a first sequence parameter set (SPS) flag for the at least one sample, and the decoder further determines a second SPS flag for the at least one sample based on the value of the first SPS flag in combination with the encoding bit depth of the at least one sample.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on and claims priority to Provisional Application No. 63 / 220,380, filed July 9, 2021, the entire contents of which are incorporated herein by reference for all purposes.

[0002] FIELD OF THE DISCLOSURE This disclosure relates to video encoding and compression, and more particularly to improving and simplifying residual and coefficient encoding for video encoding. [Background technology]

[0003] Various video coding techniques may be used to compress video data. Video coding is performed according to one or more video coding standards. For example, video coding standards may include versatile video coding (VVC), joint exploration test model (JEM), high-efficiency video coding (H.265 / HEVC), advanced video coding (H.264 / AVC), moving picture expert group (MPEG) coding, or the like. Video coding generally utilizes prediction methods (e.g., inter-prediction, intra-prediction, or the like) that exploit redundancy present in a video image or sequence. An important goal of video coding techniques is to compress video data into a format that uses a lower bit rate while avoiding or minimizing degradation of video quality. Summary of the Invention [Problem to be solved by the invention]

[0004] Examples of this disclosure provide methods and apparatus for video encoding. [Means for solving the problem]

[0005] According to the present disclosure, a method for video decoding is provided. The method may include determining, by a decoder, an encoding bit depth of at least one sample in a bitstream, determining, by the decoder, a value of a first SPS flag for the at least one sample, and determining, by the decoder, a second SPS flag for the at least one sample based on the value of the first SPS flag in combination with the encoding bit depth of the at least one sample.

[0006] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to be restrictive of the present disclosure.

[0007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate examples consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief description of the drawings]

[0008] [Figure 1] FIG. 2 is a block diagram of an encoder according to an example of the present disclosure. [Diagram 2] FIG. 2 is a block diagram of a decoder according to an example of the present disclosure. [Figure 3A] FIG. 13 is a diagram illustrating block partitions in a polymorphic tree structure according to an example of the present disclosure. [Figure 3B] FIG. 13 is a diagram illustrating block partitions in a polymorphic tree structure according to an example of the present disclosure. [Figure 3C] FIG. 13 is a diagram illustrating block partitions in a polymorphic tree structure according to an example of the present disclosure. [Figure 3D] FIG. 13 is a diagram illustrating block partitions in a polymorphic tree structure according to an example of the present disclosure. [Figure 3E] FIG. 13 is a diagram illustrating block partitions in a polymorphic tree structure according to an example of the present disclosure. [Figure 4]FIG. 2 is a diagram of a residual coding structure of a transform block according to an example of the present disclosure. [Diagram 5] FIG. 2 is a diagram of a residual coding structure for a transform skip block according to an example of the present disclosure. [Figure 6] FIG. 2 illustrates a method for encoding a video signal according to an example of the present disclosure. [Figure 7] FIG. 2 illustrates a method for encoding a video signal according to an example of the present disclosure. [Figure 8] FIG. 1 illustrates a computing environment coupled with a user interface according to an example of the present disclosure. [Figure 9] FIG. 2 illustrates a method for video encoding according to an example of the present disclosure. [Figure 10] FIG. 2 illustrates a method for video encoding according to an example of the present disclosure. [Figure 11] FIG. 2 illustrates a method for video encoding according to an example of the present disclosure. [Figure 12] FIG. 2 illustrates a method for video encoding according to an example of the present disclosure. [Figure 13] FIG. 1 is a block diagram illustrating an example system for encoding and decoding video blocks according to an example of this disclosure. [Figure 14] FIG. 2 is a block diagram illustrating an example video encoder according to one example of the present disclosure. [Figure 15] FIG. 2 is a block diagram illustrating an exemplary video decoder according to one example of the present disclosure. [Figure 16] FIG. 1 illustrates a low-delay transform skip residual coding (TSRC) method according to an example of the present disclosure. [Figure 17] FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. [Figure 18] FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. [Figure 19] FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. [Figure 20]FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. [Figure 21] FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. [Figure 22] FIG. 2 illustrates a method for video decoding according to an example of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings, in which the same numbers in different drawings represent the same or similar elements unless otherwise stated. The implementations described in the following description of the exemplary embodiments do not represent all implementations consistent with the present disclosure. Rather, the implementations are merely examples of apparatuses and methods consistent with aspects related to the present disclosure as described in the appended claims.

[0010] The terms used in this disclosure are for the purpose of describing particular embodiments only and are not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It is also to be understood that the term "and / or" as used herein is intended to mean and include any and all possible combinations of one or more of the associated listed items.

[0011] It should be understood that terms such as "first", "second", and "third" may be used herein to describe various information, but the information should not be limited by these terms. These terms are used only to distinguish one category of information from another. For example, the first information may be referred to as the second information, and similarly, the second information may be referred to as the first information, without departing from the scope of this disclosure. The term "if" as used herein may be understood to mean "when", "in the event of", or "at the discretion of", depending on the context.

[0012] Figure 1 shows a schematic diagram of a block-based video encoder for VVC. Specifically, Figure 1 shows an exemplary encoder 100. The encoder 100 has a video input 110, motion compensation 112, motion estimation 114, intra / inter mode decision 116, block predictor 140, adder 128, transform 130, quantization 132, prediction related information 142, intra prediction 118, picture buffer 120, inverse quantization 134, inverse transform 136, adder 126, memory 124, in-loop filter 122, entropy coding 138, and bitstream 144.

[0013] In encoder 100, a video frame is partitioned into multiple video blocks for processing. For a given video block, a prediction is formed based on either an inter-prediction or an intra-prediction technique.

[0014] A prediction residual, which represents the difference between a current video block that is part of the video input 110 and its predictor that is part of the block predictor 140, is sent from the adder 128 to a transform 130. The transform coefficients are then sent from the transform 130 to a quantizer 132 for entropy reduction. The quantized coefficients are then provided to an entropy encoder 138 to generate a compressed video bitstream. As shown in FIG. 1, prediction related information 142 from the intra / inter mode decision 116, such as video block partition information, motion vectors (MVs), reference picture indexes, and intra prediction modes, are also provided through the entropy encoder 138 and stored in the compressed bitstream 144. The compressed bitstream 144 comprises a video bitstream.

[0015] The encoder 100 also requires decoder-related circuitry to reconstruct pixels for prediction purposes. First, a prediction residual is reconstructed through inverse quantization 134 and inverse transform 136. This reconstructed prediction residual is combined with a block predictor 140 to generate unfiltered reconstructed pixels for the current video block.

[0016] Spatial prediction (or "intra prediction") predicts the current video block using pixels from samples (called reference samples) of already coded neighboring blocks in the same video frame as the current video block.

[0017] Temporal prediction (also called "inter prediction") uses reconstructed pixels from already coded video pictures to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in video signals. The temporal prediction signal for a given coding unit (CU) or coding block is typically signaled by one or more MVs that indicate the amount and direction of motion between the current CU and its temporal references. In addition, one reference picture index is additionally sent that is used to identify which reference picture in the reference picture storage the temporal prediction signal comes from.

[0018] Motion estimation 114 takes signals from video input 110 and picture buffer 120 and outputs a motion estimation signal to motion compensation 112. Motion compensation 112 takes signals from video input 110, picture buffer 120, and a motion estimation signal from motion estimation 114 and outputs a motion compensation signal to intra / inter mode decision 116.

[0019] After spatial prediction and / or temporal prediction are performed, an intra / inter mode decision 116 in the encoder 100 selects the best prediction mode, for example based on a rate-distortion optimization method. A block predictor 140 is then subtracted from the current video block, and the resulting prediction residual is decorrelated using a transform 130 and a quantization 132. The resulting quantized residual coefficients are inverse quantized by an inverse quantization 134 and inverse transformed by an inverse transform 136 to form a reconstructed residual, which is then added back to the prediction block to form a reconstructed signal for the CU. Further in-loop filtering 122, such as a deblocking filter, a sample adaptive offset (SAO), and / or an adaptive in-loop filter (ALF), may be applied to the reconstructed CU before it is placed into reference picture storage in a picture buffer 120 and used to encode future video blocks. To form the output video bitstream 144, the coding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit 138, which then further compresses and packs them to form the bitstream.

[0020] Figure 1 shows a block diagram of a typical block-based hybrid video coding system. The input video signal is processed block by block (called coding unit (CU)). In VTM-1.0, a CU may be up to 128x128 pixels. However, unlike HEVC, which partitions blocks based on quadtrees only, in VVC, one coding tree unit (CTU) is decomposed into CUs based on quadtrees / binarytrees / ternarytrees to accommodate different local characteristics. By definition, a coding tree block (CTB) is an NxN block of samples for some value of N, and as a result, the division of components into CTBs is a partitioning. A CTU contains a CTB of luma samples, two corresponding CTBs of chroma samples for a picture with three sample arrangements, or a CTB of samples for a monochrome picture or a picture coded using three separate color planes and the syntax structure used to code the samples. Furthermore, the concept of multiple partitioning unit types in HEVC is eliminated, i.e., in VVC, the separation of CU, prediction unit (PU), and transform unit (TU) no longer exists, instead, each CU is always used as the basic unit of both prediction and transformation without further partitioning. In the polymorphic tree structure, first, one CTU is partitioned by a quadtree structure. Then, each quadtree leaf node can be further partitioned by a binary tree structure and a ternary tree structure. As shown in Figure 3A, Figure 3B, Figure 3C, Figure 3D, and Figure 3E, there are five decomposition types: quad partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal tripartite partitioning, and vertical tripartite partitioning.

[0021] FIG. 3A shows a diagram illustrating block quadrants in a polymorphic tree structure in accordance with the present disclosure.

[0022] FIG. 3B shows a diagram illustrating block vertical bisections in a polymorphic tree structure in accordance with the present disclosure.

[0023] FIG. 3C shows a diagram illustrating block horizontal bisection in a polymorphic tree structure in accordance with the present disclosure.

[0024] FIG. 3D illustrates a diagram showing block vertical third divisions in a polymorphic tree structure in accordance with the present disclosure.

[0025] FIG. 3E illustrates a diagram showing horizontal third division of blocks in a polymorphic tree structure in accordance with the present disclosure.

[0026] In FIG. 1, spatial prediction and / or temporal prediction may be performed. Spatial prediction (or "intra prediction") predicts the current video block using pixels from samples (called reference samples) of already coded neighboring blocks in the same video picture / slice. Spatial prediction reduces spatial redundancy inherent in video signals. Temporal prediction (also called "inter prediction" or "motion compensated prediction") predicts the current video block using reconstructed pixels from already coded video pictures. Temporal prediction reduces temporal redundancy inherent in video signals. The temporal prediction signal for a given CU is typically signaled by one or more motion vectors (MVs) that indicate the amount and direction of motion between the current CU and its temporal references. Also, if multiple reference pictures are supported, one reference picture index is additionally sent that is used to identify which reference picture in the reference picture store the temporal prediction signal comes from. After spatial prediction and / or temporal prediction, a mode decision block in the encoder selects the best prediction mode, for example based on a rate-distortion optimization method. The predictive block is then subtracted from the current video block, and the predictive residual is decorrelated and quantized using a transform. The quantized residual coefficients are inverse quantized and inverse transformed to form a reconstructed residual, which is then added back to the predictive block to form a reconstructed signal for the CU. Further in-loop filtering, such as a deblocking filter, sample adaptive offset (SAO), and adaptive in-loop filter (ALF), may be applied to the reconstructed CU before it is put into a reference picture store and used to encode future video blocks. To form an output video bitstream, the coding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to an entropy coding unit, where they are further compressed and packed to form a bitstream.

[0027] Figure 2 shows a schematic block diagram of a video decoder for VVC. Specifically, Figure 2 shows a block diagram of an exemplary decoder 200. The decoder 200 includes a bitstream 210, an entropy decoding 212, an inverse quantization 214, an inverse transform 216, an adder 218, an intra / inter mode selection 220, an intra prediction 222, a memory 230, an in-loop filter 228, a motion compensation 224, a picture buffer 226, prediction related information 234, and a video output 232.

[0028] The decoder 200 is similar to the reconstruction-related section present in the encoder 100 of FIG. 1. In the decoder 200, the incoming input video bitstream 210 is first decoded through 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. The block predictor mechanism implemented in the intra / inter mode selector 220 is configured to perform either intra prediction 222 or motion compensation 224 based on the decoded prediction information. A set of unfiltered reconstructed pixels is obtained by summing the reconstructed prediction residual from the inverse transform 216 and the prediction output generated by the block predictor mechanism using an adder 218.

[0029] The reconstructed blocks may further pass through an in-loop filter 228 before being stored in a picture buffer 226, which acts as a reference picture store. The reconstructed video in the picture buffer 226 may be sent to drive a display device as well as used to predict future video blocks. In situations where the in-loop filter 228 is on, a filtering operation is performed on these reconstructed pixels to derive the final reconstructed video output 232.

[0030] FIG. 2 shows a schematic block diagram of a block-based video decoder. First, the video bitstream is entropy decoded in an entropy decoding unit. The coding mode and prediction information are sent to a spatial prediction unit (for intra-coding) or a temporal prediction unit (for inter-coding) to form a prediction block. The residual transform coefficients are sent to an inverse quantization unit and an inverse transform unit to reconstruct the residual block. The prediction block and the residual block are then added. The reconstructed block may go through further in-loop filtering before being stored in a reference picture store. The reconstructed video in the reference picture store is then sent to drive a display device and is used to predict future video blocks.

[0031] Transform Coefficient Coding in VVC Transform coefficient coding in VVC begins with setting the variable remBinsPass1 to the maximum number of context-coded bins (MCCB) allowed. In the coding process, the variable is decremented by one each time a context-coded bin is signaled. While remBinsPass1 is 4 or greater, coefficients are first signaled through the syntax sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag, which all use context-coded bins in the first pass. The remainder of the level information of the coefficients is coded using the syntax element abs_remainder, using Golomb-Rice codes and bypass-coded bins in the second pass. When remBinsPass1 becomes less than 4 while encoding the first pass, the current coefficient is not encoded in the first pass, but is directly encoded in the second pass using the syntax element of dec_abs_level, using Golomb-Rice code and bypass coding bins. The Rice parameter derivation process of dec_abs_level[] is derived as specified in Table 1A. After encoding all the levels described above, finally, the signs (sign_flag) of all scan positions where sig_coeff_flag is equal to 1 are encoded as bypass bins. Such a process is depicted in Figure 4. remBinsPass1 is reset every TB. The transition from using context coding bins for sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag to using bypass coding bins for the remaining coefficients occurs at most once per TB. For a coefficient sub-block, if remBinsPass1 is less than 4 before encoding the first coefficient, then the entire coefficient sub-block is encoded using the bypass coding bins.

[0032] FIG. 4 shows a diagram of the residual coding structure of a transform block. [Table 1] [Table 2]

[0033] Transform skip mode residual coding in VVC. In transform skip mode, the statistical properties of the residual signal differ from those of the transform coefficients, and no energy compaction around low frequency components is observed. The residual coding is modified to take into account the different signal properties of the (spatial) transform skip residual.

[0034] FIG. 5 shows a diagram of the residual coding structure of a transform skip block.

[0035] General constraint information The GCI structure contains several types of constraint syntax elements, including flags for general bitstream restrictions, such as indicating that only intra-coding is used, that all layers are independently coded, or that the bitstream contains only one AU; fields that constrain the bit depth and chroma format of the coded picture; flags that indicate that certain NAL unit types cannot be present in the bitstream; flags that constrain how pictures may be partitioned into slices, tiles, and sub-pictures in the bitstream; flags that constrain the size of the CTU and the size and type of the partitioning tree; flags that restrict the use of certain intra-coding tools; flags that restrict the use of certain inter-coding tools; flags that constrain transform, quantization, and residual coding tools; and flags that constrain aspects of the in-loop filter.

[0036] The purpose of the GCI syntax structure is to allow easy discovery of configuration information regarding features required for decoding of a bitstream, as well as to allow signaling of interoperability points that impose restrictions beyond those specified in a Profile, Tier, and Level (PTL) at a finer granularity than that allowed by previous video coding standards. Similar to subprofiles, the GCI syntax structure may allow for defining interoperability for decoder implementations that do not support all features of a VVC profile but address the needs of a particular application. A decoder implementation may check the GCI syntax elements to see if a bitstream avoids the use of certain features in order to determine how to configure the decoding process and to identify whether a bitstream is decodable by the decoder. A decoder implementation that supports all features of a VVC profile may ignore the values ​​of the GCI syntax elements, thus allowing the decoder to decode any bitstream that conforms to the specified PTL.

[0037] Transform skip residual coding According to one or more examples of the present disclosure, it is proposed to use a variable set of binary codewords to code a specific syntax element, e.g., abs_remainder, in transform skip residual coding, and the selection result is determined according to specific coded information of the current block, e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile, and / or according to a new flag associated with TB / CB / slice / picture / sequence level, e.g., extended_precision_processing_flag. Various methods may be used to derive the variable set of binary codewords, and some exemplary methods are listed below.

[0038] First, to determine the sign word of abs_remainder, the same procedure as currently used in VVC is employed, but a fixed Rice parameter (e.g., 2, 3, 4, 5, 6, 7, or 8) is always selected. The fixed value may vary under different conditions according to specific encoded information of the current block, such as the quantization parameter associated with the TB / CB and / or slice / profile, frame type (e.g., I, P, or B), component ID (e.g., luminance or chrominance), color format (e.g., 420, 422, or 444), or encoded bit depth, and / or according to syntax elements associated with the TB / CB / slice / picture / sequence level, such as the rice_parameter_value. A specific example is the case where TH1 to TH4 are predetermined thresholds satisfying (TH1 < TH2 < TH3 < TH4), and K0 to K4 are predetermined Rice parameters. It is worth noting that the same logic can actually be implemented in different ways. For example, a specific equation or look-up table may also be used to derive the same Rice parameter from the BitDepth value of the current CU / sequence.

[0039] Second, it is fixed-length binarization.

[0040] Third, it is truncated Rice binarization.

[0041] Fourth, it is the truncated binary (TB) binarization process.

[0042] Fifth, it is the k-th exponential Golomb binarization process (EGk).

[0043] Sixth, it is limited k-th exponential Golomb binarization.

[0044] An example of the corresponding decoding process based on the VVC draft is shown below, with the changes to the VVC draft shown in bold italic font in Table 1, and the deleted content shown in italic font. It is worth noting that in practice the same logic can be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 3]

[0045] In another example, when a new flag, e.g., extended_precision_processing_flag, is equal to 1, it is proposed to use only one fixed value for the Rice parameter when encoding the abs_remainder syntax element. The corresponding decoding process based on the VVC draft is shown below, with the changes in bold italic font and the deleted content in italic font. The changes relative to the VVC draft are shown in Table 2 in bold italic font. [Table 4]

[0046] In yet another example, when a new flag, e.g., extended_precision_processing_flag, is equal to 1, the Rice parameter cRiceParam is fixed as n, where n is a positive number (e.g., 2, 3, 4, 5, 6, 7, or 8). The fixed value may be different in different conditions. An example of a corresponding decoding process based on the VVC draft is shown below, with the changes shown in bold italic font and the deleted content shown in italic font. The changes to the VVC draft are shown in bold italic font in Table 3. [Table 5]

[0047] In yet another example, when BitDepth is equal to or greater than a predetermined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), the Rice parameter cRiceParam is fixed to n, where n is a positive number, e.g., 4, 5, 6, 7, or 8. The fixed value may be different in different conditions. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), the changes are shown in bold italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold italic font in Table 4. [Table 6]

[0048] In yet another example, one control flag is signaled in the slice header to indicate whether signaling of Rice parameters for transform skip blocks is enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the Rice parameter of that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), no further syntax elements are signaled at lower levels to indicate the Rice parameters of transform skip slices, and the default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2), the changes are shown in bold italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold italic font in Table 5. It is worth noting that sh_ts_residual_coding_rice_index can be coded in various ways and / or can have a maximum value. For example, to encode / decode the same syntax element, one may also use u(n), an unsigned integer using n bits, or f(n), a fixed-pattern bit sequence using n bits, written left bit first (left to right).

[0049] Slice Header Syntax [Table 7]

[0050] sh_ts_residual_coding_rice_flag equal to 1 specifies that sh_ts_residual_coding_rice_index may be present in the current slice. sh_ts_residual_coding_rice_flag equal to 0 specifies that sh_ts_residual_coding_rice_index is not present in the current slice. When sh_ts_residual_coding_rice_flag is not present, the value of sh_ts_residual_coding_rice_flag is inferred to be equal to 0. sh_ts_residual_coding_rice_index specifies the rice parameter used in the residual_ts_coding() syntax construct. [Table 8]

[0051] In yet another example, one control flag is signaled in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether the signaling of the Rice parameter for the transform skip block is enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the Rice parameter of that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), no further syntax elements are signaled at lower levels to indicate the Rice parameter of the transform skip slice, and the default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold italics in Table 7, and the deleted content is shown in italics. It is worth noting that sh_ts_residual_coding_rice_idx can be coded in various ways and / or can have a maximum value. For example, to encode / decode the same syntax element, one may also use u(n), an unsigned integer using n bits, or f(n), a fixed-pattern bit sequence using n bits, written left bit first (left to right).

[0052] Sequence Parameter Set RBSP Syntax [Table 9]

[0053] sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx may be present in an SH syntax structure that references an SPS. sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 specifies that sh_ts_residual_coding_rice_idx is not present in an SH syntax structure that references an 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 equal to 0.

[0054] Slice Header Syntax [Table 10]

[0055] sh_ts_residual_coding_rice_idx specifies the Rice parameter used in the residual_ts_coding() syntax structure. [Table 11]

[0056] In one or more examples of the present disclosure, it is proposed to disable the presence of the Rice parameter for transform skip residual coding when transform skip is disabled. In one specific example, to achieve such a design objective, 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 flag sps_transform_skip_enabled_flag is equal to 0 (i.e., when transform skip is disabled in the current picture), sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be 0 instead of being signaled. When the flag sps_transform_skip_enabled_flag is equal to 1, sps_ts_residual_coding_rice_present_in_sh_flag is further signaled. Changes to the current VVC working draft are shown in italic font below. [Table 12]

[0057] In another specific example, to achieve such design objective, it is proposed to add a bitstream-compliant requirement related to sps_transform_skip_enabled_flag of sps_ts_residual_coding_rice_present_in_sh_flag. For example, it is a bitstream-compliant requirement that the value of sps_ts_residual_coding_rice_present_in_sh_flag is equal to 0 when sps_transform_skip_enabled_flag is equal to 0. Changes to the current VVC Working Draft are shown in italic font below.

[0058] Semantics of sequence parameter set range extensions sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx_minus1 may be present in the slice_header() syntax structure referencing the 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 the slice_header() syntax structure referencing the 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 equal to 0.

[0059] It is a bitstream compliance requirement that when sps_transform_skip_enabled_flag is equal to 0, the value of sps_ts_residual_coding_rice_present_in_sh_flag is equal to 0.

[0060] In yet another example, when the transform skip flag (sps_transform_skip_enabled_flag) is signaled as enabled, one control flag is further signaled in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether the signaling of the Rice parameter of the transform skip block is enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the Rice parameter of that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), no further syntax elements are signaled at lower levels to indicate the Rice parameter of the transform skip slice, and the default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in italic font.

[0061] [Table 13]

[0062] sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx may be present in the SH syntax structure that references the 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 the SH syntax structure that references the 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 equal to 0.

[0063] [Table 14]

[0064] sh_ts_residual_coding_rice_idx_minus1+1 specifies the Rice parameter used in the residual_ts_coding() syntax construct. 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.

[0065] 9.3.3.11 abs_remainder[] thresholding process The inputs to this process are the syntax element abs_remainder[n], the color component cIdx, the current sub-block index i, the luma position (x0,y0) specifying the top-left sample of the current luma transform block relative to the top-left luma sample of the picture, the current coefficient scan position (xC,yC), the binary logarithm of the transform block width, log2TbWidth, and a request for binarization of the binary logarithm of the transform block height, log2TbHeight.

[0066] The output of this process is a binarization of the syntax elements.

[0067] The variables lastAbsRemainder and lastRiceParam are derived as follows:

[0068] - If this process is called for the first time for the current subblock index i, then lastAbsRemainder and lastRiceParam are both set equal to 0.

[0069] - Otherwise (if this is not the first time this process is called for the current subblock index i), lastAbsRemainder and lastRiceParam are set equal to the values ​​of abs_remainder[n] and cRiceParam, respectively, derived during the last invocation of the binarization process for the syntax element abs_remainder[n] specified in this clause.

[0070] The rice parameter cRiceParam is derived as follows:

[0071] - if transform_skip_flag[x0][y0][cIdx] 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_minus1+1.

[0072] - Otherwise, the Rice parameter cRiceParam is derived by invoking the Rice parameter derivation process in abs_remainder[] as specified in section 9.3.3.2 with as input the variables baseLevel set equal to 4, the color component index cIdx, the luminance position (x0,y0), the current coefficient scan position (xC,yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight.

[0073] In yet another example, one syntax element is signaled for each transform skip slice to indicate the Rice parameter of that slice. An example of the corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold italic font in Table 10. It is worth noting that sh_ts_residual_coding_rice_idx can be coded in various ways and / or can have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits, written left bit first (left to right), may also be used to code / decode the same syntax element.

[0074] Slice Header Syntax [Table 15]

[0075] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx is not present, the value of sh_ts_residual_coding_rice_idx is inferred to be equal to 0. [Table 16]

[0076] In yet another example, one control flag is signaled in the picture parameter set range extension syntax to indicate whether signaling of Rice parameters for transform skip blocks is enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled to indicate the Rice parameters for that picture. When the control flag is signaled as disabled (e.g., set equal to "0"), no further syntax elements are signaled at lower levels to indicate Rice parameters for transform skip slices, and a default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold italic font in Table 12. It is worth noting that pps_ts_residual_coding_rice_idx can be coded in various ways and / or can have a maximum value. For example, to encode / decode the same syntax element, one may also use u(n), an unsigned integer using n bits, or f(n), a fixed-pattern bit sequence using n bits, written left bit first (left to right).

[0077] Picture Parameter Set Range Extension Syntax [Table 17]

[0078] pps_ts_residual_coding_rice_flag equal to 1 specifies that pps_ts_residual_coding_rice_index may be present in the current picture. pps_ts_residual_coding_rice_flag equal to 0 specifies that pps_ts_residual_coding_rice_idx is not present in the current picture. When pps_ts_residual_coding_rice_flag is not present, the value of pps_ts_residual_coding_rice_flag is inferred to be equal to 0.

[0079] pps_ts_residual_coding_rice_idx specifies the Rice parameter used in the residual_ts_coding() syntax structure. [Table 18]

[0080] In yet another example, it is proposed to use only variable Rice parameters for the coding of the syntax element abs_remainder. The value of the Rice parameter applied may be determined according to the specific coded information of the current block, such as block size, quantization parameter, bit depth, transform type, etc. In a particular embodiment, it is proposed to adjust the Rice parameter based on the coding bit depth and the quantization parameter applied to one CU. The corresponding decoding process based on the VVC draft is shown below, where the changes to the VVC draft are shown in bold italic font in Table 14, and the deleted content is shown in italic font. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 19] JPEG0007676649000020.jpg37166

[0081] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 33 or 34). The changes to the VVC draft are shown in bold italic font in Table 15, and the deleted content is italicized. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 20]

[0082] In yet another example, the corresponding decoding process based on the VVC draft is shown below: A and T.H. B is a given threshold (e.g., TH A =8,TH B = 33 or 34). The changes to the VVC draft are shown in bold italics in Table 16, with the deletions in italics. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 21]

[0083] In yet another example, it is proposed to use only the variable Rice parameter for encoding the syntax element of abs_remainder when a new flag, e.g., extended_precision_processing_flag, is equal to 1. The variable value may be determined according to the specific encoded information of the current block, e.g., block size, quantization parameter, bit depth, transform type, etc. In a particular embodiment, it is proposed to adjust the Rice parameter based on the encoding bit depth and the quantization parameter applied to one CU. The corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold italic font in Table 17. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 22]

[0084] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). The changes to the VVC draft are shown in bold italic font in Table 18. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 23]

[0085] In yet another example, the corresponding decoding process based on the VVC draft is shown below: A and T.H. B is a given threshold (e.g., TH A =8,TH B= 18 or 19). The changes to the VVC draft are shown in bold italic font in Table 19. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 24]

[0086] FIG. 6 illustrates a method for video encoding. The method may be applied to, for example, an encoder. In step 1610, the encoder may receive a video input. The video input may be, for example, a live stream. In step 1612, the encoder may obtain a quantization parameter based on the video input. The quantization parameter may be calculated, for example, by a quantization unit in the encoder. In step 1614, the encoder may derive a Rice parameter based on at least one predefined threshold, the coding bit depth, and the quantization parameter. The Rice parameter is used, for example, to signal abs_remainder and dec_abs_level syntax. In step 1616, the encoder may entropy encode a video bitstream based on the Rice parameter. The video bitstream may be entropy encoded, for example, to generate a compressed video bitstream.

[0087] In yet another example, when BitDepth is greater than 10, it is proposed to use only fixed values ​​(e.g., 2, 3, 4, 5, 6, 7, or 8) for the Rice parameter when encoding the syntax element of abs_remainder. The fixed values ​​may be different in different conditions according to the specific encoded information of the current block, e.g., the quantization parameters. The corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). The changes to the VVC draft are shown in bold italic font in Table 20. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 25]

[0088] In yet another example, the corresponding decoding process based on the VVC draft is shown below: A and T.H. B is a given threshold (e.g., TH A =8,TH B = 18 or 19). The changes to the VVC draft are shown in bold italic font in Table 21. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 26]

[0089] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 33 or 34). The changes to the VVC draft are shown in bold italic font in Table 22. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 27]

[0090] In yet another example, the corresponding decoding process based on the VVC draft is shown below: A and T.H. B is a given threshold (e.g., TH A =8,TH B = 33 or 34). The changes to the VVC draft are shown in bold italic font in Table 23. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 28]

[0091] It is worth mentioning that in the above illustration, the equation used to calculate a specific Rice parameter is used only as an example to illustrate the proposed idea. For those skilled in the art of modern video coding techniques, other mapping functions (or equivalent mapping equations) are already applicable to the proposed idea (i.e., determining the Rice parameter of the transform skip mode based on the coded bits and the applied quantization parameter). Meanwhile, it should also be mentioned that the current VVC design allows the value of the applied quantization parameter to change at the coding block group level. Therefore, the proposed Rice parameter adjustment scheme can provide flexible adaptation of the Rice parameter of the transform skip mode at the coding block group level.

[0092] Signaling information for normal residual coding and transform skip residual coding According to one or more examples of the present disclosure, it is proposed to signal certain syntax elements in transform skip residual coding, e.g., the Rice parameter of a binary codeword for coding abs_remainder, shift and offset parameters for derivation of the Rice parameter used for abs_remainder / dec_abs_level in normal residual coding, as well as to decide whether to signal according to certain coded information of the current block, e.g., quantization parameters or coding bit depth associated with the TB / 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.

[0093] In one example, one control flag is signaled in the slice header to indicate whether the signaling of Rice parameters for transform skip blocks and the signaling of shift and / or offset parameters for the derivation of Rice parameters in transform blocks are enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the Rice parameters of that slice, and two syntax elements are further signaled for each transform slice to indicate the shift and / or offset parameters for the derivation of Rice parameters of that slice. When the control flag is signaled as disabled (e.g., set to be equal to "0"), no further syntax elements are signaled at lower levels to indicate the Rice parameters of transform skip slices, and default Rice parameters (e.g., 1) are used for all transform skip slices, and no further syntax elements are signaled at lower levels to indicate the shift and offset parameters for the Rice parameter derivation of transform slices, and default shift and / or offset parameters (e.g., 0) are used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold italic font in Table 24. It is worth noting that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_index can be coded in various ways and / or have maximum values. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits, written left bit first (left to right), may also be used to code / decode the same syntax element.

[0094] 7 shows a method for video decoding. The method may be applied to, for example, an encoder. In step 1710, the encoder may receive a video input. In step 1712, the encoder may signal a Rice parameter of a binary codeword for a coding syntax element. The coding syntax element may include abs_remainder in transform skip residual coding. In step 1714, the encoder may entropy code a video bitstream based on the Rice parameter and the video input.

[0095] Slice Header Syntax [Table 29]

[0096] sh_residual_coding_rice_flag equal to 1 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index may be present in the current slice. sh_residual_coding_rice_flag equal to 0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index are not present in the current slice.

[0097] sh_residual_coding_rice_shift specifies the shift parameter used in 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 equal to 0.

[0098] sh_residual_coding_rice_offset specifies the offset parameter used in 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.

[0099] sh_ts_residual_coding_rice_index specifies the rice parameter used in the residual_ts_coding() syntax construct. 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 30] [Table 31]

[0100] In another example, one control flag is signaled in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether the signaling of Rice parameters for transform skip blocks and the signaling of shift parameters and / or offset parameters for the derivation of Rice parameters in transform blocks are enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the Rice parameters of that slice, and two syntax elements are further signaled for each transform slice to indicate the shift parameters and / or offset parameters for the derivation of Rice parameters of that slice. When the control flag is signaled as disabled (e.g., when set equal to "0"), no further syntax elements are signaled at lower levels to indicate the Rice parameters of transform skip slices, and default Rice parameters (e.g., 1) are used for all transform skip slices, and no further syntax elements are signaled at lower levels to indicate the shift parameters and / or offset parameters for the Rice parameter derivation of transform slices, and default shift parameters and / or offset parameters (e.g., 0) are used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold italic font in Table 27. It is worth noting that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be coded in various ways and / or have maximum values. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits, written left bit first (left to right), may also be used to code / decode the same syntax element.

[0101] Sequence Parameter Set RBSP Syntax [Table 32]

[0102] 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 may be present in the SH syntax structure that references the 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 the SH syntax structure that references the 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 equal to 0.

[0103] Slice Header Syntax [Table 33]

[0104] sh_residual_coding_rice_shift specifies the shift parameter used in 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 equal to 0.

[0105] sh_residual_coding_rice_offset specifies the offset parameter used in 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.

[0106] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax construct. 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 34] [Table 35]

[0107] In yet another example, one syntax element is signaled for each transform skip slice to indicate the Rice parameter for that slice, and two syntax elements are signaled for each transform slice to indicate the shift and / or offset parameters for the derivation of the Rice parameter for that slice. An example of the corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold italic font in Table 31. It is worth noting that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be coded in various ways and / or have maximum values. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits, written left bit first (left to right), may also be used to code / decode the same syntax element.

[0108] Slice Header Syntax [Table 36]

[0109] sh_ts_residual_coding_rice_idx specifies the rice parameter used in 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 equal to 0.

[0110] sh_residual_coding_rice_offset specifies the offset parameter used in 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.

[0111] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax construct. 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 37] [Table 38]

[0112] In yet another example, one control flag is signaled in the picture parameter set range extension syntax to indicate whether the signaling of Rice parameters for transform skip blocks and the signaling of shift and / or offset parameters for the derivation of Rice parameters in transform blocks are enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled to indicate the Rice parameters for transform skip residual coding of the picture, and two syntax elements are further signaled to indicate the shift and / or offset parameters for the derivation of Rice parameters of the picture per normal residual coding. When the control flag is signaled as disabled (e.g., set equal to “0”), no further syntax elements are signaled at lower levels to indicate the Rice parameters for transform skip residual coding, and the default Rice parameters (e.g., 1) are used for all transform skip residual coding, and no further syntax elements are signaled at lower levels to indicate the shift and / or offset parameters for the Rice parameter derivation for normal residual coding, and the default shift and / or offset parameters (e.g., 0) are used for all normal residual coding. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold italic font in Table 34. It is worth noting that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_idx can be coded in various ways and / or have maximum values. For example, to encode / decode the same syntax element, one may also use u(n), an unsigned integer using n bits, or f(n), a fixed-pattern bit sequence using n bits, written left bit first (left to right).

[0113] Picture Parameter Set Range Extension Syntax [Table 39]

[0114] 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 may be present in the current picture. 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_idx are not present in the current picture. When pps_residual_coding_info_flag is not present, the value of pps_residual_coding_info_flag is inferred to be equal to 0.

[0115] pps_residual_coding_rice_shift specifies the shift parameter used in 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.

[0116] pps_residual_coding_rice_offset specifies the offset parameter used in the Rice parameter derivation process for abs_remainder[] and dec_abs_level[]. When pps_residual_coding_rice_offset is not present, the value of pps_residual_coding_rice_offset is inferred to be equal to 0.

[0117] pps_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. When pps_ts_residual_coding_rice_index is not present, the value of pps_ts_residual_coding_rice_index is inferred to be equal to 0. [Table 40] [Table 41]

[0118] According to one or more examples of the present disclosure, it is proposed to use different Rice parameters for coding certain syntax elements in transform skip residual coding, e.g., abs_remainder, shift and offset parameters for derivation of the Rice parameters used for abs_remainder / dec_abs_level in normal residual coding, and to decide which one to use according to certain coded information of the current block, e.g., quantization parameters or coding bit depth associated with the TB / 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.

[0119] In one example, one control flag is signaled in the slice header to indicate whether the derivation process of the Rice parameter of the transform skip block and the derivation process of the shift parameter and / or offset parameter of the Rice parameter in the transform block are enabled or disabled. When the control flag is signaled as enabled, the Rice parameter may be different in different conditions according to the specific coded information of the current block, such as the quantization parameter and bit depth. Also, the shift parameter and / or offset parameter for the derivation of the Rice parameter in normal residual coding may be different in different conditions according to the specific coded information of the current block, such as the quantization parameter and bit depth. When the control flag is signaled as disabled (e.g., set to be equal to "0"), the default Rice parameter (e.g., 1) is used for all transform skip slices, and the default shift parameter and / or offset parameter (e.g., 0) is used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below, and the TH A and T.H. B is a given threshold (e.g., TH A =8,TH B = 18 or 19). The changes to the VVC draft are shown in bold italic font in Table 37. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters.

[0120] Slice Header Syntax [Table 42]

[0121] sh_residual_coding_rice_flag equal to 1 specifies that the bit-depth dependent Rice parameter derivation process is used for the current slice. sh_residual_coding_rice_flag equal to 0 specifies that the bit-depth dependent Rice parameter derivation process is not used for the current slice. [Table 43] [Table 44]

[0122] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). The changes to the VVC draft are shown in bold italic font in Table 40. It is worth noting that in practice the same logic may be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameters. [Table 45] JPEG0007676649000047.jpg83161

[0123] According to another aspect of the present disclosure, it is proposed to add constraints that the values ​​of these encoding tools above flag in order to provide the same general constraint control as the others in the general constraint information.

[0124] For example, sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx may be present in the SH syntax structure that references the SPS. sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 specifies that sh_ts_residual_coding_rice_idx is not present in the SH syntax structure that references the SPS. According to the present disclosure, it is proposed to add a syntax element gci_no_ts_residual_coding_rice_constraint_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 46] [Table 47]

[0125] In another example, pps_ts_residual_coding_rice_flag equal to 1 specifies that pps_ts_residual_coding_rice_index may be present in the current picture. pps_ts_residual_coding_rice_flag equal to 0 specifies that pps_ts_residual_coding_rice_idx is not present in the current picture. According to the present disclosure, it is proposed to add a syntax element gci_no_ts_residual_coding_rice_constraint_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The added parts are highlighted in italics. [Table 48]

Table 49

[0126] In yet another example, when sps_rice_adaptation_enabled_flag is equal to 1, it indicates that the Rice parameters for the binarization of abs_remainder[] and dec_abs_level can be derived by an expression.

[0127] The expression 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 Tx[] = {32, 128, 512, 2048}>>(1523) Rx[] = {0, 2, 4, 6, 8}.

[0128] According to the present disclosure, in order to provide the same general constraint control as other flags, it is proposed to add a syntax element gci_no_rice_adaptation_constraint_flag to the general constraint information syntax. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The added parts are emphasized in italics.

Table 50

Table 51

[0129] Since the proposed Rice parameter adaptation scheme is only used for transform skip residual coding (TSRC), the proposed method can be effective when TSRC is enabled. Correspondingly, in one or more embodiments of the present disclosure, it is proposed to add one bitstream constraint that requires the value of gci_no_rice_adaptation_constraint_flag to be 1 when the transform skip mode is disabled from the general constraint information level, e.g., when the value of gci_no_transform_skip_constraint_flag is set to 1.

[0130] In yet another example, sps_range_extension_flag equal to 1 specifies the presence of sps_range_extension() syntax structure in the SPS RBSP syntax structure. sps_range_extension_flag equal to 0 specifies the absence of this syntax structure. According to the present disclosure, it is proposed to add a syntax element gci_no_range_extension_constraint_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 52] [Table 53]

[0131] 9 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 1902, the decoder may receive a sequence parameter set (SPS) range extension flag indicating whether a syntax structure sps_range_extension is present in a raw byte sequence payload (RBSP) syntax structure of a slice head (SH) based on a value of the SPS range extension flag.

[0132] At step 1904, in response to determining that the value of the SPS range extension flag is equal to one, the decoder may determine that sps_range_extension is present in the SH RBSP syntax structure.

[0133] At step 1906, in response to determining that the value of the range extension flag is equal to 0, the decoder may determine that sps_range_extension is not present in the SH RBSP syntax structure.

[0134] sps_cabac_bypass_alignment_enabled_flag specifies that the value of ivlCurrRange may be aligned before bypass decoding of 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 ivlCurrRange is not aligned before bypass decoding. According to this disclosure, it is proposed to add syntax element gci_no_cabac_bypass_alignment_constraint_flag in the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 54] [Table 55]

[0135] 10 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2002, the decoder may receive a sequence parameter set (SPS) alignment enable flag indicating whether the index ivlCurrRange is aligned before bypass decoding of syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flagn based on a value of SPS alignment enable.

[0136] At step 2004, in response to determining that the value of the SPS alignment valid flag is equal to one, the decoder may determine that the ivlCurrRange is aligned prior to bypass decoding.

[0137] In step 2006, in response to determining that the value of the SPS alignment valid flag is equal to 0, the decoder may determine that the ivlCurrRange is not aligned prior to bypass decoding.

[0138] In yet another example, extended_precision_processing_flag equal to 1 specifies that extended dynamic range may be used for transform coefficients and transform processing. extended_precision_processing_flag equal to 0 specifies that extended dynamic range is not used. According to the present disclosure, it is proposed to add a syntax element gci_no_extended_precision_processing_constraint_flag in the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The added parts are highlighted in italics. [Table 56] [Table 57]

[0139] 11 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2102, the decoder may include receiving an extended precision processing flag indicating whether an extended dynamic range is employed for the transform coefficients and during the transform process based on a value of the extended precision processing flag.

[0140] In step 2104, in response to determining that the value of the extended precision processing flag is equal to one, the decoder may determine that extended dynamic range is to be employed for the transform coefficients and during the transform process.

[0141] In step 2106, in response to determining that the value of the extended precision processing flag is equal to 0, the decoder may determine that extended dynamic range is not employed for the transform coefficients or during the transform process.

[0142] In yet another example, persistent_rice_adaptation_enabled_flag equal to 1 specifies that the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level at the beginning of each sub-block may be initialized using mode-dependent statistics accumulated from the previous sub-block. persistent_rice_adaptation_enabled_flag equal to 0 specifies that the previous sub-block state is not used in the Rice parameter derivation. According to the present disclosure, it is proposed to add a syntax element gci_no_persistent_rice_adaptation_constraint_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The added parts are highlighted in italics. [Table 58] [Table 59]

[0143] 12 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2202, the decoder may receive a persistent Rice adaptation enable flag indicating whether Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each sub-block employing mode-dependent statistics accumulated from the previous sub-block based on the value of the persistent Rice adaptation enable flag.

[0144] In step 2204, in response to determining that the value of the persistent Rice adaptation enable flag is equal to one, the decoder may determine that the Rice parameter derivation for binarization is initialized at the beginning of each sub-block employing mode-dependent statistics accumulated from the previous sub-block.

[0145] At step 2206, in response to determining that the value of the persistent Rice adaptation valid flag is equal to 0, the decoder may determine that the previous sub-block state is not to be employed in the Rice parameter derivation.

[0146] In yet another example, sps_rrc_rice_extension_flag equal to 1 specifies that the extension of the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is enabled. sps_rrc_rice_extension_flag equal to 0 specifies that the extension of the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is disabled. According to the present disclosure, it is proposed to add a syntax element gci_no_rrc_rice_extension_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are shown in italic font below. [Table 60] [Table 61]

[0147] 17 illustrates a method for video decoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2702, the decoder may receive an SPS Rice extension flag indicating whether an extension of the Rice parameter derivation for binarization of abs_remainder and dec_abs_level is enabled.

[0148] At step 2704, in response to determining that the value of the SPS Rice extension flag is equal to one, the decoder may determine that extension of the Rice parameter derivation for binarization is enabled.

[0149] At step 2706, in response to determining that the value of the SPS Rice extension flag is equal to 0, the decoder may determine that extension of the Rice parameter derivation for binarization is disabled.

[0150] In yet another example, sps_persistent_rice_adaptation_enabled_flag equal to 1 specifies that the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is initialized at the beginning of each TU using statistics accumulated from the previous TU. sps_persistent_rice_adaptation_enabled_flag equal to 0 specifies that the previous TU state is not used in the Rice parameter derivation. According to the present disclosure, it is proposed to add a syntax element gci_no_persistent_rice_adaptation_enabled_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are shown in italic font below. [Table 62] [Table 63]

[0151] 18 illustrates a method for video decoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2802, the decoder may receive an SPS Rice adaptation enable flag indicating whether the Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each transform unit using statistics accumulated from the previous TU.

[0152] In step 2804, in response to determining that the value of the SPS Rice adaptation enable flag is equal to one, the decoder may determine that the Rice parameter derivation for binarization is initialized at the beginning of each TU using statistics accumulated from the previous TU.

[0153] At step 2806, in response to determining that the value of the SPS Rice adaptation valid flag is equal to 0, the decoder may determine that the previous TU state is not to be employed in the Rice parameter derivation.

[0154] In yet another example, sps_reverse_last_sig_coeff_enabled_flag equal to 1 specifies that sh_reverse_last_sig_coeff_flag is present in the slice_header() syntax structure that references the SPS. sps_reverse_last_sig_coeff_enabled_flag equal to 0 specifies that sh_reverse_last_sig_coeff_flag is not present in the slice_header() syntax structure that references the SPS. According to the present disclosure, it is proposed to add a syntax element gci_no_reverse_last_sig_coeff_enabled_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 64] [Table 65]

[0155] sh_reverse_last_sig_coeff_flag equal to 1 specifies that the coordinates of the last significant coefficient are coded relative to ((Log2ZoTbWidth<<1)-1,(Log2ZoTbHeight<<1)-1) of each transform block of the current slice. sh_reverse_last_sig_coeff_flag equal to 0 specifies that the coordinates of the last significant coefficient are coded relative to (0,0) of each transform block of the current slice. When not present, the value of sh_reverse_last_sig_coeff_flag is inferred to be equal to 0.

[0156] 19 illustrates a method for video decoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 2902, the decoder may receive an SPS reversed coordinate of a last significant coefficient enabled flag indicating whether the SH reversed coordinate of the last significant coefficient enabled flag is present in a slice header syntax structure that references an SPS.

[0157] In step 2904, in response to determining that the value of the SPS inverse coordinate of the last significant coefficient enable flag is equal to one, the decoder may determine that the SH inverse coordinate of the last significant coefficient enable flag is present in a slice header syntax structure that references the SPS.

[0158] In step 2906, in response to determining that the value of the SPS inverse coordinate of the last significant coefficient enable flag is equal to 0, the decoder may determine that the SH inverse coordinate of the last significant coefficient enable flag is not present in the slice header syntax structure that references the SPS.

[0159] In yet another example, sps_transform_precision_adaptation_enabled_flag equal to 1 specifies that the scaling of transform coefficients and the downshifting of scaled transform coefficients are adaptively assigned by inspecting coefficient values ​​during inverse quantization and inverse transformation. According to the present disclosure, it is proposed to add a syntax element gci_no_transform_precision_adaptation_enabled_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 66] [Table 67]

[0160] 20 shows a method for video decoding according to an example of the present disclosure. The method may be applied to a decoder, for example. In step 3002, the decoder may receive an SPS transform precision adaptation enable flag, which indicates whether the scaling process of transform coefficients and the downshifting process of scaled transform coefficients are adaptively assigned by checking the coefficient values ​​of inverse quantization and inverse transformation.

[0161] In step 3004, in response to determining that the value of the SPS transform precision adaptation enable flag is equal to one, the decoder may determine that scaling of transform coefficients and downshifting in the transformation process of scaled transform coefficients are adaptively assigned by examining the coefficient values ​​of inverse quantization and inverse transformation.

[0162] In yet another example, sps_high_throughput_flag equal to 1 may determine that all syntax elements in the residual coding except the last significant coefficient position in the RRC are coded through bypass mode, and only one alignment is required after the last significant coefficient position in the RRC and at the very beginning of the TB of the TSRC. According to the present disclosure, it is proposed to add a syntax element gci_no_high_throughput_flag in the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. The changes to the VVC draft are highlighted. The additions are highlighted in italics. [Table 68] [Table 69]

[0163] 21 illustrates a method for video decoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 3102, the decoder may receive an SPS high throughput flag indicating whether a syntax element in the residual coding is coded through a bypass mode.

[0164] In step 3104, in response to determining that the value of the SPS high throughput flag is equal to 1, the decoder may determine that all syntax elements in the residual coding except for the position of the last significant coefficient in regular residual coding (RRC) are coded via bypass mode, and alignment is performed after the position of the last significant coefficient and at the beginning of the transform block (TB) in transform skip residual coding (TSRC).

[0165] The above methods may be implemented using an apparatus including one or more circuits, including an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a controller, a microcontroller, a microprocessor, or other electronic components. The apparatus may use the circuits in combination with other hardware or software components to perform the methods described above. Each module, sub-module, unit, or sub-unit disclosed above may be at least partially implemented using one or more circuits.

[0166] Determination of rice parameters On the encoder side, TSRC coding may require multiple coding passes to derive the best Rice parameter. This multi-pass coding may not be suitable for the design of a practical hardware encoder. To solve this problem, a low-delay TSRC coding method is also proposed. According to one or more examples of the present disclosure, it is proposed to derive the Rice parameter according to the specific coded information of the current slice, such as the quantization parameter and / or coding bit depth associated with the slice / picture / sequence, and / or according to the hash ratio associated with the level of the slice / picture / sequence. Various methods may be used to derive the Rice parameter, and some exemplary methods are listed below. It should be noted that the following methods may be applied alone or in combination.

[0167] 1. The Rice parameters mentioned in the above embodiments may further depend on the video resolution, including both the temporal resolution (e.g., frame rate) and spatial resolution (e.g., picture width and height) of the video.

[0168] 2. The Rice parameter may vary at the sequence level, picture level, slice level, and / or any given region. In one specific example, different Rice values ​​are used for pictures with different temporal layer IDs (related to nuh_temporal_id_plus1 specified in the VVC specification). Alternatively, the Rice parameter may include a value determined based on the QP value used at the sequence level, picture level, slice level, and / or any given region. For example, the Rice parameter = Clip3 (1, 8, (TH-QP) / 6), where TH is a predefined threshold (e.g., 18, 19).

[0169] 3. The Rice parameter may be set as a default value, e.g., 1, according to the change in the coded information between the current slice and the previous slice. In a specific example, when the temporal layer ID has changed compared to the previous picture, the default Rice value is used for the picture. Alternatively, when ΔQ is greater than TH, the default Rice value is used for the picture, where ΔQ is calculated as abs(QPcurrent-QPprevious), and TH is a predefined threshold. Rice parameter (e.g., 0, 5). For example, when the hash ratio from the intra block copy mode of the current slice is greater than TH, the Rice parameter=1, where TH is a predefined threshold, e.g., Max(41*(number of CTUs), 4200).

[0170] 4. The Rice parameter of each slice based on the value of abs_remainder coded in its preceding slice according to the coding order. In a specific example, after one slice is coded, the number of bins for binarization of abs_remainder using different Rice parameters is calculated, and then the number is used to determine the Rice parameter of the subsequent slice. For example, the Rice parameter that achieves the minimum number of bins in the preceding slice is selected for the current slice. As another example, if the current slice and its preceding slice use the same QP, the Rice parameter that achieves the minimum number of bins in the preceding slice is selected for the current slice, otherwise, the number of bins generated in the preceding slice using the default Rice parameter (i.e., 1) is scaled by TH before being compared with other Rice parameters, and the Rice parameter that results in the minimum number of bins is selected for the current slice, where TH is a predetermined threshold, e.g., 0.9.

[0171] 5. The Rice parameter of each slice based on the value of abs_remainder coded in its previous slice according to the coding order, and the Rice parameter may be adjusted according to the change in coded information between the current slice and the previous slice. In a specific example, for example, the Rice parameter that achieves the minimum number of bins in the previous slice is selected for the current slice. Also, when ΔQ is larger than TH, the Rice value may be adjusted, where ΔQ is calculated as abs(QPcurrent-QPprevious), and TH is a predetermined threshold. Rice parameter (e.g., 0, 5). The adjustment may be adding a predetermined offset (e.g., +1, -1) or scaling by a predetermined value.

[0172] Bitstream Constraints In one or more examples of the present disclosure, it is proposed to disable the presence of Rice parameters for transform skip residual coding and high bit depth tools for low bit depth coding. In one specific example, to achieve such a goal, it is proposed to add a bitstream compliance requirement indicating that such tools are disabled when the bit depth is 10 or less in a profile definition such as HEVC or its semantics.

[0173] For example, sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx may be present in SH syntactic structures that reference an SPS. Changes to the current VVC Working Draft are:

[0174] It is a bitstream compliance requirement that the value of sps_ts_residual_coding_rice_present_in_sh_flag be equal to 0 when BitDepth is 10 or less.

[0175] In another example, sps_rrc_rice_extension_flag equal to 1 specifies that the extension of the Rice parameter derivation for binarization of abs_remaining[] and dec_abs_level[] is enabled. sps_rrc_rice_extension_flag equal to 0 specifies that the extension of the Rice parameter derivation for binarization of abs_remaining[] and dec_abs_level[] is disabled. According to this disclosure, the changes to the current VVC working draft are as follows:

[0176] It is a bitstream compliance requirement that the value of sps_rrc_rice_extension_flag be equal to 0 when BitDepth is 10 or less.

[0177] In yet another example, sps_persistent_rice_adaptation_enabled_flag equal to 1 specifies that the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is initialized at the beginning of each TU using accumulated statistics from the previous TU. sps_persistent_rice_adaptation_enabled_flag equal to 0 specifies that the previous TU state is not used for the derivation of the Rice parameters. According to this disclosure, the changes to the current VVC working draft are as follows:

[0178] It is a bitstream compliance requirement that the value of sps_persistent_rice_adaptation_enabled_flag be equal to 0 when BitDepth is 10 or less.

[0179] In yet another example, sps_reverse_last_sig_coeff_enabled_flag equal to 1 specifies that sh_reverse_last_sig_coeff_flag is present in the slice_header() syntax structure that references the SPS. sps_reverse_last_sig_coeff_enabled_flag equal to 0 specifies that sh_reverse_last_sig_coeff_flag is not present in the slice_header() syntax structure that references the SPS. According to this disclosure, the changes to the current VVC working draft are as follows:

[0180] It is a bitstream compliance requirement that the value of sps_reverse_last_sig_coeff_enabled_flag be equal to 0 when BitDepth is 10 or less.

[0181] In yet another example, sps_high_throughput_flag equal to 1 specifies that the syntax elements in the residual coding are coded through bypass mode. According to this disclosure, the changes to the current VVC working draft are as follows:

[0182] It is a bitstream compliance requirement that the value of sps_high_throughput_flag be equal to 0 when BitDepth is 10 or less.

[0183] Moreover, it is worth mentioning that the proposed bitstream compliant constraint on the coding bit depth sps_ts_residual_coding_rice_present_in_sh_flag is orthogonal to the slice level flag conditioned signal of the transform skip flag, i.e. sps_transform_skip_enabled_flag. In one embodiment, in such a combination, the flag sps_transform_skip_enabled_flag is used to condition the presence of sps_ts_residual_coding_rice_present_in_sh_flag. On the other hand, a compliant bitstream is also applied to require that sps_ts_residual_coding_rice_present_in_sh_flag can be equal to 1 only when the coding bit depth value is greater than 10. The following shows the SPS syntax table and the semantic changes when such a method is applied. [Table 70]

[0184] sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 specifies that sh_ts_residual_coding_rice_idx may be present in SH syntax structures that reference an SPS. Changes to the current VVC Working Draft are:

[0185] It is a bitstream compliance requirement that the value of sps_ts_residual_coding_rice_present_in_sh_flag be equal to 0 when BitDepth is 10 or less.

[0186] FIG. 22 illustrates a method for video decoding according to an example of the present disclosure. The method may be applied to, for example, a decoder. In step 3202, the decoder may determine an encoding bit depth of at least one sample in a bitstream. In step 3204, the decoder may determine a value of a first SPS flag for the at least one sample. In step 3206, the decoder may determine a second SPS flag for the at least one sample based on the value of the first SPS flag in combination with the encoding bit depth of the at least one sample. In some examples, the decoder may determine the presence of the second SPS flag based on the first SPS flag or may determine the value of the second SPS flag based on the encoding bit depth. In some examples, the decoder may determine the presence of the second SPS flag based on the first SPS flag and the encoding bit depth. In some examples, the decoder may determine the value of the second SPS flag based on the first SPS flag and the encoding bit depth. In some other examples, the decoder may determine the value of the second SPS flag based on the coding bit depth, regardless of the value of the first SPS flag.

[0187] In another embodiment, instead of applying bitstream compliance, it is proposed to directly use the bit depth and the flag sps_transform_skip_enabled_flag to condition the signaling of the flag sps_ts_residual_coding_rice_present_in_sh_flag. Specifically, such a method signals the value of the flag sps_ts_residual_coding_rice_present_in_sh_flag only when sps_transform_skip_enabled_flag is equal to 1 and the coding bit depth is greater than 10, as shown below: [Table 71]

[0188] FIG. 16 illustrates a flow diagram of a low-delay transform skip residual coding (TSRC) method according to an example of the present disclosure. The method may be applied to an encoder, for example. In step 2602, the encoder may derive a Rice parameter based on encoded information of a current slice of a video. The encoded information may include one or more of the following parameters: a quantization parameter or a coding bit depth associated with the slice, picture, or sequence of the video, or a hash ratio associated with the slice, picture, or sequence of the video.

[0189] It should be noted that the above encoder method may also be applied to the decoder side. In a specific example, the Rice parameters do not need to be signaled to the decoder, and the encoder / decoder derives the Rice parameters using the same method.

[0190] 8 illustrates a computing environment 1810 coupled with a user interface 1860. The computing environment 1810 may be part of a data processing server. The computing environment 1810 includes a processor 1820, a memory 1840, and an I / O interface 1850.

[0191] The processor 1820 typically controls the overall operation of the computing environment 1810, such as operations related to display, data acquisition, data communication, and image processing. The processor 1820 may include one or more processors for executing instructions to perform all or some of the steps in the methods described above. Additionally, the processor 1820 may include one or more modules that facilitate interaction between the processor 1820 and other components. The processor may be a central processing unit (CPU), a microprocessor, a single chip machine, a GPU, etc.

[0192] The memory 1840 is configured to store various types of data to support the operation of the computing environment 1810. The memory 1840 may include predefined software 1842. Examples of such data include instructions for any application or method operating on the computing environment 1810, video data sets, image data, etc. The memory 1840 may be implemented by using any type of volatile or non-volatile memory device or combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0193] The I / O interface 1850 provides an interface between the processor 1820 and peripheral interface modules such as a keyboard, click wheel, buttons, and the like. The buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. The I / O interface 1850 may be coupled to encoders and decoders.

[0194] In some embodiments, a non-transitory computer readable storage medium is also provided that includes a number of programs, such as those contained in memory 1840, executable by processor 1820 in computing environment 1810 for performing the methods described above. For example, the non-transitory computer readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, or the like.

[0195] A non-transitory computer-readable storage medium has stored therein a plurality of programs executed by a computing device having one or more processors, the plurality of programs, when executed by the one or more processors, causing the computing device to perform the above-described method for motion prediction.

[0196] In some embodiments, the computing environment 1810 may be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable arrays (FPGAs), graphical processing units (GPUs), controllers, microcontrollers, microprocessors, or other electronic components for performing the methods described above.

[0197] FIG. 13 is a block diagram illustrating an example system 10 for encoding and decoding video blocks in parallel, according to some implementations of the present disclosure. As shown in FIG. 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 include any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smart phones, 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.

[0198] In some implementations, the destination device 14 may receive the encoded video data to be decoded via a link 16. The link 16 may include any type of communication medium or communication device capable of moving the encoded video data from the source device 12 to the destination device 14. In one example, the link 16 may include 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 communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form 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.

[0199] In some other implementations, the encoded video data may be transmitted from the output interface 22 to the storage device 32. The encoded video data in the storage device 32 may then be accessed by the destination device 14 via the input interface 28. The storage device 32 may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, a Blu-ray disc, a digital versatile disc (DVD), a compact disc read only memory (CD-ROM), a flash memory, a volatile or non-volatile memory, or any other suitable digital storage medium for storing the encoded video data. In a further example, the storage device 32 may correspond to a file server or another intermediate storage device capable of holding the encoded video data generated by the source device 12. The destination device 14 may access the stored video data from the storage device 32 via streaming or download. The file server may be any type of computer capable of storing the encoded video data and transmitting the encoded video data to the destination device 14. Exemplary file servers include web servers (e.g., for websites), file transfer protocol (FTP) servers, network attached storage (NAS) devices, or local disk drives. Destination device 14 may 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., a Digital Subscriber Line (DSL), cable modem, etc.), or a combination of both suitable for accessing encoded video data stored on a file server. Transmission of the encoded video data from storage device 32 may be a streaming transmission, a download transmission, or a combination of both.

[0200] As shown in FIG. 13, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources such as a video capture device, e.g., a video camera, a video archive 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 source video, or a combination of such sources. As an example, if video source 18 is a video camera of a security surveillance system, source device 12 and destination device 14 may form a camera phone or a video phone. However, implementations described in this application may be applicable to video encoding in general and may be applicable to wireless and / or wired applications.

[0201] The captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video data may be transmitted directly to destination device 14 via output interface 22 of source device 12. The encoded video data may also (or alternatively) be stored on storage device 32 for later access by destination device 14 or other devices for decoding and / or playback. Output interface 22 may further include a modem and / or a transmitter.

[0202] Destination device 14 includes an input interface 28, a video decoder 30, and a display device 34. Input interface 28 may include a receiver and / or modem and receive encoded video data over link 16. The encoded video data communicated over link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use in decoding the video data by video decoder 30. 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.

[0203] In some implementations, destination device 14 may include a display device 34, which may be an integrated display device as well as an external display device configured to communicate with destination device 14. Display device 34 displays the decoded video data to a user and may include 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.

[0204] Video encoder 20 and video decoder 30 may operate according to a proprietary or industry standard, such as VVC, HEVC, MPEG-4, Part 10, AVC, or extensions of such standards. It should be understood that the present application is not limited to a particular video encoding / decoding standard, but is applicable to other video encoding / decoding standards. In general, it is contemplated that video encoder 20 of source device 12 may be configured to encode video data according to any of these current or future standards. Similarly, it is also contemplated that video decoder 30 of destination device 14 may be configured to decode video data according to any of these current or future standards.

[0205] Each of the video encoder 20 and the video decoder 30 may be implemented as any of a variety of suitable encoder and / or decoder circuits, 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. If implemented partially in software, the electronic device may store instructions for the software on a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the video encoding / decoding operations disclosed in this disclosure. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, either of which may be integrated as part of a combined encoder / decoder (CODEC) within the respective device.

[0206] FIG. 14 is a block diagram illustrating an example video encoder 20 according to some implementations described in the present application. Video encoder 20 may perform intra-predictive and inter-predictive coding of video blocks in video frames. Intra-predictive coding relies on spatial prediction to reduce or remove spatial redundancy of video data in a given video frame or picture. Inter-predictive coding relies on temporal prediction to reduce or remove temporal redundancy of video data in adjacent video frames or pictures of a video sequence. It should be noted that the term "frame" may be used synonymously with the term "image" or "picture" in the field of video coding.

[0207] As shown in FIG. 14, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture 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 41 further includes a motion estimation unit 42, a motion compensation unit 44, a partition 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. An in-loop filter 63, such as a deblocking filter, may be disposed between the adder 62 and the DPB 64 to filter block boundaries and remove blocky artifacts from the reconstructed video. In addition to the deblocking filter, another in-loop filter, such as a sample adaptive offset (SAO) filter and / or an adaptive in-loop filter (ALF), may also be used to filter the output of the adder 62. In some examples, the in-loop filter may be omitted, and the decoded video blocks may be provided directly to DPB 64 by summer 62. Video encoder 20 may take the form of a fixed or programmable hardware unit, or may be divided into one or more of the illustrated fixed or programmable hardware units.

[0208] Video data memory 40 may store video data to be encoded by components of video encoder 20. The video data in video data memory 40 may be obtained, for example, from video source 18 shown in FIG. 13. DPB 64 is a buffer that stores reference video data (e.g., reference frames or pictures) for use in encoding the video data by video encoder 20 (e.g., in an intra-predictive coding mode or an inter-predictive coding mode). Video data memory 40 and DPB 64 may be formed by any of a variety of memory devices. In various examples, video data memory 40 may be on-chip with other components of video encoder 20 or off-chip relative to those components.

[0209] As shown in FIG. 14, after receiving the video data, partition unit 45 in prediction processing unit 41 partitions the video data into video blocks. This partitioning also includes partitioning the video frame into slices, tiles (e.g., a set of video blocks), or other larger coding units (CUs) according to a predefined decomposition structure, such as a Quad-Tree (QT) structure associated with the video data. A video frame may be or be considered as a two-dimensional array or matrix of samples having sample values. The samples in the array may also be referred to as pixels or pels. The number of samples in the horizontal and vertical directions (or axes) of the array or picture defines the size and / or resolution of the video frame. The video frame may be divided into multiple video blocks, for example, by using QT partitioning. A video block may also be or be considered as a two-dimensional array or matrix of samples having sample values, although with smaller dimensions than a video frame. The number of samples in the horizontal and vertical directions (or axes) of a video block defines the size of the video block. A video block may be further partitioned into one or more block partitions or sub-blocks (which may again 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 may be a portion of a frame or picture, specifically a rectangular (square or non-square) portion. For example, with respect to HEVC and VVC, a block or video block may be or correspond to a coding tree unit (CTU), CU, prediction unit (PU), or transform unit (TU), and / or a corresponding block, e.g., a coding tree block (CTB), coding block (CB), prediction block (PB), or transform block (TB), and / or a sub-block.

[0210] Prediction processing unit 41 may select one of a number of possible predictive coding modes, such as one of a number of intra-predictive coding modes or one of a number of inter-predictive coding modes, for the current video block based on the error result (e.g., the coding rate and level of distortion). Prediction processing unit 41 may provide the resulting intra- or inter-predictive coded block to summer 50 to generate a residual block, and may also provide the resulting intra- or inter-predictive coded block to summer 62 to reconstruct a coded block for subsequent use as part of a reference frame. Prediction processing unit 41 also provides syntax elements, such as motion vectors, intra-mode indicators, partition information, and other such syntax information, to entropy coding unit 56.

[0211] To select an appropriate intra-prediction coding mode for a current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-prediction coding of the current video block relative to one or more neighboring blocks in the same frame as the current block to be encoded to provide spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 may perform inter-prediction coding of the current video block relative to one or more predictive blocks in one or more reference frames to provide temporal prediction. Video encoder 20 may perform multiple coding passes, e.g., to select an appropriate coding mode for each block of video data.

[0212] In some implementations, motion estimation unit 42 determines an inter prediction mode for a current video frame by generating a motion vector that indicates a displacement of a video block in a current video frame relative to a predictive block in a reference video frame according to a predetermined pattern in a sequence of video frames. Motion estimation performed by motion estimation unit 42 is a process of generating motion vectors that estimate the motion of a video block. For example, the motion vector may indicate a displacement of a video block in a current video frame or picture relative to a predictive block in a reference frame relative to a current block being coded in the current frame. The predetermined pattern designates a video frame in the sequence as a P frame or a B frame. Intra BC unit 48 may determine vectors, e.g., block vectors, for intra BC coding in a manner similar to the determination of motion vectors by motion estimation unit 42 for inter prediction, or may utilize motion estimation unit 42 to determine the block vectors.

[0213] The predictive block of a video block may be or correspond to a block of a reference frame or reference blocks that are considered to closely match in terms of pixel difference with the video block to be encoded, which may be determined by a sum of absolute difference (SAD), sum of square difference (SSD), or other difference metric. In some implementations, video encoder 20 may calculate values ​​for sub-integer pixel locations of the reference frame stored in DPB 64. For example, video encoder 20 may interpolate values ​​for quarter, eighth, or other fractional pixel locations of the reference frame. Thus, motion estimation unit 42 may perform motion search for whole and fractional pixel locations and output motion vectors with fractional pixel accuracy.

[0214] Motion estimation unit 42 calculates a motion vector for a video block in an inter-predictively coded frame by comparing the position of the video block with the position of a predictive block of a reference frame selected from a first reference frame list (List 0) or a second reference frame list (List 1), which respectively identify one or more reference frames stored in DPB 64. Motion estimation unit 42 sends the calculated motion vector to motion compensation unit 44 and then to entropy coding unit 56.

[0215] The motion compensation performed by motion compensation unit 44 may include fetching or generating a predictive block based on the motion vector determined by motion estimation unit 42. Upon receiving the motion vector for the current video block, motion compensation unit 44 may locate the predictive block to which the motion vector points in one of the reference frame lists, obtain the predictive block from DPB 64, and forward the predictive block to summer 50. Summer 50 then forms a residual video block of pixel difference values ​​by subtracting pixel values ​​of the predictive block provided by motion compensation unit 44 from pixel values ​​of the current video block being coded. The pixel difference values ​​forming the residual video block may include luma or chroma difference components, or both. Motion compensation unit 44 may also generate syntax elements associated with the video blocks of the video frames for use in decoding the video blocks of the video frames by video decoder 30. The syntax elements may include, for example, syntax elements defining the motion vector used to identify the predictive block, any flags indicating a prediction mode, or any other syntax information described herein. It should be noted that motion estimation unit 42 and motion compensation unit 44 may be highly integrated, but are shown separately for conceptual purposes.

[0216] In some implementations, intra BC unit 48 may generate vectors and fetch predictive blocks in a manner similar to that described above in connection with motion estimation unit 42 and motion compensation unit 44, except that the predictive block is in the same frame as the current block being coded, and the vectors are referred to as block vectors rather than motion vectors. Specifically, intra BC unit 48 may determine an intra prediction mode to use to code the current block. In some examples, intra BC unit 48 may code the current block using various intra prediction modes, e.g., during separate coding passes, and test their performance through rate-distortion analysis. Intra BC unit 48 may then select an appropriate intra prediction mode to use from among the various tested intra prediction modes and generate an intra mode indicator accordingly. For example, intra BC unit 48 may calculate rate-distortion values ​​using the rate-distortion analysis for the various tested intra prediction modes, and select the intra prediction mode with the best rate-distortion characteristics among the tested modes as the appropriate intra prediction mode to use. The rate-distortion analysis generally determines the amount of distortion (or error) between a coded block and the original uncoded block that was coded to create the coded block, and the bitrate (i.e., number of bits) used to create the coded block. Intra BC unit 48 may calculate ratios from the distortions and rates of the various coded blocks to determine which intra-prediction mode exhibits the best rate-distortion value for the block.

[0217] In other examples, intra BC unit 48 may use all or a portion of motion estimation unit 42 and motion compensation unit 44 to perform such functions for intra BC prediction according to implementations described herein. In either case, for intra block copying, the predictive block may be a block that is deemed to closely match the block to be coded, in terms of pixel differences, which may be determined by SAD, SSD, or other difference metric, and identification of the predictive block may include calculation of values ​​of sub-integer pixel positions.

[0218] Whether the predictive block is a block from the same frame according to intra prediction or a block from a different frame according to inter prediction, video encoder 20 may form a residual video block by subtracting pixel values ​​of the predictive block from pixel values ​​of the current video block being encoded to form pixel difference values. The pixel difference values ​​that form the residual video block may include both luma and chroma component differences.

[0219] Intra-prediction processing unit 46 may intra-predict the current video block as an alternative to inter-prediction performed by motion estimation unit 42 and motion compensation unit 44, or as an alternative to intra-block copy prediction performed by intra BC unit 48, as described above. Specifically, intra-prediction processing unit 46 may determine an intra-prediction mode to use to encode the current block. To do so, intra-prediction processing unit 46 may encode the current block using various intra-prediction modes, e.g., during separate encoding passes, and intra-prediction processing unit 46 (or, in some examples, a mode selection unit) may select an appropriate intra-prediction mode to use from the tested intra-prediction modes. Intra-prediction processing unit 46 may provide information indicating the selected intra-prediction mode for the block to entropy encoding unit 56. Entropy encoding unit 56 may encode the information indicating the selected intra-prediction mode into the bitstream.

[0220] After prediction processing unit 41 determines the predictive block for the current video block by inter- or intra-prediction, 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, which may be included in one or more TUs, is provided to transform processing unit 52. Transform processing unit 52 converts the residual video data into residual transform coefficients using a transform, such as a Discrete Cosine Transform (DCT) or a conceptually similar transform.

[0221] Transform processing unit 52 may send the resulting transform coefficients to quantization unit 54, which quantizes the transform coefficients to further reduce the bit rate. The quantization process may also reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting a quantization parameter. In some examples, quantization unit 54 may then perform a scan of a matrix containing the quantized transform coefficients. Alternatively, entropy encoding unit 56 may perform the scan.

[0222] Following quantization, entropy encoding 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 Entropy (PIPE) encoding, or another entropy encoding methodology or technique. The encoded bitstream may then be transmitted to video decoder 30 as shown in FIG. 13 or archived to storage device 32 as shown in FIG. 13 for later transmission to or retrieval by video decoder 30. Entropy encoding unit 56 may also entropy encode motion vectors and other syntax elements of the current video frame being encoded.

[0223] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain to generate reference blocks for prediction of other video blocks. As described above, motion compensation unit 44 may generate motion compensated prediction blocks from one or more reference blocks of frames stored in DPB 64. Motion compensation unit 44 may also apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values ​​for use in motion estimation.

[0224] Summer 62 may add the reconstructed residual block to the motion compensated predictive block created by motion compensation unit 44 to create a reference block for storage in DPB 64. The reference block may then be used by intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 as a predictive block to inter predict another video block in a subsequent video frame.

[0225] FIG. 15 is a block diagram illustrating an example 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, an adder 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 may perform a decoding process that is generally inverse to the encoding process described above for the video encoder 20 in connection with FIG. 14. For example, the motion compensation unit 82 may generate prediction data based on a motion vector received from the entropy decoding unit 80, while the intra prediction unit 84 may generate prediction data based on an intra prediction mode indicator received from the entropy decoding unit 80.

[0226] In some examples, the units of the video decoder 30 may be assigned tasks of performing implementations of the present application. Also, in some examples, implementations of the present disclosure may be divided among one or more of the units of the video decoder 30. For example, the intra BC unit 85 may perform implementations of the present 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 BC unit 85, and the functions of the intra BC unit 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82.

[0227] Video data memory 79 may store video data, such as an encoded video bitstream, to be decoded by other components of video decoder 30. The video data stored in video data memory 79 may be obtained, for example, from storage device 32, from a local video source such as a camera, via wired or wireless network communication of video data, or by accessing a physical data storage medium (e.g., a flash drive or hard disk). Video data memory 79 may include a Coded Picture Buffer (CPB) that stores encoded video data from the encoded video bitstream. DPB 92 of video decoder 30 stores reference video data for use in decoding video data by video decoder 30 (e.g., in an intra-predictive coding mode or an inter-predictive coding mode). Video data memory 79 and DPB 92 may be formed by 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. 15, for purposes of illustration, video data memory 79 and DPB 92 are depicted as two separate components of video decoder 30. However, it will be apparent to one skilled in the art that video data memory 79 and DPB 92 may be provided by the same memory device or separate memory devices. In some examples, video data memory 79 may be on-chip with other components of video decoder 30 or off-chip relative to those components.

[0228] During the decoding process, video decoder 30 receives an encoded video bitstream representing video blocks and associated syntax elements of encoded video frames. Video decoder 30 may receive the syntax elements at the video frame level and / or the video block level. 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. Entropy decoding unit 80 then forwards the motion vectors or intra-prediction mode indicators and other syntax elements to prediction processing unit 81.

[0229] When a video frame is coded as an intra-predictive coded (I) frame or for intra-coded predictive blocks in other types of frames, intra prediction unit 84 of prediction processing unit 81 may generate predictive data for video blocks of the current video frame based on a signaled intra-prediction mode and reference data from previously decoded blocks of the current frame.

[0230] When a video frame is coded as an inter-predictive (i.e., B or P) frame, motion compensation unit 82 of prediction processing unit 81 may generate one or more predictive blocks of a video block of the current video frame based on the motion vectors and other syntax elements received from entropy decoding unit 80. Each of the predictive blocks may be created from a reference frame in one of the reference frame lists. Video decoder 30 may construct the reference frame lists, List 0 and List 1, using a default construction technique based on the reference frames stored in DPB 92.

[0231] In some examples, when a video block is encoded according to the intra BC modes described herein, intra BC unit 85 of prediction processing unit 81 creates a predictive block of the current video block based on the block vectors and other syntax elements received from entropy decoding unit 80. The predictive block may be within the same reconstructed region of the picture as the current video block defined by video encoder 20.

[0232] Motion compensation unit 82 and / or intra BC unit 85 determine prediction information for video blocks of the current video frame by analyzing the motion vectors and other syntax elements, and then use the prediction information to create a predictive block for the current video block being decoded. For example, motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra prediction or inter prediction) used to encode the 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 of the frame, a motion vector for each inter predictive coded video block of the frame, an inter prediction status for each inter predictive coded video block of the frame, and other information for decoding video blocks in the current video frame.

[0233] Similarly, intra BC unit 85 may use some of the received syntax elements, such as flags, to determine that the current video block was predicted using intra BC mode, construction information regarding which video blocks of the frame are within the reconstruction region and which video blocks should be stored in DPB 92, 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 for decoding video blocks in the current video frame.

[0234] Motion compensation unit 82 may also perform interpolation using an interpolation filter used by video encoder 20 during encoding of the video block to calculate sub-integer pixel interpolated values ​​of the reference block. In this case, motion compensation unit 82 may determine the interpolation filter used by video encoder 20 from the received syntax element and use the interpolation filter to create the predictive block.

[0235] Inverse quantization unit 86 inverse quantizes the quantized transform coefficients provided in the bitstream and entropy decoded by entropy decoding unit 80, using the same quantization parameters calculated by video encoder 20 for each video block in a video frame to determine the degree of quantization. Inverse transform processing unit 88 applies an inverse transform, e.g., an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process, to the transform coefficients in order to reconstruct residual blocks in the pixel domain.

[0236] After motion compensation unit 82 or intra BC unit 85 generates a predictive block for the current video block based on the vectors and other syntax elements, summer 90 reconstructs a decoded video block for the current video block by adding the residual block from inverse transform processing unit 88 and the corresponding predictive block generated by motion compensation unit 82 and intra BC unit 85. An in-loop filter 91, such as a deblocking filter, an SAO filter, and / or an ALF, may be disposed between summer 90 and DPB 92 to further process the decoded video block. In some examples, in-loop filter 91 may be omitted and the decoded video block may be provided directly to DPB 92 by summer 90. The decoded video block in a given frame is then stored in DPB 92, which stores reference frames used for subsequent motion compensation of the next video block. DPB 92, or a memory device separate from DPB 92, may also store the decoded video for later presentation on a display device, such as display device 34 of FIG. 13.

[0237] The description of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limiting of the disclosure. Many modifications, variations and alternative implementations will become apparent to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings.

[0238] The examples have been chosen and described to explain the principles of the disclosure and to enable those skilled in the art to understand the disclosure in its various embodiments and to best utilize the underlying principles and various implementations with various modifications suited to the particular applications contemplated. Thus, it should be understood that the scope of the disclosure is not limited to the particular examples of implementations disclosed, and that modifications and other implementations are intended to be included within the scope of the disclosure.

Claims

1. 1. A method for video decoding, comprising: determining, by a decoder, a coding bit depth value; determining, by the decoder, a value of a first sequence parameter set (SPS) flag, the first SPS flag being a transform skip enable flag; determining, by the decoder, a second SPS flag based on the value of the first SPS flag and the coded bit depth value; A method comprising:

2. determining the second SPS flag based on the value of the first SPS flag and the value of the coding bit depth; 2. The method for video decoding of claim 1 comprising: determining the presence of the second SPS flag based on a value of the first SPS flag and a value of the encoded bit depth.

3. determining the second SPS flag based on the value of the first SPS flag and the value of the coding bit depth; 2. The method for video decoding of claim 1 comprising: determining a value of the second SPS flag based on the value of the first SPS flag and the value of the coded bit depth.

4. determining a value of the second SPS flag based on at least one of the value of the first SPS flag and the value of the coding bit depth; 4. The method for video decoding of claim 3, comprising: in response to determining that the value of the first SPS flag is equal to 0 and the value of the encoded bit depth is greater than 10, determining that the value of the second SPS flag is equal to 0.

5. 2. The method for video decoding of claim 1, further comprising: determining, in response to determining that the value of the second SPS flag is equal to 1, that information of an SH transform skip residual coding Rice index may be present in a slice header (SH) syntax structure that references the SPS.

6. determining a presence of the second SPS flag based on the value of the first SPS flag and the value of the coding bit depth; 3. The method for video decoding of claim 2, comprising: determining that the second SPS flag is present in response to determining that the value of the first SPS flag is equal to 1 and the value of the encoded bit depth is greater than 10.

7. 1. An apparatus for video decoding, comprising: one or more processors; a memory configured to store instructions executable by the one or more processors; 7. Apparatus, wherein the one or more processors are configured to perform the method of any of claims 1 to 6 upon execution of the instructions.

8. 1. A non-transitory computer-readable storage medium for video decoding, comprising: A non-transitory computer readable storage medium storing computer executable instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method of any of claims 1 to 6.

9. 7. A computer program comprising instructions for execution by a computing device having one or more processors, the instructions, when executed by the one or more processors, causing the computing device to perform a method according to any of claims 1 to 6.

10. 1. A method for storing a bitstream, comprising the steps of: performing an encoding method to generate a bitstream; storing the bitstream in a computer readable storage medium; The encoding method comprises: signaling a parameter for determining an encoding bit depth value; signaling a value of a first sequence parameter set (SPS) flag, the first SPS flag being a transform skip enable flag; setting a second SPS flag based on the value of the first SPS flag and the value of the coding bit depth; A method comprising the steps of:

Images