Encoding of residuals and coefficients for video coding

Abstract

To provide a method, an apparatus, and a non-transitory computer-readable storage medium for improving and simplifying residual and coefficient coding in video coding.SOLUTION: A method includes signaling parameters for determining a coding bit depth value, signaling a first sequence parameter set (SPS) flag that is a transform skip enable flag, and setting a second SPS flag on the basis of the value of the first SPS flag and the coding bit depth value.SELECTED DRAWING: Figure 22

Description

[Technical Field]

[0001] Cross-reference of related applications This application claims priority to Provisional Application No. 63 / 220,380, filed on 9 July 2021, which in its entirety is incorporated herein by reference for any purpose.

[0002] This disclosure relates to video encoding and compression. More specifically, this disclosure relates to improvements and simplifications of 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 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 similar. Video coding generally utilizes prediction methods (e.g., interpretation, intrapretation, or similar) that leverage the redundancy present in the moving image or sequence. A key goal of video coding techniques is to compress video data into a format that uses a lower bit rate while avoiding or minimizing a loss of video quality. [Overview of the project] [Problems that the invention aims to solve]

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

[0005] A method for video decoding is provided according to this disclosure. The method may include: a decoder determining the encoded bit depth of at least one sample in a bitstream; a decoder determining the value of a first SPS flag for at least one sample; and a decoder determining a second SPS flag for at least one sample based on the value of the first SPS flag, combining the encoded bit depths of at least one sample.

[0006] Please understand that the above general description and the following detailed description are illustrative and explanatory only and are not intended to limit this disclosure.

[0007] The accompanying drawings incorporated herein and constituting part of herein illustrate examples in accordance with this disclosure and serve to explain the principles of this disclosure together with the descriptions. [Brief explanation of the drawing]

[0008] [Figure 1] This is a block diagram of an encoder relating to an example of this disclosure. [Figure 2] This is a block diagram of a decoder relating to an example of this disclosure. [Figure 3A] This figure shows the block divisions in a polymorphic tree structure as an example of this disclosure. [Figure 3B] This figure shows the block divisions in a polymorphic tree structure as an example of this disclosure. [Figure 3C] This figure shows the block divisions in a polymorphic tree structure as an example of this disclosure. [Figure 3D] This figure shows the block divisions in a polymorphic tree structure as an example of this disclosure. [Figure 3E] This figure shows the block divisions in a polymorphic tree structure as an example of this disclosure. [Figure 4]A diagram of the residual coding structure of a conversion block according to an example of the present disclosure. [Figure 5] A diagram of the residual coding structure of a conversion skip block according to an example of the present disclosure. [Figure 6] A diagram showing a method for encoding a video signal according to an example of the present disclosure. [Figure 7] A diagram showing a method for encoding a video signal according to an example of the present disclosure. [Figure 8] A diagram showing a computing environment coupled with a user interface according to an example of the present disclosure. [Figure 9] A diagram showing a method for video encoding according to an example of the present disclosure. [Figure 10] A diagram showing a method for video encoding according to an example of the present disclosure. [Figure 11] A diagram showing a method for video encoding according to an example of the present disclosure. [Figure 12] A diagram showing a method for video encoding according to an example of the present disclosure. [Figure 13] A block diagram showing an exemplary system for encoding and decoding a video block according to an example of the present disclosure. [Figure 14] A block diagram showing an exemplary video encoder according to an example of the present disclosure. [Figure 15] A block diagram showing an exemplary video decoder according to an example of the present disclosure. [Figure 16] A diagram showing a low-delay transform skip residual coding (TSRC) method according to an example of the present disclosure. [Figure 17] A diagram showing a method for video decoding according to an example of the present disclosure. [Figure 18] A diagram showing a method for video decoding according to an example of the present disclosure. [Figure 19] A diagram showing a method for video decoding according to an example of the present disclosure. [Figure 20]This figure shows a method for video decoding according to an example of the disclosure. [Figure 21] This figure shows a method for video decoding according to an example of the disclosure. [Figure 22] This figure shows a method for video decoding according to an example of the disclosure. [Modes for carrying out the invention]

[0009] Next, exemplary embodiments will be referenced in detail, examples of which are shown in the accompanying drawings. The following description refers to the accompanying drawings, and unless otherwise noted, the same numbers in different drawings represent the same or similar elements. The implementations described below in the description of exemplary embodiments do not represent all implementations in accordance with this disclosure. Rather, they are merely examples of apparatus and methods in accordance with the aspects relating to this disclosure described in the accompanying claims.

[0010] The terms used in this disclosure are for the sole purpose of describing specific embodiments and are not intended to limit this disclosure. The singular forms “a,” “an,” and “the” are intended to include the plural forms when used in this disclosure and the appended claims, unless the context clearly indicates otherwise. It should also be understood that the terms “and / or” as used herein are intended to mean, and include, any or all possible combinations of one or more of the related enumerated items.

[0011] In this specification, terms such as “first,” “second,” and “third” may be used to describe various types of information, but it should be understood that these terms should not limit the information. These terms are used solely to distinguish one category of information from another. For example, without departing from the scope of this disclosure, first information may be referred to as second information, and similarly, second information may be referred to as first information. When used herein, the term “case” may be understood, depending on the context, to mean “when,” “on the occasion of,” or “depending on judgment.”

[0012] Figure 1 shows a schematic diagram of a block-based video encoder for VVC. Specifically, Figure 1 shows a typical encoder 100. The encoder 100 has a video input 110, motion compensation 112, motion estimation 114, intra / inter-mode determination 116, block predictor 140, adder 128, transform 130, quantization 132, predict-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, video frames are divided into multiple video blocks for processing. For each given video block, a prediction is formed based on either an interpretation method or an intrapretation method.

[0014] A prediction residual, representing the difference between the current video block, which is part of the video input 110, and its predictor, which is part of the block predictor 140, is sent from the adder 128 to the transform 130. Then, for entropy reduction, the transform coefficients are sent from the transform 130 to the quantizer 132. The quantized coefficients are then fed to the entropy code 138 to produce a compressed video bitstream. Prediction-related information 142 from the intra / inter-mode determination 116, such as video block segmentation information, motion vectors (MV), reference picture index, and intra-prediction mode, is also fed via the entropy code 138 and stored in the compressed bitstream 144. The compressed bitstream 144 contains the video bitstream.

[0015] Encoder 100 also requires decoder-related circuitry to reconstruct pixels for prediction purposes. First, the prediction residuals are reconstructed through inverse quantization 134 and inverse transform 136. These reconstructed prediction residuals are combined with block predictor 140 to generate unfiltered reconstructed pixels of the current video block.

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

[0017] Time prediction (also called "interpretation") predicts the current video block using reconstructed pixels from an already encoded video picture. Time prediction reduces the temporal redundancy inherent in video signals. The time prediction signal for a given coding unit (CU) or coding block is typically signaled by one or more MVs indicating the amount and direction of movement between the current CU and its time reference. In addition, one reference picture index is sent, which is used to identify which reference picture in reference picture storage the time prediction signal is coming from.

[0018] The motion estimation unit 114 takes in signals from the video input 110 and the picture buffer 120 and outputs the motion estimation signal to the motion compensation unit 112. The motion compensation unit 112 takes in signals from the video input 110, the picture buffer 120, and the motion estimation signal from the motion estimation unit 114 and outputs the motion compensation signal to the intra / inter-mode determination unit 116.

[0019] After spatial and / or temporal predictions are performed, an intra / inter mode determination 116 in the encoder 100 selects the best prediction mode, for example, based on a rate-distortion optimization method. The block predictor 140 is then subtracted from the current video block, and the resulting prediction residual is decorrelated using a transform 130 and quantization 132. The resulting quantized residual coefficient is inversely quantized by inverse quantization 134 and inversely transformed by inverse transform 136 to form a reconstructed residual, which is then added back to the prediction block to form the reconstructed signal of the CU. Before the reconstructed CU is placed into the reference picture storage of the picture buffer 120 and used to encode future video blocks, further in-loop filtering 122, such as an unblock filter, sample-adaptive offset (SAO), and / or adaptive in-loop filter (ALF), may be applied to the reconstructed CU. To form the output video bitstream 144, the encoding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy encoding unit 138, where they are further compressed and packed 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 units (CUs)). In VTM-1.0, a CU may be up to 128 × 128 pixels. However, unlike HEVC, which partitions blocks based solely on quadtrees, VVC decomposes a single coding tree unit (CTU) into CUs to adapt to various local characteristics based on quadtrees / binary trees / ternary trees. By definition, a coding tree block (CTB) is a sample of N × N blocks, where N is a certain value, and consequently, the partitioning of components into CTBs is partitioning. A CTU may include a CTB of luminance samples, two corresponding CTBs of saturation samples of a picture with a three-sample array, or a CTB of samples of a picture encoded using a syntactic structure used to encode a monochrome picture or three separate color planes and samples. Furthermore, the concept of multiple partitioning unit types in HEVC is eliminated; that is, in VVC, the separation of CU, Prediction Unit (PU), and Transformation Unit (TU) no longer exists, and instead, each CU is always used as the basic unit for both prediction and transformation without further partitioning. In polymorphic tree structures, first, one CTU is partitioned by a quadtree structure. Then, each quadtree leaf node can be further partitioned by binary and ternary tree structures. As shown in Figures 3A, 3B, 3C, 3D, and 3E, there are five decomposition types: quadration, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning.

[0021] Figure 3A shows a diagram illustrating the block quartion in a polymorphic tree structure according to this disclosure.

[0022] Figure 3B shows a diagram illustrating the vertical bisection of a block in a polymorphic tree structure according to this disclosure.

[0023] Figure 3C shows a diagram illustrating the horizontal division of a block in a polymorphic tree structure according to this disclosure.

[0024] Figure 3D shows a diagram illustrating the vertical three-part division of a block in a polymorphic tree structure according to this disclosure.

[0025] Figure 3E shows a diagram illustrating the horizontal division of a block into three parts in a polymorphic tree structure according to this disclosure.

[0026] In Figure 1, spatial and / or temporal prediction may be performed. Spatial prediction (or “intra prediction”) predicts the current video block using pixels from already encoded adjacent block samples (called reference samples) within the same video picture / slice. Spatial prediction reduces the spatial redundancy inherent in the video signal. Temporal prediction (also called “inter prediction” or “motion-compensated prediction”) predicts the current video block using reconstructed pixels from already encoded video pictures. Temporal prediction reduces the temporal redundancy inherent in the video signal. The temporal prediction signal for a given CU is typically signaled by one or more motion vectors (MVs) indicating the amount and direction of motion between the current CU and its temporal reference. Additionally, if multiple reference pictures are supported, one reference picture index is sent, used to identify which reference picture in the reference picture store the temporal prediction signal is coming from. After spatial and / or temporal prediction, a mode determination block within the encoder selects the best prediction mode, for example, based on a rate-distortion optimization method. Next, the predicted block is subtracted from the current video block, and the predicted residual is decorrelated and quantized using a transform. The quantized residual coefficients are inversely quantized and inversely transformed to form the reconstructed residual, which is then added back to the predicted block to form the reconstructed signal of the CU. Before the reconstructed CU is placed in the reference picture store and used to encode future video blocks, further in-loop filtering such as deblocking filters, sample-adaptive offsets (SAO), and adaptive in-loop filters (ALF) may be applied to the reconstructed CU. To form the output video bitstream, the encoding mode (inter or intra), predicted mode information, motion information, and quantized residual coefficients are all sent to an entropy encoding unit, where they are further compressed and packed to form the bitstream.

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

[0028] Decoder 200 is similar to the reconstruction-related section present in encoder 100 in Figure 1. In 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 reconstructed prediction residuals. A block predictor mechanism implemented in intra / inter-mode selector 220 is configured to perform either intra-prediction 222 or motion compensation 224 based on the decoded prediction information. An unfiltered reconstructed set of pixels is obtained by summing the reconstructed prediction residuals from the inverse transform 216 with the prediction output generated by the block predictor mechanism using adder 218.

[0029] The reconstructed blocks may pass through an in-loop filter 228 before being stored in a picture buffer 226, which functions as a reference picture store. The reconstructed video in the picture buffer 226 is sent to drive the display device and may also be used to predict future video blocks. When the in-loop filter 228 is on, filtering operations are performed on these reconstructed pixels to derive the final reconstructed video output 232.

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

[0031] Transformation coefficient coding in VVC In VVC coefficient coding, the variable remBinsPass1 is initially set to the maximum number of context-coded bins (MCCB). During the coding process, the variable is decremented by 1 each time a context-coded bin is transmitted. While remBinsPass1 is 4 or greater, the coefficients are first transmitted through the syntax of sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag, all of which use context-coded bins in the first pass. The remaining level information of the coefficients is coded in the second pass using Golomb-Rice coding and bypass-coded bins with the syntax elements of abs_remainder. When remBinsPass1 becomes less than 4 while encoding the first pass, the current coefficients are not encoded in the first pass, but are directly encoded in the second pass using the syntactic elements of dec_abs_level with Golomb-Rice coding and bypass coding bins. The Rice parameter derivation process for dec_abs_level[] is derived as specified in Table 1A. After encoding all the levels described above, finally, the sign (sign_flag) of all scan positions where sig_coeff_flag is equal to 1 is encoded as a bypass bin. Such a process is illustrated in Figure 4. remBinsPass1 is reset per 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 coefficient subblocks, if remBinsPass1 is less than 4 before encoding the first coefficient, the entire coefficient subblock is encoded using the bypass encoding bin.

[0032] Figure 4 shows the residual coding structure of the transformation block. [Table 1] [Table 2]

[0033] Residual coding of conversion skip mode in VVC In transformation-skip mode, the statistical characteristics of the residual signal differ from those of the transformation coefficients, and no energy compression around low-frequency components is observed. Residual coding is modified to account for the various signal characteristics of the (spatial) transformation-skip residuals.

[0034] Figure 5 shows the residual coding structure of the transform skip block.

[0035] General constraint information The GCI structure includes several types of constraint syntax elements, including flags for general bitstream restrictions indicating that only intra-coding is used, all layers are coded independently, or the bitstream contains only one AU; fields that restrict the bit depth and saturation format of the coded picture; flags indicating that certain NAL unit types cannot exist in the bitstream; flags that restrict how a picture can be partitioned into slices, tiles, and subpictures in the bitstream; flags that restrict the size of the CTU, as well as 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 restrict transform, quantize, and residual coding tools; and flags that restrict the form of the in-loop filter.

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

[0037] Residual coding of conversion skip According to one or more examples of this disclosure, it is proposed to use a variable set of binary code words to encode a particular syntactic element, e.g., abs_remainder, in transform skip residual coding, and the selection result is determined according to specific encoded information of the current block, e.g., TB / CB and / or quantization parameters or coding bit depth associated with slice / profile, and / or 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 code words, 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 used, 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 be implemented in different ways in practice. 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 a truncated binary (TB) binarization process.

[0042] Fifth, it is a 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 changes from the VVC draft indicated in bold italics in Table 1, and deleted content indicated in italics. It is worth noting that the same logic may actually 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, it is proposed that when a new flag, such as extended_precision_processing_flag, is equal to 1, only one fixed value should be used for the Rice parameter when encoding the syntactic elements of abs_remainder. The corresponding decoding process based on the VVC draft is shown below, with changes indicated in bold italics and deletions indicated in italics. Changes from the VVC draft are shown in bold italics in Table 2. [Table 4]

[0046] In yet another example, when a new flag, such as 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 differ under different conditions. An example of the corresponding decoding process based on the VVC draft is shown below, with changes indicated in bold italics and deletions in italics. Changes from the VVC draft are shown in bold italics in Table 3. [Table 5]

[0047] In yet another example, when BitDepth is greater than or equal to 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 differ under different conditions. An example of the 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), changes are shown in bold italics, and deleted content is shown in italics. Changes from the VVC draft are shown in bold italics in Table 4. [Table 6]

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

[0049] Slice header syntax [Table 7]

[0050] A value of 1 for sh_ts_residual_coding_rice_flag indicates that sh_ts_residual_coding_rice_index may exist in the current slice. A value of 0 for sh_ts_residual_coding_rice_flag indicates that sh_ts_residual_coding_rice_index does not exist in the current slice. When sh_ts_residual_coding_rice_flag does not exist, its value is inferred to be equal to 0. sh_ts_residual_coding_rice_index specifies the rice parameter used in the residual_ts_coding() syntax structure. [Table 8]

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

[0052] Sequence parameter set RBSP syntax [Table 9]

[0053] A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 indicates that sh_ts_residual_coding_rice_idx may exist within an SH syntactic structure referencing an SPS. A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 indicates that sh_ts_residual_coding_rice_idx does not exist within an SH syntactic structure referencing an SPS. When sps_ts_residual_coding_rice_present_in_sh_flag does not exist, its value 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 this disclosure, it is proposed to disable the existence of a rice parameter for transform-skip residual coding when transform skipping is disabled. In a specific example, it is proposed to use sps_transform_skip_enabled_flag to condition the existence of sps_ts_residual_coding_rice_present_in_sh_flag in order to achieve such a design objective. For example, when the flag sps_transform_skip_enabled_flag is equal to 0 (i.e., when transform skipping is disabled in the current picture), sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be 0 rather than 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, it is proposed to add a bitstream compliance requirement related to sps_transform_skip_enabled_flag for sps_ts_residual_coding_rice_present_in_sh_flag in order to achieve such a design objective. For example, the bitstream compliance requirement is 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. Changes to the current VVC working draft are shown in italics below.

[0058] Semantics of Sequence Parameter Set Range Extension A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 indicates that sh_ts_residual_coding_rice_idx_minus1 may exist within a slice_header() syntax structure that references an SPS. A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 indicates that sh_ts_residual_coding_rice_idx_minus1 does not exist within a slice_header() syntax structure that references an SPS. When sps_ts_residual_coding_rice_present_in_sh_flag does not exist, its value is inferred to be equal to 0.

[0059] A bitstream compliance requirement is that when sps_transform_skip_enabled_flag is equal to 0, the value of sps_ts_residual_coding_rice_present_in_sh_flag must also be 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 signaling of the rice parameter of the transform skip block is enabled or disabled. When the control flag is signaled as enabled, one syntactic 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 (for example, set to equal to "0"), no further syntactic elements are signaled at a lower level to indicate the rice parameter of the transform skip slice, and the default rice parameter (for example, 1) is used for all transform skip slices. An example of the corresponding decoding process based on the VVC draft is shown below. Changes from the VVC draft are shown in italics.

[0061] [Table 13]

[0062] A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 1 indicates that sh_ts_residual_coding_rice_idx may exist within an SH syntactic structure referencing an SPS. A value of sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 indicates that sh_ts_residual_coding_rice_idx_minus1 does not exist within an SH syntactic structure referencing an SPS. When sps_ts_residual_coding_rice_present_in_sh_flag does not exist, its value 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 structure. If sh_ts_residual_coding_rice_idx_minus1 does not exist, its value is inferred to be equal to 0.

[0065] 9.3.3.11 Binarization process of abs_remainder[] The input to this process is a request to find the binarization of the following: the syntax element abs_remainder[n], the color component cIdx, the current subblock index i, the luminance position (x0, y0) which specifies the top-left sample of the current luminance transformation block relative to the top-left luminance sample of the picture, the current coefficient scan position (xC, yC), the binary logarithm of the transformation block width log2TbWidth, and the binary logarithm of the transformation block height log2TbHeight.

[0066] The output of this process is the binarization of syntactic 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, both lastAbsRemainder and lastRiceParam are set to equal to 0.

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

[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 to be equal to sh_ts_residual_coding_rice_idx_minus1+1.

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

[0073] In yet another example, one syntactic element is signaled for each conversion 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. Changes from the VVC draft are shown in bold italics in Table 10. It is worth noting that sh_ts_residual_coding_rice_idx can be encoded in various ways and / or may have a maximum value. For example, to encode / decode the same syntactic element, one may also use u(n), which is an unsigned integer using n bits, or f(n), which is a fixed pattern bit sequence using n bits, with the left bit written first (from left to right).

[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 does not exist, its value is inferred to be equal to 0. [Table 16]

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

[0077] Picture parameter set range extension syntax [Table 17]

[0078] A value of pps_ts_residual_coding_rice_flag equal to 1 indicates that pps_ts_residual_coding_rice_index may exist in the current picture. A value of pps_ts_residual_coding_rice_flag equal to 0 indicates that pps_ts_residual_coding_rice_idx does not exist in the current picture. When pps_ts_residual_coding_rice_flag does not exist, its value 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 encoding the syntactic element abs_remainder. The values ​​of the Rice parameters to be applied may be determined according to specific encoded information of the current block, such as block size, quantization parameters, bit depth, and transformation type. In one particular embodiment, it is proposed to adjust the Rice parameters based on the encoded bit depth and the quantization parameters applied to one CU. The corresponding decoding process based on the VVC draft is shown below, with changes from the VVC draft indicated in bold italics in Table 14, and deleted content indicated in italics. It is worth noting that in practice the same logic may be implemented in different ways. For example, specific equations or lookup tables may also be used to derive the same Rice parameters. [Table 19] JPEG0007839925000020.jpg69167

[0081] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined threshold (e.g., 33 or 34). Changes from the VVC draft are shown in bold italics in Table 15, and deleted content is shown in italics. It is worth noting that the same logic can actually 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 decryption process based on the VVC draft is shown below: A and TH B This is a predetermined threshold (for example, TH A =8, TH B (=33 or 34). Changes to the VVC draft are shown in bold italics in Table 16, and deleted content is shown in italics. It is worth noting that the same logic may actually be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 21]

[0083] In yet another example, it is proposed that when a new flag, e.g., extended_precision_processing_flag, is equal to 1, only a variable Rice parameter is used to encode the syntactic elements of abs_remainder. The variable value may be determined according to specific encoded information of the current block, e.g., block size, quantization parameters, bit depth, transformation type, etc. In one particular embodiment, it is proposed to adjust the Rice parameter based on the encoded bit depth and the quantization parameters applied to one CU. The corresponding decoding process based on the VVC draft is shown below. Changes from the VVC draft are shown in bold italics in Table 17. It is worth noting that the same logic may actually be implemented in different ways. For example, specific equations or lookup tables 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 predetermined threshold (e.g., 18, 19). Changes from the VVC draft are shown in bold italics in Table 18. It is worth noting that the same logic can actually 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 decryption process based on the VVC draft is shown below: A and TH B This is a predetermined threshold (for example, TH A =8, TH B(=18 or 19). Changes to the VVC draft are shown in bold italics in Table 19. It is worth noting that the same logic may actually be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 24]

[0086] Figure 6 shows a method for video encoding. The method may be applied to an encoder, for example. 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 quantization parameters based on the video input. The quantization parameters may be calculated, for example, by a quantization unit within the encoder. In step 1614, the encoder may derive RICE parameters based on at least one predetermined threshold, encoding bit depth, and quantization parameters. The RICE parameters are used, for example, to signal the syntax of abs_remainder and dec_abs_level. In step 1616, the encoder may entropi encode the video bitstream based on the RICE parameters. The video bitstream may be entropi encoded, for example, to produce 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 abs_remainder syntax element. The fixed values may vary under different conditions according to certain encoded information of the current block, e.g., the quantization parameter. The corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined threshold (e.g., 18, 19). The changes to the VVC draft are indicated in Table 20 in bold italic font. It is worth noting that the same logic can actually be implemented in different ways. For example, specific equations or look-up tables 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, where TH A and TH B are predetermined thresholds (e.g., TH A = 8, TH B = 18 or 19). The changes to the VVC draft are indicated in Table 21 in bold italic font. It is worth noting that the same logic can actually be implemented in different ways. For example, specific equations or look-up tables may also be used to derive the same Rice parameter. [Table 26]

[0089] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined threshold (e.g., 33 or 34). The changes to the VVC draft are indicated in Table 22 in bold italic font. It is worth noting that the same logic can actually be implemented in different ways. For example, specific equations or look-up tables may also be used to derive the same Rice parameter. [Table 27]

[0090] In yet another example, the corresponding decryption process based on the VVC draft is shown below: A and TH B This is a predetermined threshold (for example, TH A =8, TH B (=33 or 34). Changes to the VVC draft are shown in bold italics in Table 23. It is worth noting that the same logic can actually be implemented in different ways. For example, a specific equation or lookup table may also be used to derive the same Rice parameter. [Table 28]

[0091] It is worth noting that in the above example, the equation used to calculate the specific Rice parameter is used only as an example to illustrate the proposed idea. For those skilled in 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 parameters). On the other hand, it should also be noted that current VVC designs allow for variations in the values ​​of the applied quantization parameters at the coded block group level. Thus, the proposed Rice parameter tuning scheme can provide flexible adaptation of the Rice parameter of the transform skip mode at the coded block group level.

[0092] Signal transmission information for normal residual coding and transformation-skip residual coding According to one or more examples of the present disclosure, it is proposed to signal in transform-skip residual coding a specific syntactic element, e.g., a rice parameter of a binary code word for encoding abs_remainder, a shift parameter and an offset parameter for deriving the rice parameter used in abs_remainder / dec_abs_level in normal residual coding, and to determine whether to signal in accordance with specific encoded information of the current block, e.g., quantization parameters or encoded bit depth associated with TB / CB and / or slice / profile, and / or a new flag associated with TB / CB / slice / picture / sequence level, e.g., sps_residual_coding_info_present_in_sh_flag.

[0093] In one example, a control flag is signaled in the slice header to indicate whether signaling of rice parameters for conversion skip blocks, and signaling of shift and / or offset parameters for deriving rice parameters in conversion blocks, is enabled or disabled. When the control flag is signaled as enabled, one more syntactic element is signaled for each conversion skip slice to indicate the rice parameter of that slice, and two more syntactic elements are signaled for each conversion slice to indicate the shift and / or offset parameters for deriving the rice parameter of that slice. When the control flag is signaled as disabled (for example, set to "0"), no further syntactic elements are signaled at a lower level to indicate the rice parameter of a conversion skip slice, and the default rice parameter (e.g., 1) is used for all conversion skip slices; and no further syntactic elements are signaled at a lower level to indicate the shift and / or offset parameters for deriving the rice parameter of a conversion slice, and the default shift and / or offset parameters (e.g., 0) are used for all conversion slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined value (e.g., 0, 1, 2). Changes from the VVC draft are shown in bold italics 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 encoded in various ways and / or may have a maximum value. For example, to encode / decode the same syntactic element, either u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit sequence using n bits, with the left bit written first (from left to right), may be used.

[0094] Figure 7 shows a method for video decoding. The method may be applied, for example, to 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 code word for an encoding syntax element. The encoding syntax element may include an abs_remainder in transform-skip residual coding. In step 1714, the encoder may entropi encode the video bitstream based on the Rice parameter and the video input.

[0095] Slice header syntax [Table 29]

[0096] A value of 1 for sh_residual_coding_rice_flag indicates that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index may exist in the current slice. A value of 0 for sh_residual_coding_rice_flag indicates that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index do not exist 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[]. If sh_residual_coding_rice_shift does not exist, its value 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[]. If sh_residual_coding_rice_offset does not exist, its value 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 structure. If sh_ts_residual_coding_rice_index does not exist, its value is inferred to be equal to 0. [Table 30] [Table 31]

[0100] In another example, a control flag is signaled within the sequence parameter set (or within the sequence parameter set range extension syntax) to indicate whether signaling of rice parameters for transformation skip blocks, and signaling of shift and / or offset parameters for deriving rice parameters in transformation blocks, is enabled or disabled. When the control flag is signaled as enabled, one more syntax element is signaled for each transformation skip slice to indicate the rice parameter for that slice, and two more syntax elements are signaled for each transformation slice to indicate the shift and / or offset parameters for deriving the rice parameter for that slice. When the control flag is signaled as disabled (for example, set to equal to "0"), no further syntax elements are signaled at a lower level to indicate the rice parameter for transformation skip slices, and the default rice parameter (e.g., 1) is used for all transformation skip slices, and no further syntax elements are signaled at a lower level to indicate the shift and / or offset parameters for deriving the rice parameter for transformation slices, and the default shift and / or offset parameters (e.g., 0) are used for all transformation slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined value (e.g., 0, 1, 2). Changes from the VVC draft are shown in bold italics 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 encoded in various ways and / or may have a maximum value. For example, to encode / decode the same syntactic element, either u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit sequence using n bits, with the left bit written first (from left to right), may be used.

[0101] Sequence parameter set RBSP syntax [Table 32]

[0102] A value of sps_residual_coding_info_present_in_sh_flag equal to 1 indicates that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx may exist within an SH syntactic structure referencing an SPS. A value of sps_residual_coding_info_present_in_sh_flag equal to 0 indicates that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx do not exist within an SH syntactic structure referencing an SPS. When sps_residual_coding_info_present_in_sh_flag does not exist, 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[]. If sh_residual_coding_rice_shift does not exist, its value 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[]. If sh_residual_coding_rice_offset does not exist, its value 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 structure. If sh_ts_residual_coding_rice_index does not exist, its value is inferred to be equal to 0. [Table 34] [Table 35]

[0107] In yet another example, one syntactic element is signaled for each conversion skip slice to indicate the rice parameter of that slice, and two syntactic elements are signaled for each conversion slice to indicate the shift and / or offset parameters for the derivation of the rice parameter of that slice. An example of the corresponding decoding process based on the VVC draft is shown below. Changes from the VVC draft are shown in bold italics 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 encoded in various ways and / or may have a maximum value. For example, to encode / decode the same syntactic element, either u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit sequence using n bits, written with the left bit first (from left to right), may also be used.

[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. If sh_ts_residual_coding_rice_idx does not exist, its value 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[]. If sh_residual_coding_rice_offset does not exist, its value 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 structure. If sh_ts_residual_coding_rice_index does not exist, its value is inferred to be equal to 0. [Table 37] [Table 38]

[0112] In yet another example, a control flag is signaled within the picture parameter set range extension syntax to indicate whether signaling of the rice parameter for the transform skip block, and signaling of the shift and / or offset parameters for the derivation of the rice parameter in the transform block, is enabled or disabled. When the control flag is signaled as enabled, one more syntax element is signaled to indicate the rice parameter for the transform skip residual coding of that picture, and two more syntax elements are signaled to indicate the shift and / or offset parameters for the derivation of the rice parameter for that picture for each normal residual coding. When the control flag is signaled as invalid (e.g., set to "0"), no further syntactic elements are signaled at lower levels to indicate the rice parameter for transform-skipped residual coding, and the default rice parameter (e.g., 1) is used for all transform-skipped residual coding. Similarly, no further syntactic elements are signaled at lower levels to indicate the shift and / or offset parameters for the rice parameter derivation of normal residual coding, and the default shift and / or offset parameters (e.g., 0) are used for all normal residual coding. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predetermined value (e.g., 0, 1, 2). Changes from the VVC draft are shown in bold italics 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 encoded in various ways and / or may have a maximum value. For example, to encode / decode the same syntactic elements, one may also use u(n), which is an unsigned integer using n bits, or f(n), which is a fixed pattern bit sequence using n bits, where the left bit is written first (from left to right).

[0113] Picture parameter set range extension syntax [Table 39]

[0114] A value of pps_residual_coding_info_flag equal to 1 indicates that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_index may exist in the current picture. A value of pps_residual_coding_info_flag equal to 0 indicates that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_idx do not exist in the current picture. When pps_residual_coding_info_flag does not exist, its value 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[]. If pps_residual_coding_rice_shift does not exist, its value 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 does not exist, its value 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. If pps_ts_residual_coding_rice_index does not exist, its value is inferred to be equal to 0. [Table 40] [Table 41]

[0118] According to one or more examples of this disclosure, it is proposed to use different Rice parameters for encoding a particular syntactic element, e.g., abs_remainder, in transform-skip residual coding, shift parameters and offset parameters for deriving the Rice parameters used in abs_remainder / dec_abs_level in normal residual coding, and to determine which to use according to specific encoded information of the current block, e.g., quantization parameters or encoded 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., sps_residual_coding_info_present_in_sh_flag.

[0119] In one example, a control flag is signaled within the slice header to indicate whether the process for deriving the rice parameter of a transform skip block and the process for deriving the shift and / or offset parameters of the rice parameter in a transform block are enabled or disabled. When the control flag is signaled as enabled, the rice parameter may differ under different conditions depending on the specific encoded information of the current block, e.g., the quantization parameter and bit depth. Similarly, the shift and / or offset parameters for deriving the rice parameter in normal residual coding may differ under different conditions depending on the specific encoded information of the current block, e.g., the quantization parameter and bit depth. When the control flag is signaled as disabled (e.g., set to "0"), the default rice parameter (e.g., 1) is used for all transform skip slices, and the 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, TH A and TH B This is a predetermined threshold (for example, TH A =8, TH B (=18 or 19). Changes to the VVC draft are shown in bold italics in Table 37. It is worth noting that 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 parameter.

[0120] Slice header syntax [Table 42]

[0121] A value of sh_residual_coding_rice_flag equal to 1 indicates that the bit-depth-dependent rice parameter derivation process will be used for the current slice. A value of sh_residual_coding_rice_flag equal to 0 indicates that the bit-depth-dependent rice parameter derivation process will not be 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 predetermined threshold (e.g., 18, 19). Changes from the VVC draft are shown in bold italics in Table 40. It is worth noting that the same logic can actually 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] JPEG0007839925000047.jpg110167

[0123] According to another aspect of this disclosure, it is proposed to add a constraint that the values ​​of these encoding tools described above are flagged 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 being equal to 1 indicates that sh_ts_residual_coding_rice_idx may exist within an SH syntactic structure referencing an SPS. If sps_ts_residual_coding_rice_present_in_sh_flag being equal to 0 indicates that sh_ts_residual_coding_rice_idx does not exist within an SH syntactic structure referencing an SPS. According to this disclosure, it is proposed to add the syntactic element gci_no_ts_residual_coding_rice_constraint_flag to the general constraint information syntax in order to provide the same general constraint control as other flags. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 46] [Table 47]

[0125] In another example, pps_ts_residual_coding_rice_flag being equal to 1 indicates that pps_ts_residual_coding_rice_index may exist in the current picture. pps_ts_residual_coding_rice_flag being equal to 0 indicates that pps_ts_residual_coding_rice_idx does not exist in the current picture. According to this disclosure, it is proposed to add the syntax element gci_no_ts_residual_coding_rice_constraint_flag to the general constraint information syntax to provide the same general constraint control as the other flags. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 48]

Table 49

[0126] In yet another example, that the sps_rice_adaptation_enabled_flag is equal to 1 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 highlighted in italics.

Table 50

Table 51

[0129] Since the proposed rice parameter adaptation scheme is used only for transform skip residual coding (TSRC), the proposed method can only be effective when TSRC is enabled. Accordingly, in one or more embodiments of the present disclosure, it is proposed to add a 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, for example, when the value of gci_no_transform_skip_constraint_flag is set to 1.

[0130] In yet another example, sps_range_extension_flag being equal to 1 indicates that the sps_range_extension() syntax structure exists within the SPS RBSP syntax structure. sps_range_extension_flag being equal to 0 indicates that this syntax structure does not exist. According to this disclosure, it is proposed to add the syntax element gci_no_range_extension_constraint_flag within the general constraint information syntax to provide the same general constraint control as the other flags. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 52] [Table 53]

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

[0132] In step 1904, the decoder may, in response to the determination that the value of the SPS range extension flag is equal to 1, determine that sps_range_extension exists within the SH RBSP syntax structure.

[0133] In step 1906, the decoder may, in response to the determination that the value of the range extension flag is equal to 0, determine that sps_range_extension does not exist within the SH RBSP syntax structure.

[0134] The sps_cabac_bypass_alignment_enabled_flag specifies that the value of ivlCurrRange may be aligned before bypass decoding of the syntax elements sb_coded_flag[][], abs_remainder[], dec_abs_level[n], and coeff_sign_flag[]. sps_cabac_bypass_alignment_enabled_flag being equal to 0 specifies that the value of ivlCurrRange will not be aligned before bypass decoding. According to this disclosure, it is proposed to add the syntax element gci_no_cabac_bypass_alignment_constraint_flag within the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process for the VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 54] [Table 55]

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

[0136] In step 2004, the decoder may, in response to the determination that the value of the SPS alignment enabled flag is equal to 1, determine that the ivlCurrRange is aligned before bypass decoding.

[0137] In step 2006, the decoder may, in response to the determination that the value of the SPS alignment enabled flag is equal to 0, determine that the ivlCurrRange will not be aligned before bypass decoding.

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

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

[0140] In step 2104, the decoder may, in response to the determination that the value of the extended precision processing flag is equal to 1, determine that the extended dynamic range is adopted for the conversion coefficients and during the conversion process.

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

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

[0143] Figure 12 shows a method for video encoding according to an example of the present disclosure. The method may be applied, for example, to a decoder. In step 2202, the decoder may receive a persistent Rice adaptive enable flag, which indicates whether the Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the start of each subblock that employs mode-dependent statistics accumulated from the previous subblock, based on the value of the persistent Rice adaptive enable flag.

[0144] In step 2204, the decoder may, in response to the determination that the value of the persistent Rice adaptive enable flag is equal to 1, determine that the Rice parameter derivation for binarization is initialized at the beginning of each subblock that employs mode-dependent statistics accumulated from the previous subblock.

[0145] In step 2206, the decoder may, in response to the determination that the value of the persistent Rice adaptation enabled flag is equal to 0, decide not to adopt the previous subblock state in the Rice parameter derivation.

[0146] In yet another example, sps_rrc_rice_extension_flag being equal to 1 indicates that the rice parameter derivation extension for binarization of abs_remainder[] and dec_abs_level[] is enabled. sps_rrc_rice_extension_flag being equal to 0 indicates that the rice parameter derivation extension for binarization of abs_remainder[] and dec_abs_level[] is disabled. According to this disclosure, it is proposed to add the syntax element gci_no_rrc_rice_extension_flag within the general constraint information syntax to provide the same general constraint control as the other flags. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are shown in the following italic font. [Table 60] [Table 61]

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

[0148] In step 2704, the decoder may determine that the extension of the Rice parameter derivation for binarization is valid in response to the determination that the value of the SPS Rice extension flag is equal to 1.

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

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

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

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

[0153] In step 2806, the decoder may, in response to the determination that the value of the SPS Rice Adaptive Enable Flag is equal to 0, decide not to adopt the previous TU state in the Rice parameter derivation.

[0154] In yet another example, sps_reverse_last_sig_coeff_enabled_flag being equal to 1 indicates that sh_reverse_last_sig_coeff_flag exists within the slice_header() syntax structure that references SPS. sps_reverse_last_sig_coeff_enabled_flag being equal to 0 indicates that sh_reverse_last_sig_coeff_flag does not exist within the slice_header() syntax structure that references SPS. According to this disclosure, it is proposed to add the syntax element gci_no_reverse_last_sig_coeff_enabled_flag within the general constraint information syntax to provide the same general constraint control as the other flags. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 64] [Table 65]

[0155] A value of sh_reverse_last_sig_coeff_flag equal to 1 specifies that the coordinates of the final significance coefficient are encoded relative to ((Log2ZoTbWidth<<1)-1,(Log2ZoTbHeight<<1)-1) for each transformation block in the current slice. A value of sh_reverse_last_sig_coeff_flag equal to 0 specifies that the coordinates of the final significance coefficient are encoded relative to (0,0) for each transformation block in the current slice. If it does not exist, the value of sh_reverse_last_sig_coeff_flag is inferred to be equal to 0.

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

[0157] In step 2904, in response to the determination that the value of the SPS inverse coordinate of the last effective coefficient enable flag is equal to 1, the decoder may determine that the SH inverse coordinate of the last effective coefficient enable flag is located within a slice header syntax structure that references SPS.

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

[0159] In yet another example, sps_transform_precision_adaptation_enabled_flag being equal to 1 specifies that downshifts in the scaling of transformation coefficients and the transformation of scaled transformation coefficients are adaptively assigned by checking the coefficient values ​​during inverse quantization and inverse transformation. According to this disclosure, it is proposed to add the syntax element gci_no_transform_precision_adaptation_enabled_flag within the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process for the VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics. [Table 66] [Table 67]

[0160] Figure 20 shows a method for video decoding according to an example of the present disclosure. The method may be applied, for example, to a decoder. In step 3002, the decoder may receive an SPS conversion accuracy adaptive enable flag indicating whether the downshift in the scaling process of the conversion coefficients and the conversion process of the scaled conversion coefficients is adaptively assigned by checking the coefficient values ​​of the inverse quantization and inverse conversion.

[0161] In step 3004, the decoder may, in response to the determination that the value of the SPS conversion accuracy adaptive enable flag is equal to 1, determine that the downshift in the scaling process of the conversion coefficients and the conversion process of the scaled conversion coefficients are adaptively assigned by checking the coefficient values ​​of the inverse quantization and inverse conversion.

[0162] In yet another example, if the sps_high_throughput_flag is equal to 1, it may be determined that all syntax elements in the residual coding except for the position of the last valid coefficient in the RRC are encoded through the bypass mode, and after the position of the last valid coefficient in the RRC and at the beginning of the TB of the TSRC, alignment is only required once. 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_high_throughput_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 68

Table 69

[0163] FIG. 21 shows 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 the syntax elements in the residual coding are encoded through the bypass mode.

[0164] In step 3104, in response to a determination 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 valid coefficient in the normal residual coding (RRC: regular residual coding) are encoded through the bypass mode, and alignment is performed after the position of the last valid coefficient and at the beginning of the transform block (TB) in the transform skip residual coding (TSRC).

[0165] The above methods may be carried out using an apparatus comprising 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 carry out the methods described above. Each module, submodule, unit, or subunit 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 parameters. This multi-pass coding may not be suitable for the design of actual hardware encoders. To solve this problem, low-latency TSRC coding methods are also proposed. According to one or more examples of this disclosure, it is proposed to derive rice parameters according to specific coded information of the current slice, e.g., quantization parameters and / or coding bit depth associated with the slice / picture / sequence, and / or hash ratio associated with the level of the slice / picture / sequence. Various methods may be used to derive rice parameters, and some exemplary methods are listed below. It should be noted that the following methods may be applied individually or in combination.

[0167] 1. The RICE parameters described in the above embodiments may further depend on the video resolution, which includes 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 predetermined region. In a specific example, different Rice values ​​are used for pictures with different time layer IDs (related to nuh_temporal_id_plus1 as 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 predetermined region. For example, Rice parameter = Clip3(1,8,(TH-QP) / 6), where TH is a predetermined threshold (e.g., 18, 19).

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

[0170] 4. Rice parameters for each slice based on the values ​​of abs_remainder encoded in the preceding slice according to the encoding order. In a specific example, after one slice is encoded, the number of bins for binarization of abs_remainder using different rice parameters is calculated, and that number is then used to determine the rice parameters for subsequent slices. For example, the rice parameter that achieves the minimum number of bins in the preceding slice is selected for the current slice. In 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 produced using the default rice parameter (i.e., 1) in the preceding slice 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. Rice parameters for each slice based on the value of abs_remainder encoded in the preceding slice according to the encoding order, the rice parameters may be adjusted according to the change in encoded information between the current slice and the previous slice. In a specific example, for example, the rice parameters that achieve the minimum number of bins in the preceding slice are selected for the current slice. Also, when ΔQ is greater than TH, the rice values ​​may be adjusted, where ΔQ is calculated as abs(QPcurrent-QPprevious) and TH is a predetermined threshold. Rice parameters (e.g., 0, 5). The adjustment may be by adding a predetermined offset (e.g., +1, -1) or by scaling by a predetermined value.

[0172] Bitstream constraints In one or more examples of this disclosure, it is proposed to disable the existence of Rice parameters for transform skip residual coding and high bit-depth tools for low bit-depth coding. In a specific example, to achieve such an objective, 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 being equal to 1 indicates that sh_ts_residual_coding_rice_idx may exist within an SH syntactic structure that references SPS. The changes to the current VVC working draft are as follows:

[0174] When BitDepth is 10 or less, the value of sps_ts_residual_coding_rice_present_in_sh_flag must be equal to 0 for bitstream compliance to be valid.

[0175] In another example, sps_rrc_rice_extension_flag being equal to 1 indicates that the extension of the rice parameter derivation for binarization of abs_remaining[] and dec_abs_level[] is enabled. sps_rrc_rice_extension_flag being equal to 0 indicates 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 from the current VVC working draft are as follows:

[0176] When BitDepth is 10 or less, the value of sps_rrc_rice_extension_flag must be equal to 0 for it to be a bitstream compliant requirement.

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

[0178] When BitDepth is 10 or less, the value of sps_persistent_rice_adaptation_enabled_flag must be equal to 0 for bitstream compliance to be valid.

[0179] In yet another example, sps_reverse_last_sig_coeff_enabled_flag being equal to 1 indicates that sh_reverse_last_sig_coeff_flag exists within the slice_header() syntax structure that references SPS. sps_reverse_last_sig_coeff_enabled_flag being equal to 0 indicates that sh_reverse_last_sig_coeff_flag does not exist within the slice_header() syntax structure that references SPS. According to this disclosure, the changes from the current VVC working draft are as follows:

[0180] A requirement for bitstream compliance is that when BitDepth is 10 or less, the value of sps_reverse_last_sig_coeff_enabled_flag is equal to 0.

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

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

[0183] Furthermore, it is worth mentioning that the proposed bitstream compliance constraint sps_ts_residual_coding_rice_present_in_sh_flag regarding the encoded bit depth is orthogonal to the conditional signaling of the transform skip flag, i.e., the slice-level flag of 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, the compliant bitstream is also applied to require that sps_ts_residual_coding_rice_present_in_sh_flag can only be equal to 1 when the value of the encoded bit depth is greater than 10. The following shows the SPS syntax table and the semantic changes when such a method is applied.

Table 70

[0184] When sps_ts_residual_coding_rice_present_in_sh_flag is equal to 1, it specifies that there may be a sh_ts_residual_coding_rice_idx within the SH syntax structure referring to the SPS. The changes to the current VVC working draft are as follows.

[0185] When BitDepth is 10 or less, the value of sps_ts_residual_coding_rice_present_in_sh_flag must be equal to 0 for bitstream compliance to be valid.

[0186] Figure 22 shows a method for video decoding according to an example of the present disclosure. The method may be applied, for example, to a decoder. In step 3202, the decoder may determine the encoded bit depth of at least one sample in the bitstream. In step 3204, the decoder may determine the value of a first SPS flag for at least one sample. In step 3206, the decoder may determine a second SPS flag for at least one sample based on the value of the first SPS flag in combination with the encoded bit depth of at least one sample. In some examples, the decoder may determine the presence of a second SPS flag based on the first SPS flag, or determine the value of a second SPS flag based on the encoded bit depth. In some examples, the decoder may determine the presence of a second SPS flag based on the first SPS flag and the encoded bit depth. In some examples, the decoder may determine the value of a second SPS flag based on the first SPS flag and the encoded bit depth. In some other examples, the decoder may determine the value of the second SPS flag based on the encoded 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, in such a manner, the value of the sps_ts_residual_coding_rice_present_in_sh_flag flag is signaled only when sps_transform_skip_enabled_flag is equal to 1 and the encoded bit depth is greater than 10, as shown below. [Table 71]

[0188] Figure 16 shows a flowchart of a low-latency transform-skip-residual coding (TSRC) method according to an example of the present disclosure. The method may be applied, for example, to an encoder. In step 2602, the encoder may derive slice parameters based on encoded information of the current slice of video. The encoded information may include one or more of the following parameters: quantization parameters or encoded bit depth associated with a slice, picture, or sequence of video, or hash ratios associated with a slice, picture, or sequence of 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 transmitted to the decoder; the encoder / decoder derives the Rice parameters using the same method.

[0190] Figure 8 shows 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, memory 1840, and an I / O interface 1850.

[0191] The processor 1820 typically controls the overall operation of the computing environment 1810, including 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 above method. Furthermore, 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] Memory 1840 is configured to store various types of data to support the operation of the computing environment 1810. Memory 1840 may include certain software 1842. Examples of such data include instructions for any application or method running on the computing environment 1810, video datasets, image data, etc. Memory 1840 may be implemented using any type of volatile or non-volatile memory device or combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disks, or optical disks.

[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 similar devices. The buttons may include, but are not limited to, a home button, a scan start button, and a scan stop button. The I / O interface 1850 may be coupled with an encoder and a decoder.

[0194] In some embodiments, a non-temporary computer-readable storage medium containing multiple programs, such as those contained in memory 1840, is also provided, which can be executed by a processor 1820 in a computing environment 1810 for performing the above method. For example, the non-temporary computer-readable storage medium may be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, or similar.

[0195] A non-temporary computer-readable storage medium stores multiple programs therein that are executed by a computing device having one or more processors, and when the multiple programs are executed by one or more processors, the computing device performs 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 above-described method.

[0197] Figure 13 is a block diagram illustrating an exemplary system 10 for parallel encoding and decoding of video blocks, according to several implementations of the present disclosure. As shown in Figure 13, system 10 includes a source device 12 that generates and encodes video data to be later decoded by a destination device 14. The source device 12 and destination device 14 may include any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or the like. In some implementations, the source device 12 and destination device 14 have wireless communication capabilities.

[0198] In some implementations, the destination device 14 may receive the encoded video data to be decoded via link 16. 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, link 16 may include a communication medium that allows the source device 12 to directly transmit the encoded video data 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 sent from the output interface 22 to a 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, Blu-ray disc, digital multipurpose disc (DVD), compact disc read-only memory (CD-ROM), flash memory, 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 sending the encoded video data to the destination device 14. An exemplary file server includes a web server (e.g., for a website), a File Transfer Protocol (FTP) server, a Network Attached Storage (NAS) device, or a local disk drive. The destination device 14 may access the encoded video data through any standard data connection, including a wireless channel (e.g., Wireless Fidelity (Wi-Fi) connection), a wired connection (e.g., Digital Subscriber Line (DSL), cable modem, etc.), or a combination of both that is suitable for accessing the encoded video data stored on the file server. Transmission of the encoded video data from the storage device 32 may be streaming transmission, download transmission, or a combination of both.

[0200] As shown in Figure 13, the source device 12 includes a video source 18, a video encoder 20, and an output interface 22. The video source 18 may include a source such as a video capture device, 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. For example, if the video source 18 is a video camera in a security surveillance system, the source device 12 and the destination device 14 may form a camera phone or video phone. However, the implementations described herein may be applicable to video coding in general and may be applicable to wireless and / or wired applications.

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

[0202] The destination device 14 includes an input interface 28, a video decoder 30, and a display device 34. The input interface 28 includes a receiver and / or a modem and may receive encoded video data via link 16. The encoded video data communicated over link 16 or provided on the storage device 32 may include various syntactic elements generated by the video encoder 20 for use when the video decoder 30 decodes the video data. Such syntactic elements may be included in the encoded video data transmitted over a communication medium, stored on a storage medium, or stored on a file server.

[0203] In some implementations, the destination device 14 may include a display device 34, which may be an integrated display device and an external display device configured to communicate with the destination device 14. The display device 34 displays the decoded video data to the user and may include any of various display devices such as a liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, or other types of display devices.

[0204] The video encoder 20 and video decoder 30 may operate in accordance with proprietary or industry standards such as VVC, HEVC, MPEG-4, Part 10, AVC, or extensions of such standards. It should be understood that this application is not limited to any particular video encoding / decoding standard and is applicable to other video encoding / decoding standards as well. Generally, the video encoder 20 of the source device 12 is intended to be configured to encode video data in accordance with either of these current or future standards. Similarly, generally, the video decoder 30 of the destination device 14 is intended to be configured to decode video data in accordance with either of these current or future standards.

[0205] The video encoder 20 and video decoder 30 may each be implemented as one or more 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 the electronic device is partially implemented in software, it may store instructions for the software in a suitable non-temporary computer-readable medium and use one or more processors to execute those instructions in hardware to perform the video encoding / decoding operations disclosed herein. Each of the video encoder 20 and 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] Figure 14 is a block diagram showing an exemplary video encoder 20 in several implementation forms described in this application. The video encoder 20 may perform intra-predictive coding and inter-predictive coding of video blocks within a video frame. Intra-predictive coding relies on spatial prediction to reduce or eliminate spatial redundancy of video data within a given video frame or picture. Inter-predictive coding relies on temporal prediction to reduce or eliminate temporal redundancy of video data within adjacent video frames or pictures in a video sequence. It should be noted that the term “frame” may be used synonymously with the terms “image” or “picture” in the field of video coding.

[0207] As shown in Figure 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 transformation 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 segmentation 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 transformation processing unit 60, and an adder 62 for video block reconstruction. An in-loop filter 63, such as an unblock filter, may be placed between the adder 62 and the DPB 64 to filter block boundaries and remove blocky artifacts from the reconstructed video. In addition to the unblock 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 block may be provided directly to the DPB64 by the adder 62. The video encoder 20 may take the form of a fixed or programmable hardware unit, or it may be divided into one or more of the fixed or programmable hardware units shown.

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

[0209] As shown in Figure 14, the partitioning unit 45 within the prediction processing unit 41 partitions the video data into video blocks after receiving the video data. This partitioning may also involve partitioning the video frame into slices, tiles (e.g., sets 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 considered as a two-dimensional array or matrix of samples having sample values. Samples in the array may also be called pixels or pels. The number of samples in the horizontal and vertical (or axis) directions of the array or picture defines the size and / or resolution of the video frame. A video frame may be divided into multiple video blocks, for example by using QT partitioning. A video block may also be considered as a two-dimensional array or matrix of samples having sample values, although it has fewer dimensions than a video frame. The number of samples in the horizontal and vertical (or axis) directions of the video block defines the size of the video block. A video block may be further subdivided into one or more block partitions or subblocks (which may again form blocks) by repeatedly using, for example, QT partitioning, binary-tree (BT) partitioning, or triple-tree (TT) partitioning, or any combination thereof. It should be noted that the terms “block” or “video block” as used herein may refer to 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 an Encoded Tree Unit (CTU), CU, Prediction Unit (PU), or Translating Unit (TU), and / or a corresponding block, e.g., Encoded Tree Block (CTB), Encoded Block (CB), Prediction Block (PB), or Translating Block (TB), and / or subblocks.

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

[0211] To select an appropriate intra-predictive coding mode for the current video block, the intra-predictive processing unit 46 within the prediction processing unit 41 may perform intra-predictive coding of the current video block for one or more adjacent blocks in the same frame as the current block to be coded, thereby providing a spatial prediction. The motion estimation unit 42 and motion compensation unit 44 within the prediction processing unit 41 may perform inter-predictive coding of the current video block for one or more predicted blocks in one or more reference frames, thereby providing a temporal prediction. The video encoder 20 may perform multiple coding passes to select an appropriate coding mode for each block of video data, for example.

[0212] In some implementations, the motion estimation unit 42 determines the inter-prediction mode for the current video frame by generating motion vectors that indicate the displacement of the video block in the current video frame relative to the predicted block in the reference video frame, according to a predetermined pattern in the sequence of video frames. Motion estimation performed by the motion estimation unit 42 is the process of generating motion vectors that estimate the motion of the video block. For example, the motion vectors may indicate the displacement of the video block in the current video frame or picture relative to the predicted block in the reference frame relative to the current block encoded in the current frame. The predetermined pattern designates the video frames in the sequence as P-frames or B-frames. The intra-BC unit 48 may determine vectors for intra-BC encoding, such as block vectors, in a similar manner to how the motion estimation unit 42 determines the motion vectors for inter-prediction, or it may determine the block vectors using the motion estimation unit 42.

[0213] The predicted video block may be a block or reference block of a reference frame that is considered to be in exact agreement with the video block to be encoded in terms of pixel difference, or it may correspond to such blocks, which may be determined by the Sum of Absolute Difference (SAD), Sum of Square Difference (SSD), or other difference metrics. In some implementations, the video encoder 20 may calculate the values ​​of sub-integer pixel positions of the reference frame stored in the DPB64. For example, the video encoder 20 may interpolate the values ​​of pixel positions that are one-quarter, one-eighth, or other fractional pixel positions of the reference frame. Thus, the motion estimation unit 42 may perform motion search on all pixel positions and fractional pixel positions and output motion vectors with fractional pixel precision.

[0214] The motion estimation unit 42 calculates the motion vector of a video block in an interpredictive coded frame by comparing the position of a video block with the position of a predicted block in a reference frame selected from a first reference frame list (list 0) or a second reference frame list (list 1), each identifying one or more reference frames stored in the DPB64. The motion estimation unit 42 sends the calculated motion vector to the motion compensation unit 44, and then to the entropy coding unit 56.

[0215] Motion compensation performed by the motion compensation unit 44 may include fetching or generating a prediction block based on a motion vector determined by the motion estimation unit 42. Upon receiving the motion vector of the current video block, the motion compensation unit 44 may locate the position of the prediction block pointed to by that motion vector in one of the reference frame lists, retrieve the prediction block from the DPB 64, and transfer the prediction block to the adder 50. The adder 50 then forms a residual video block of pixel difference values ​​by subtracting the pixel values ​​of the prediction block provided by the motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel difference values ​​forming the residual video block may include a luminance difference component or a chrominance difference component, or both. The motion compensation unit 44 may also generate syntactic elements associated with the video block of the video frame for use when the video decoder 30 decodes the video block of the video frame. Syntactic elements may include, for example, syntactic elements that define the motion vector used to identify the prediction block, optional flags indicating the prediction mode, or any other syntactic information described herein. Although the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, they are shown separately for the purpose of illustrating the concepts.

[0216] In some implementations, the intraBC unit 48 can generate vectors and fetch predicted blocks in a manner similar to that described above in relation to the motion estimation unit 42 and the motion compensation unit 44, but the predicted blocks are in the same frame as the current block being encoded, and the vectors are called block vectors rather than motion vectors. Specifically, the intraBC unit 48 may determine which intraprediction mode to use to encode the current block. In some examples, the intraBC unit 48 may encode the current block using various intraprediction modes, for example, during separate encoding passes, and test their performance through rate distortion analysis. The intraBC unit 48 may then select an appropriate intraprediction mode to use from among the various tested intraprediction modes and generate an intramode indicator accordingly. For example, the intraBC unit 48 may calculate rate distortion values ​​using rate distortion analysis for the various tested intraprediction modes and select the intraprediction mode with the best rate distortion characteristics among the tested modes as the appropriate intraprediction mode to use. Rate distortion analysis generally determines the amount of distortion (or error) between the encoded block and the original unencoded block used to create the encoded block, and the bit rate (i.e., number of bits) used to create the encoded block. The intraBC unit 48 may calculate ratios from the distortion and rates of various encoded blocks to determine which intraprediction mode shows the best rate distortion value for that block.

[0217] In other examples, the intra-BC unit 48 may use all or part of the motion estimation unit 42 and the motion compensation unit 44 to perform such functions for intra-BC prediction in accordance with the implementations described herein. In any example, for intra-block copies, the predicted block may be a block that is considered to be an exact match to the block to be encoded, which may be determined with respect to pixel difference by SAD, SSD, or other difference metrics, and the identification of the predicted block may include calculating values ​​for sub-integer pixel positions.

[0218] Whether the predicted block is from the same frame according to intra-prediction, or from different frames according to inter-prediction, the video encoder 20 may form a residual video block by subtracting the pixel values ​​of the predicted block from the pixel values ​​of the currently encoded video block to form a pixel difference value. The pixel difference value forming the residual video block may include both luminance component differences and saturation component differences.

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

[0220] After the prediction processing unit 41 determines the prediction block of the current video block by interpretation or intraprediction, the adder 50 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be contained in one or more TUs and is provided to the transformation processing unit 52. The transformation processing unit 52 transforms the residual video data into residual transformation coefficients using a transformation such as a discrete cosine transform (DCT) or a conceptually similar transformation.

[0221] The conversion processing unit 52 may send the resulting conversion coefficients to the quantization unit 54. The quantization unit 54 quantizes the conversion 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 the quantization parameters. In some examples, the quantization unit 54 may then perform a scan of the matrix containing the quantized conversion coefficients. Alternatively, the entropy coding unit 56 may perform the scan.

[0222] Following quantization, the entropy coding unit 56 entropi-codes the quantized transformation 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) coding, or another entropy coding methodology or technique. The coded bitstream is then transmitted to the video decoder 30 as shown in Figure 13, or archived in the storage device 32 as shown in Figure 13 for later transmission to or retrieval by the video decoder 30. The entropy coding unit 56 may also entropi-code the motion vector and other syntactic elements of the current video frame being coded.

[0223] The inverse quantization unit 58 and the inverse transform processing unit 60 reconstruct the residual video block in the pixel domain by applying inverse quantization and inverse transform, respectively, to generate a reference block for predicting other video blocks. As described above, the motion compensation unit 44 may generate a motion-compensated prediction block from one or more reference blocks of frames stored in the DPB 64. The 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] The adder 62 may add the reconstructed residual block to the motion-compensated prediction block created by the motion compensation unit 44 to create a reference block for storage in the DPB 64. The reference block may then be used by the intraBC unit 48, the motion estimation unit 42, and the motion compensation unit 44 as a prediction block for interpreting another video block in a subsequent video frame.

[0225] Figure 15 is a block diagram showing an exemplary video decoder 30 in several 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 transformation 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 substantially the reverse of the encoding process described above with respect to the video encoder 20 in relation to Figure 14. For example, the motion compensation unit 82 may generate prediction data based on motion vectors 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, units of the video decoder 30 may be assigned the task of performing the implementation of the present invention. Also, in some examples, the implementation of the present disclosure may be divided into one or more units of the video decoder 30. For example, the intraBC unit 85 may perform the implementation of the present invention alone or in combination with other units of the video decoder 30, such as the motion compensation unit 82, the intraprediction unit 84, and the entropy decoding unit 80. In some examples, the video decoder 30 may not include the intraBC unit 85, and the functions of the intraBC unit 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82.

[0227] The video data memory 79 may store video data, such as an encoded video bitstream, which is decoded by other components of the video decoder 30. Video data stored in the video data memory 79 may be retrieved, for example, from a 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). The video data memory 79 may include a coded picture buffer (CPB) that stores the encoded video data from the encoded video bitstream. The DPB 92 of the video decoder 30 stores reference video data for use when the video decoder 30 decodes the video data (e.g., in intra-predictive coding mode or inter-predictive coding mode). The video data memory 79 and DPB 92 may be formed by any of various 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. In Figure 15, for illustrative purposes, the video data memory 79 and DPB92 are depicted as two separate components of the video decoder 30. However, it will be apparent to those skilled in the art that the video data memory 79 and DPB92 may be provided by the same memory device or by separate memory devices. In some examples, the video data memory 79 may be on-chip with the other components of the video decoder 30 or off-chip with respect to those components.

[0228] During the decoding process, the video decoder 30 receives an encoded video bitstream representing the video blocks and associated syntactic elements of the encoded video frames. The video decoder 30 may also receive syntactic elements at the video frame level and / or video block level. The entropy decoding unit 80 of the video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors or intra-predictive mode indicators, and other syntactic elements. The entropy decoding unit 80 then transfers the motion vectors or intra-predictive mode indicators and other syntactic elements to the prediction processing unit 81.

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

[0230] When a video frame is encoded as an interpredictive coded (i.e., B or P) frame, the motion compensation unit 82 of the prediction processing unit 81 may generate one or more prediction blocks of the video block of the current video frame based on the motion vector and other syntactic elements received from the entropy decoding unit 80. Each prediction block may be constructed from a reference frame in one of the reference frame lists. The 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 the DPB92.

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

[0232] The motion compensation unit 82 and / or intra-BC unit 85 determine prediction information about the video block of the current video frame by parsing motion vectors and other syntactic elements, and then use the prediction information to create a prediction block for the current video block being decoded. For example, the motion compensation unit 82 uses some of the received syntactic elements to determine the prediction mode used to encode the video block of the video frame (e.g., intra-predict or inter-predict), the inter-predict frame type (e.g., B or P), construction information for one or more of the frame's reference frame lists, the motion vector for each inter-predict coded video block of the frame, the inter-predict status for each inter-predict coded video block of the frame, and other information for decoding the video block in the current video frame.

[0233] Similarly, the intraBC unit 85 may use some of the received syntactic elements, such as flags, to determine that the current video block was predicted using intraBC mode, construction information regarding which video blocks in the frame are in the reconstruction area and which video blocks should be stored in the DPB 92, the block vector of each intraBC predicted video block in the frame, the intraBC predicted status of each intraBC predicted video block in the frame, and other information for decoding the video blocks in the current video frame.

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

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

[0236] After the motion compensation unit 82 or intraBC unit 85 generates a predicted block for the current video block based on vectors and other syntactic elements, the adder 90 reconstructs the decoded video block of the current video block by adding the residual block from the inverse processing unit 88 with the corresponding predicted block generated by the motion compensation unit 82 and intraBC unit 85. For further processing of the decoded video block, an in-loop filter 91 such as an unblock filter, an SAO filter, and / or ALF may be placed between the adder 90 and the DPB 92. In some examples, the in-loop filter 91 may be omitted, and the decoded video block may be provided directly to the DPB 92 by the adder 90. The decoded video block in a given frame is then stored in the DPB 92, which stores a reference frame to be used for subsequent motion compensation of the next video block. Alternatively, the DPB 92, or a memory device separate from the DPB 92, may store the decoded video for later presentation on a display device, such as the display device 34 in Figure 13.

[0237] The descriptions in this disclosure are provided for illustrative purposes only and are not intended to exhaust or limit the scope of this disclosure. Many modifications, variations, and alternative implementations will become apparent to those skilled in the art who benefit from the teachings presented in the foregoing description and the accompanying drawings.

[0238] The examples have been selected and described to illustrate the principles of this disclosure and to enable those skilled in the art to understand this disclosure in various embodiments and to make the most of the underlying principles and various implementations with various modifications to suit the specific intended use. It should therefore be understood that the scope of this disclosure is not limited to specific examples of the disclosed implementations, and that modifications and other implementations are intended to be included within the scope of this disclosure.

Claims

1. A method for video encoding, The parameters for determining the value of the encoding bit depth are transmitted via signal, The first sequence parameter set (SPS) flag is transmitted, wherein the first SPS flag is a conversion skip enable flag. Based on the value of the first SPS flag and the value of the encoding bit depth, a second SPS flag is set. Methods that include...

2. The second SPS flag is set based on the value of the first SPS flag and the value of the coding bit depth. A method for video coding according to claim 1, comprising signaling a second SPS flag based on the value of the first SPS flag and the value of the coding bit depth.

3. The second SPS flag is set based on the value of the first SPS flag and the value of the coding bit depth. A method for video coding according to claim 1, comprising setting the value of the second SPS flag based on the value of the first SPS flag and the value of the coding bit depth.

4. The value of the second SPS flag is set based on the value of the first SPS flag and the value of the coding bit depth. A method for video coding according to claim 3, comprising setting the value of the second SPS flag to be equal to 0, given that the value of the first SPS flag is equal to 0 and the value of the coding bit depth is greater than 10.

5. The method for video coding according to claim 1, further comprising setting the value of the second SPS flag to equal 1 to indicate that information about an SH transform skip residual coded rice index may be present in a slice header (SH) syntax structure that references the SPS.

6. The second SPS flag is transmitted based on the value of the first SPS flag and the value of the encoding bit depth. A method for video coding according to claim 2, comprising transmitting the second SPS flag on the condition that the value of the first SPS flag is equal to 1 and the value of the coding bit depth is greater than 10.

7. A device for video encoding, One or more processors, A memory configured to store instructions executable by one or more processors, An apparatus in which one or more processors are configured to execute the method described in any one of claims 1 to 6 when executing the instruction.

8. A non-temporary computer-readable storage medium for video encoding, A non-temporary computer-readable storage medium that stores computer-executable instructions that cause one or more computer processors to perform the method described in any one of claims 1 to 6 when executed by one or more computer processors.

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

10. A method for storing a bitstream, A bitstream is generated by performing the video encoding method according to any one of claims 1 to 6, Including storing the bitstream, method.

Images