Coding of residuals and coefficients for video coding

Abstract

To provide a method, an apparatus, and a non-transitory computer-readable storage medium for video decoding.SOLUTION: A decoder receives an enabling flag for a last significant coefficient of a sequence parameter set (SPS) indicating whether the enabling flag for an inverted coordinate of a last significant coefficient of a slice header (SH) is present in a slice header syntax structure referring to the SPS. In order to provide the same general constraint control as other flags, to general constraint information (GCI) syntax, the enabling flag for the inverted coordinate of the last significant coefficient of the GCI can be added.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] Cross-references to related applications

[0001] This application claims priority pursuant to Provisional Application No. 63 / 215,961 filed on 28 June 2021, the entire contents of which are incorporated herein by reference for all purposes.

[0002]

[0002] This disclosure relates to video coding and compression. More specifically, this disclosure relates to improvements and simplification of residual and coefficient coding for video coding. [Background technology]

[0003]

[0003] Various video coding techniques can be used to compress video data. Video coding is performed according to one or more video coding standards. For example, video coding standards include Multipurpose Video Coding (VVC), Joint Search Test Model (JEM), High Efficiency Video Coding (H.265 / HEVC), Advanced Video Coding (H.264 / AVC), and Moving Picture Expert Group (MPEG) coding. Video coding generally utilizes predictive methods (e.g., inter-prediction, intra-prediction, etc.) that take advantage of redundancy present in video images or sequences. A key goal of video coding techniques is to compress video data into a format that uses a lower bitrate while avoiding or minimizing a decrease in video quality. [Overview of the project]

[0004]

[0004] An example of the present disclosure provides a method and apparatus for video coding.

[0005]

[0005] According to a first aspect of the present disclosure, a method for video decoding is provided. The method may include the decoder receiving an SPS coefficient enable flag indicating whether a Slice Header (SH) coefficient enable flag exists in a Slice Header syntax structure that references a Sequence Parameter Set (SPS).

[0006]

[0006] A second aspect of the present disclosure provides a method for video decoding. The method may include the step of the decoder receiving a sequence parameter set (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 are adaptively assigned by examining the coefficient values ​​of the inverse quantization and inverse transform.

[0007]

[0007] A third aspect of the present disclosure provides a method for video decoding. The method may include the steps of: the decoder receiving a Sequence Parameter Set (SPS) high-throughput flag indicating whether syntax elements in residual coding are coded through bypass mode; and, in response to a determination that the value of the SPS high-throughput flag is equal to 1, the decoder determining that all syntax elements in residual coding are coded in bypass mode, except for the final significance coefficient position of normal residual coding (RRC), and that alignment is performed after the final significance coefficient position of the RRC and at the beginning of the transform block (TB) of transform-skip residual coding (TSRC).

[0008]

[0008] The above general description and the following detailed description are for illustrative purposes only and should be understood as not intended to limit the disclosure.

[0009]

[0009] The accompanying drawings incorporated herein and constituting part thereof illustrate examples consistent with the Disclosure and, together with the description, are useful in illustrating the principles of the Disclosure. [Brief explanation of the drawing]

[0010] [Figure 1]

[0010] Block diagram of an encoder according to an example of the present disclosure. [Figure 2]

[0011] Block diagram of a decoder according to an example of the present disclosure. [Figure 3A]

[0012] Diagram showing block division in a multi-tree structure according to an example of the present disclosure. [Figure 3B]

[0013] Diagram showing block division in a multi-tree structure according to an example of the present disclosure. [Figure 3C]

[0014] Diagram showing block division in a multi-tree structure according to an example of the present disclosure. [Figure 3D]

[0015] Diagram showing block division in a multi-tree structure according to an example of the present disclosure. [Figure 3E]

[0016] Diagram showing block division in a multi-tree structure according to an example of the present disclosure. [Figure 4]

[0017] Diagram showing the residual encoding structure of a transform block according to an example of the present disclosure. [Figure 5]

[0018] Diagram showing the residual encoding structure of a transform skip block according to an example of the present disclosure. [Figure 6]

[0019] Diagram of a method for encoding a video signal according to an example of the present disclosure. [Figure 7]

[0020] Diagram of a method for encoding a video signal according to an example of the present disclosure. [Figure 8]

[0021] Diagram showing a computing environment coupled with a user interface according to an example of the present disclosure. [Figure 9]

[0022] Diagram showing a method of video coding according to an example of the present disclosure. [Figure 10]

[0023] This figure shows a video coding method according to an example of the disclosure. [Figure 11]

[0024] This figure shows a video coding method according to an example of the disclosure. [Figure 12]

[0025] This figure shows a video encoding method according to an example of the disclosure. [Figure 13]

[0026] This block diagram shows an exemplary system for encoding and decoding video blocks, as an example of the present disclosure. [Figure 14]

[0027] Block diagram showing an exemplary video encoder according to an example of this disclosure. [Figure 15]

[0028] Block diagram showing an exemplary video decoder according to an example of this disclosure. [Figure 16]

[0029] This figure shows a low-latency transform-skip residual coding (TSRC) method according to an example of the present disclosure. [Figure 17]

[0030] This figure shows a method for video decoding according to an example of the present disclosure. [Figure 18]

[0031] This figure shows a method for video decoding according to an example of the present disclosure. [Figure 19]

[0032] This figure shows a method for video decoding according to an example of the present disclosure. [Figure 20]

[0033] This figure shows a method for video decoding according to an example of the present disclosure. [Figure 21]

[0034] This figure shows a method for video decoding according to an example of the present disclosure. [Modes for carrying out the invention]

[0011]

[0035] Next, exemplary embodiments will be referenced in detail, with examples 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 exemplary embodiments do not represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with the aspects related to the present disclosure as described in the accompanying claims.

[0012]

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

[0013]

[0037] Terms such as “first,” “second,” and “third” may be used herein to describe various types of information, but it should be understood that the information should not be limited by these terms. These terms are used solely to distinguish one category of information from another. For example, without departing from the scope of this disclosure, the first type of information may be referred to as the second type of information. Similarly, the second type of information may be referred to as the first type of information. The term “case” as used herein may be understood, depending on the context, to mean “when,” “at that time,” or “depending on judgment.”

[0014]

[0038] Figure 1 shows a general diagram of a block-based video encoder (video coder) for VVC. Specifically, Figure 1 shows a typical encoder 100. The encoder 100 includes a video input 110, a motion compensation unit 112, a motion estimation unit 114, an intra / intermode determination unit 116, a block predictor 140, an adder 128, a transform unit 130, a quantization unit 132, prediction-related information 142, an intra-prediction unit 118, a picture buffer 120, an inverse quantization unit 134, an inverse transform unit 136, an adder 126, a memory 124, an in-loop filter 122, an entropy coding unit 138, and a bitstream 144.

[0015]

[0039] 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 interprediction approach or an intraprediction approach.

[0016]

[0040] The 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 transformer 130. The transform coefficients are then sent from the transformer 130 to the quantizer 132 for entropy reduction. The quantization coefficients are then supplied to the entropy encoder 138 to generate a compressed video bitstream. As shown in Figure 1, prediction-related information 142 from the intra / intermode determination unit 116, such as video block division information, motion vectors (MV), reference picture index, and intra-prediction mode, is also supplied through the entropy encoder 138 and stored in the compressed bitstream 144. The compressed bitstream 144 contains the video bitstream.

[0017]

[0041] The encoder 100 also requires decoder-related circuitry to reconstruct pixels for prediction purposes. Prediction residuals are reconstructed through the inverse quantization unit 134 and the inverse transform unit 136. These reconstructed prediction residuals are coupled with the block predictor 140 to generate unfiltered reconstructed pixels of the current video block.

[0018]

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

[0019]

[0043] Time prediction (also called "interpretation") predicts the current video block using pixels reconstructed from an already encoded video picture. Time prediction mitigates the temporal redundancy inherent in video signals. The time prediction signal for a particular encoding unit (CU) or encoding block typically indicates the amount and direction of movement between the current CU and its time reference. It is transmitted by one or more MVs. In addition, if multiple reference pictures are supported, one reference picture index is transmitted, which is used to identify which reference picture in the reference picture storage the time prediction signal is from.

[0020]

[0044] The motion estimation unit 114 takes in signals from the video input 110 and the picture buffer 120 and outputs a motion estimation signal to the motion compensation unit 112. The motion compensation unit 112 takes in signals from the video input 110, the image buffer 120, and the motion estimation signal from the motion estimation unit 114 and outputs a motion compensation signal to the intra / intermode determination unit 116.

[0021]

[0045] After spatial and / or temporal predictions are performed, the intra / intermode determination unit 116 within the encoder 100 selects the best prediction mode, for example, based on a rated distortion optimization method. The block predictor 140 is then subtracted from the current video block, and the resulting prediction residual is decorrelated using the transform unit 130 and quantization unit 132. The resulting quantized residual coefficient is dequantized by the inverse quantization unit 134 and inversely transformed by the inverse transform unit 136 to form the reconstructed residual, which is then added back to the prediction block to form the reconstructed signal of the CU. Further in-loop filtering 122, such as a deblocking filter, sample-adaptive offset (SAO), and / or adaptive in-loop filter (ALF), can be applied to the reconstructed CU before it is placed in the reference picture storage of the picture buffer 120 and used to encode future video blocks. To form the output video bitstream 144, the encoding mode (inter or intra), prediction mode information, motion information, and quantization residual coefficients are all sent to the entropy encoding unit 138, where they are further compressed and packed to form the bitstream.

[0022]

[0046] 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 can be up to 128 x 128 pixels. However, unlike HEVC, which divides blocks based only on a quaternary tree, VVC divides a single coding tree unit (CTU) into CUs, adapting to various local characteristics based on quaternary / binary / triterary trees. By definition, a coding tree block (CTB) is an NxN block of samples for some value of N, where dividing the components into CTBs constitutes a division. A CTU may include a CTB for luminance (luma) samples, two corresponding CTBs for chroma samples of a picture with a three-sample array, or a CTB for samples of a picture encoded using three separate color planes and syntax structures used for encoding monochrome pictures or samples. Furthermore, the concept of multiple division unit types in HEVC is eliminated. In other words, the separation of CUs, Prediction Units (PUs), and Transformation Units (TUs) no longer exists in VVCs. Instead, each CU is always used as the basic unit for both prediction and transformation without further subdivision. In a multi-tree structure, first, one CU is subdivided into a quaternary tree structure. Then, each quaternary tree leaf node can be further subdivided into binary and ternary tree structures. As shown in Figures 3A, 3B, 3C, 3D, and 3E, there are five subdivision types: quaternary, horizontal bifurcation, vertical bifurcation, horizontal trifurcation, and vertical trifurcation.

[0023]

[0047] Figure 3A shows a diagram illustrating the division of a block into four parts in a multi-tree structure according to this disclosure.

[0024]

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

[0025]

[0049] Figure 3C shows a diagram illustrating the horizontal division of a block into two in a multi-tree structure according to this disclosure.

[0026]

[0050] Figure 3D shows a diagram representing the vertical three-part division of a block in a multi-tree structure as described in this disclosure.

[0027]

[0051] Figure 3E shows a diagram illustrating the horizontal three-part division of a block in a multi-tree structure according to this disclosure.

[0028]

[0052] In Figure 1, spatial and / or temporal prediction can be performed. Spatial prediction (or "intra-prediction") predicts the current video block using pixels from already encoded adjacent blocks (called reference samples) within the same video picture / slice. Spatial prediction mitigates the spatial redundancy inherent in video signals. Temporal prediction (also called "inter-prediction" or "motion-compensated prediction") predicts the current video block using pixels reconstructed from already encoded video pictures. Temporal prediction mitigates the temporal redundancy inherent in video signals. The temporal prediction signal for a particular CU is typically transmitted by one or more motion vectors (MVs) indicating the amount and direction of motion between the current CU and its time reference. If multiple reference pictures are supported, an additional reference picture index is transmitted, used to identify which reference picture in the reference picture storage the temporal prediction signal came from. After spatial and / or temporal prediction, a mode determination block within the encoder selects the optimal prediction mode, for example, based on a rated strain optimization method. The prediction block is then subtracted from the current video block. The prediction residuals are decorrelated and quantized using a transform. The quantized residual coefficients are inversely quantized and inversely transformed to form the reconstructed residuals, which are then added back to the prediction block to form the reconstructed signal of the CU. Further in-loop filtering, such as deblocking filters, sample-adaptive offsets (SAO), and adaptive in-loop filters (ALF), can be applied to the reconstructed CU before it is placed in the reference picture storage and used for encoding future video blocks. To form the output video bitstream, the encoding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy encoding unit, where they are further compressed and packed to form the bitstream.

[0029]

[0053] Figure 2 shows a typical block diagram of a video decoder for VVC. Specifically, Figure 2 shows a block diagram of a typical decoder 200. The decoder 200 includes a bitstream 210, an entropy decoder 212, an inverse quantizer 214, an inverse transformer 216, an adder 218, an intra / intermode selector 220, an intra prediction unit 222, a memory 230, an in-loop filter 228, a motion compensation unit 224, a picture buffer 226, prediction-related information 234, and a video output 232.

[0030]

[0054] The decoder 200 is similar to the reconstruction-related section present in the encoder 100 in Figure 1. In the decoder 200, the input video bitstream 210 is first decoded through the entropy decoding unit 212 to derive quantization coefficient levels and prediction-related information. Next, the quantization coefficient levels are processed through the inverse quantization unit 214 and the inverse transform unit 216 to obtain the reconstructed prediction residuals. The block prediction mechanism implemented in the intra / intermode selector 220 is configured to perform either the intra prediction unit 222 or the motion compensation unit 224 based on the decoded prediction information. The set of unfiltered reconstructed pixels is obtained by summing the reconstructed prediction residuals from the inverse transform unit 216 with the prediction output generated by the block prediction mechanism using the adder 218.

[0031]

[0055] The reconfigured block functions as a picture buffer, which stores the reference picture. Before being stored in 226, the image can pass through the in-loop filter 228. The reconstructed video in the picture buffer 226 is not only sent to drive the display device, but 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.

[0032]

[0056] Figure 2 shows a typical block diagram of a block-based video decoder. The video bitstream is first 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-coding) or the temporal prediction unit (in the case of inter-coding) to form a prediction block. The residual transformation coefficients are sent to the inverse quantization unit and the inverse transform unit to reconstruct the residual block. Next, the prediction block and the residual block are added together. The reconstructed block may further pass through in-loop filtering before being stored in the reference picture storage unit. The reconstructed video in the reference picture storage unit is used not only to drive the display device but also to predict future video blocks.

[0033]

[0057] Transformation coefficient coding in VVC

[0034]

[0058] In VVC conversion coefficient coding, the variable remBinsPassl is initially set to the maximum number of allowed context coding bins (MCCBs). During the coding process, the variable is decremented by 1 each time a context coding bin is transmitted. While remBinsPassl is 4 or greater, the coefficients are first transmitted through the syntax of sig_coeff_flag, abs_level_gtl_flag, par_level_flag, and abs_level_gt3_flag, all using context coding bins in the first pass. The remaining level information of the coefficients is coded in the syntax element of abs_remainder using Golombrice code and bypass coding bins in the second pass. If remBinsPass1 becomes less than 4 during the coding of the first pass, the current coefficients are not coded in the first pass but are directly coded in the second pass with the syntax element of dec_abs_level using Golombrice code and bypass coding bins. Rice parameters of dec_abs_level[] The derivation process is performed as specified in Table 1A. After all the level coding described above, the codes (code flags) at all scan positions where sig_coeff_flag is equal to 1 are finally coded as bypass bins. Such a process is shown in Figure 4. remBinsPasssl is reset per TB. The transition from using context coding bins for sig_coeff_flag, abs_level_gtl_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 coding the first coefficient, the entire coefficient subblock is coded using bypass coding bins.

[0035]

[0059] Figure 4 shows the residual coding structure of the transformation block.

[0036] [Table 1]

[0037] [Table 2]

[0038]

[0060] Residual coding in VVC conversion skip mode

[0039]

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

[0040]

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

[0041]

[0063] General Constraint Information

[0042]

[0064] The GCI structure includes several types of constraint syntax elements, including flags for general bitstream restrictions such as indicating that only intra-coding is used, that all layers are coded independently, or that the bitstream contains only one AU; fields that restrict the bit depth and saturation format of coded pictures; flags that indicate that certain NAL unit types cannot exist in the bitstream; flags that restrict how pictures can be divided into slices, tiles, and subpictures in the bitstream; flags that restrict the size of the CTU and the size and type of the division 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 aspects of in-loop filtering.

[0043]

[0065] The purpose of the GCI syntax structure is to facilitate the discovery of configuration information regarding the features required for decoding a bitstream, to impose restrictions beyond those specified in the profile, hierarchy, and level (PTL), and to enable signaling of interoperability points that impose restrictions at a finer granularity than allowed by previous video coding standards. Similar to subprofiles, the GCI syntax structure allows for the definition of interoperability for decoder implementations that address the needs of specific applications, although they do not support all features of the VVC profile. Decoder implementations may examine GCI syntax elements to determine how the decoding process is structured and to identify whether the bitstream is decodeable by the decoder, checking whether the bitstream avoids the use of certain features. Decoder implementations that support all features of the VVC profile can ignore the values ​​of the GCI syntax elements because such decoders can decode any bitstream conforming to a given PTL.

[0044]

[0066] Residual coding for conversion skipping

[0045]

[0067] According to one or more examples of the present disclosure, to encode certain syntax elements, a variable set of binary codewords, e.g., abs_remainder, is proposed to be used in transform skip residual coding. The selection is made according to certain coding information of the current block, e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile, and / or according to a new flag associated with TB / CB / slice / picture / sequence level, e.g., extended_precision_processing_flag. Various methods can be used to derive the variable set of binary codewords. Some exemplary methods are shown below.

[0046]

[0068] First, the same procedure as that used in the current VVC for determining the codeword of abs_remainder 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 certain coding information of the current block, e.g., quantization parameters, frame type (e.g., I, P, or B), component ID (e.g., luminance or chrominance), color format (e.g., 420, 422, or 444), or coding bit depth associated with TB / CB and / or slice / profile, and / or according to a syntax element associated with TB / CB / slice / picture / sequence level, e.g., 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. In fact, it is worth noting that the same logic can be implemented in different ways. For example, a specific equation or look-up table can also be used to derive the same Rice parameter from the BitDepth value of the current CU / sequence.

[0047]

[0069] Second, fixed-length binarization.

[0048]

[0070] Thirdly, binarization of the rice by truncation.

[0049]

[0071] Fourth, the truncation-to-binary (TB) binarization process.

[0050]

[0072] Fifth, the k-th order Exp-Golomb binarization process (EGk).

[0051]

[0073] Sixth, limited k-th order Exp-Golomb binarization

[0052]

[0074] An example of the corresponding decryption process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold italics in Table 1, and deleted content is shown in italics. Note that in practice, the same logic may be implemented in different ways. For example, the same RICE parameters may be derived using a specific equation or lookup table.

[0053] [Table 3]

[0054]

[0075] In another example, it is proposed that when a new flag, e.g., extended_precision_processing_flag, is equal to 1, only one fixed value should be used for the Rice parameter when encoding the syntax elements of abs_remainder. The corresponding decoding process based on the WC draft is shown below. Changes are shown in bold italics, and deleted content is shown in italics. Changes to the VVC draft are shown in bold italics in Table 2.

[0055] [Table 4]

[0056]

[0076] In yet another example, if a new flag, such as extended_precision_processing_flag, is equal to 1, the rice parameter cRiceParam is fixed to n, where n is a positive number (e.g., 2, 3, 4, 5, 6, 7, or 8). The fixed value may vary depending on the conditions. An example of the corresponding decryption process based on the VVC draft is shown below. Changes are shown in bold italics, and deleted content is shown in italics. Changes to the VVC draft are shown in bold italics in Table 3.

[0057] [Table 5]

[0058]

[0077] In yet another example, if 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 vary depending on the conditions. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a pre-set 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 to the VVC draft are shown in bold italics in Table 4.

[0059] [Table 6]

[0060]

[0078] In yet another example, a control flag is transmitted within the slice header to indicate whether the transmission of rice parameters for a transform skip block is enabled or disabled. If the control flag is transmitted as enabled, one more syntax element is transmitted for each transform skip slice to indicate the rice parameter for that slice. If the control flag is transmitted as disabled (e.g., set to "0"), no further syntax elements are transmitted 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 are shown in bold and italic fonts, and deleted content is shown in italic fonts. Changes to the VVC draft are shown in bold and italic fonts 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, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits written first (from left to right), can also be used to encode / decode the same syntax elements.

[0061]

[0079] Slice header syntax [Table 7]

[0062]

[0080] A sh_ts_residual_coding_rice_flag equal to 1 indicates that sh_ts_residual_coding_rice_index may exist in the current slice. A sh_ts_residual_coding_rice_flag equal to 0 indicates that sh_ts_residual_coding_rice_index does not exist in the current slice. If sh_ts_residual_coding_rice_flag does not exist, its value is assumed to be equal to 0. sh_ts_residual_coding_rice_index specifies the rice parameter used in the residual_ts_coding() syntax structure.

[0063] [Table 8]

[0064]

[0081] In yet another example, a control flag is transmitted within the sequence parameter set (or sequence parameter set range extension syntax) to indicate whether the transmission of rice parameters for transform skip blocks is enabled or disabled. If the control flag is transmitted as enabled, one more syntax element is transmitted for each transform skip slice to indicate the rice parameter for that slice. If the control flag is transmitted as disabled (e.g., set to "0"), no further syntax elements are transmitted 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 to the VVC draft are shown in bold and italic font in Table 7, and deleted content is shown in italic font. 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, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits written first (from left to right), can also be used to encode / decode the same syntax elements.

[0065]

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

[0066]

[0083] A 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 syntax structure referencing an SPS. A 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 syntax structure referencing an SPS. If sps_ts_residual_coding_rice_present_in_sh_flag does not exist, its value is presumed to be equal to 0.

[0067]

[0084] Slice header syntax [Table 10]

[0068]

[0085] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure.

[0069] [Table 11]

[0070]

[0086] In one or more examples of this disclosure, it is proposed to disable the existence of the rice parameter for transform-skip residual coding when transform skipping is disabled. In a particular 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 to satisfy such design objectives. For example, if the flag sps_transform_skip_enabled_flag is equal to 0 (i.e., transform skipping is disabled in the current picture), sps_ts_residual_coding_rice_present_in_sh_flag is not signaled and is inferred to be 0. 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 italics below.

[0071] [Table 12]

[0072]

[0087] In another specific example, it is proposed to add a bitstream conformance requirement related to sps_transform_skip_enabled_flag for sps_ts_residual_coding_rice_present_in_sh flag in order to satisfy such design objectives. For example, it is a bitstream conformance requirement that if sps_transform_skip_enabled_flag is equal to 0, then the value of sps_ts_residual_coding_rice_present_in_sh_flag must be equal to 0. Changes to the current VVC working draft are shown in italics below.

[0073]

[0088] Sequence parameter set range extension semantics

[0074]

[0089] A 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 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. If sps_ts_residual_coding_rice_present_in_sh_flag does not exist, its value is assumed to be equal to 0.

[0075]

[0090] A bitstream conformance requirement is that if sps_transform_skip_enabled_flag is equal to 0, then the value of sps_ts_residual_coding_rice_present_in_sh_flag must also be equal to 0.

[0076]

[0091] In yet another example, when the transform skip (sps_transform_skip_enabled_flag) flag is signaled as enabled, one control flag is further signaled in the sequence parameter set (or sequence parameter set range extension syntax) to indicate whether signaling of the rice parameter for the transform skip block is enabled or disabled. When the control flag is signaled as enabled, one syntax element is further signaled for each transform skip slice to indicate the rice parameter for that slice. When the control flag is signaled as disabled (e.g., set to "0"), no further syntax 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. Changes to the VVC draft are shown in italics.

[0077]

[0092] Sequence parameter set RBSP syntax [Table 13]

[0078]

[0093] A 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 syntax structure referencing an SPS. A 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 syntax structure referencing an SPS. If the sps_ts_residual_coding_rice_present_in_sh flag is not present, the value of sps_ts_residual_coding_rice_present_in_sh_flag is assumed to be equal to 0.

[0079]

[0094] Slice header syntax [Table 14]

[0080]

[0095] sh_ts_residual_coding_rice_idx_minus1 plus 1 specifies the rice parameter used in the residual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx_minus1 is not present, its value is assumed to be equal to 0.

[0081]

[0096] 9.3.3.11 Binarization process of abs_remainder[ ]

[0082]

[0097] The input to this process is the syntax element abs_remainder[n] The request is to binarize the following: color component cIdx, current subblock index i, luminance position (xO, yO) specifying the top-left sample of the current luminance conversion block relative to the top-left luminance sample of the picture, current coefficient scan position (xC, yC), binary logarithm of the conversion block width log2Tbwidth, and binary logarithm of the conversion block height log2TbHeight.

[0083]

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

[0084]

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

[0085]

[0100] - This process is called for the first time for the current subblock index i. If issued, both lastAbsRemainder and lastRiceParam will be set to equal to 0.

[0086]

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

[0087]

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

[0088]

[0103] - transform_skip_flag[x0][y0][cIdx If ] is equal to 1 and the sh_ts_residual_coding disable flag is equal to 0, the rice parameter cRiceParam is set to equal to sh_ts_residual_coding_rice_idx_minus1+1.

[0089]

[0104] - Otherwise, the rice parameter cRiceParam is set to 9.3. As specified in Section 3.2, the rice parameter of abs_remainder[ ] The derivation process is invoked by setting the variable baseLevel to equal to 4, and using the color component index cIdx, luminance position (x0, y0), current coefficient scan position (xC, yC), binary logarithm of the transformed block width log2Tbwidth, and binary logarithm of the transformed block height log2TbHeight as inputs.

[0090]

[0105] In yet another example, one syntax element for each transformation skip slice. This signal is transmitted and indicates the rice parameter of that slice. An example of the corresponding decoding process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold italics in Table 10. Note that sh_ts_residual_coding_rice_idx can be encoded in various ways and / or may have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits with the left bit written first (from left to right), can also be used to encode / decode the same syntax element.

[0091]

[0106] Slice header syntax [Table 15]

[0092]

[0107] sh_ts_residual_coding_rice_idx is res Specifies the rice parameter used for the idual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx does not exist, the value of sh_ts_residual_coding_rice_idx is assumed to be equal to 0.

[0093] [Table 16]

[0094]

[0108] In yet another example, is the transmission of the rice parameter in the conversion skip block effective? To indicate invalidity, a control flag is transmitted in the picture parameter set range extension syntax. If the control flag is transmitted as valid, the picture's parameter set range is extended. One more syntax element is transmitted to indicate the ta. If the control flag is transmitted as invalid (e.g., set to "0"), no further syntax elements are transmitted at a lower level to indicate the rice parameter of the transform skip slice, and the default rice parameter (e.g., 1) is used for all transform skip slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a given value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italic font 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, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits with the left bit written first (left to right), can also be used to encode / decode the same syntax element.

[0095]

[0109] Extended syntax for picture parameter set range

[0096] [Table 17]

[0097]

[0110] pps_ts_residual_coding_rice_fl is equal to 1 `ag` specifies that `pps_ts_residual_coding_rice_index` may exist in the current picture. A `pps_ts_residual_coding_rice_flag` equal to 0 specifies that `pps_ts_residual_coding_rice_idx` does not exist in the current picture. If `pps_ts_residual_coding_rice_flag` does not exist, its value is assumed to be equal to 0.

[0098]

[0111] pps_ts_residual_coding_rice_idx is re sidual_ts_coding() specifies the ts parameter used for the syntax structure.

[0099] [Table 18]

[0100]

[0112] In yet another example, the encoding of the syntax element abs_remainder It is proposed to use only variable Rice parameters. The values ​​of the Rice parameters to be applied may be determined according to specific encoding 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 encoding bit depth and the quantization parameters applied to one CU. The corresponding decoding process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold and italic font in Table 14, and deleted content is shown in italic font. It is worth noting that in practice, the same logic can be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0101] [Table 19-1] [Table 19-2]

[0102]

[0113] In yet another example, the corresponding decoding process based on the VVC draft is as follows: As shown, TH is a predetermined threshold (e.g., 33 or 34). Changes to the VVC draft are shown in bold and italic font in Table 15, and deleted content is shown in italic font. Note that in practice, the same logic may be implemented in different ways. For example, the same Rice parameters may also be derived using a specific equation or lookup table.

[0103] [Table 20]

[0104]

[0114] In yet another example, the corresponding decoding process based on the VVC draft is as follows: As shown, TH 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 and italic font in Table 16, and deleted content is shown in italic font. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0105] [Table 21]

[0106]

[0115] In yet another example, a new flag, for example, extended_precisi If on_processing_flag is equal to 1, it is proposed to use only variable Rice parameters for encoding the syntax elements of abs_remainder. The variable values ​​may be determined according to specific encoding 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 parameters based on the encoding bit depth and the quantization parameters applied to one CU. The corresponding decoding process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold and italic font in Table 17. It is worth noting that in practice, the same logic can be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0107] [Table 22]

[0108]

[0116] In yet another example, the corresponding decoding process based on the VVC draft is as follows: As shown, where TH is a predetermined threshold (e.g., 18, 19). Changes to the VVC draft are shown in bold and italic font in Table 18. In practice, It is worth noting that the same logic can be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0109] [Table 23]

[0110]

[0117] In yet another example, the corresponding decoding process based on the VVC draft is as follows: As shown, 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 and italic font in Table 19. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0111] [Table 24]

[0112]

[0118] Figure 6 shows a video encoding method. This method can be applied, for example, to an encoder. Step 1610 allows the encoder to receive a video input. For example, the video input may be a live stream. Step 1612 allows the encoder to obtain quantization parameters based on the video input. The quantization parameters may be calculated, for example, by a quantization unit within the encoder. Step 1614 allows the encoder to derive RICE parameters based on at least one predetermined threshold, coding bit depth, and quantization parameters. For example, the RICE parameters are used to transmit the syntax of abs_remainder and dec_abs_level. Step 1616 allows the encoder to entropically encode the video bitstream based on the RICE parameters. For example, the video bitstream may be entropically encoded to produce a compressed video bitstream.

[0113]

[0119] In yet another example, if BitDepth is greater than 10, abs_rem When encoding the syntax elements of the remainder, it has been proposed to use only fixed values (e.g., 2, 3, 4, 5, 6, 7, or 8) for the Rice parameter. The fixed values can be different under different conditions according to the specific encoding information of the current block, such as the quantization parameter. The corresponding decoding process based on the VVC draft is shown as follows. Here, TH is a predetermined threshold (e.g., 18, 19). The changes to the VVC draft are shown in Table 20 in bold and italic font. In fact, it is worth noting that the same logic can be implemented in different ways. For example, the same Rice parameter can also be derived using a specific equation or a look-up table.

[0114]

Table 25

[0115]

[0120] In yet another example, the corresponding decoding process based on the VVC draft is as follows shown, 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 shown in Table 21 in bold and italic font. In fact, it is worth noting that the same logic can be implemented in different ways. For example, the same Rice parameter can also be derived using a specific equation or a look-up table.

[0116]

Table 26

[0117]

[0121] In yet another example, the corresponding decoding process based on the VVC draft is as follows As shown, TH is a predetermined threshold (e.g., 33 or 34). Changes to the VVC draft are shown in bold and italic font in Table 22. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0118] [Table 27]

[0119]

[0122] In yet another example, the corresponding decoding process based on the VVC draft is as follows: As shown, TH 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 and italic font in Table 23. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0120] [Table 28]

[0121]

[0123] In the figure above, the equation used to calculate the specific Rice parameter is: It is worth mentioning that this 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 encoded bits and the quantization parameters applied). On the other hand, it should also be mentioned that in current VVC designs, the values ​​of the applied quantization parameters can be changed at the encoded 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 encoded block group level.

[0122]

[0124] Transmission information for regular residual coding and conversion skip residual coding Information

[0123]

[0125] According to one or more examples of this disclosure, in regular residual coding, particularly It has been proposed to transmit fixed syntax elements, such as the abs_remainder for transform skip residual coding, the shift parameters and offset parameters for deriving the Rice parameters used in abs_remainder / dec_abs_level, and to determine whether to transmit them according to specific coding information of the current block, such as the quantization parameters or coding bit depth associated with TB / CB and / or slice / profile, and / or according to a new flag associated with TB / CB / slice / picture / sequence level, such as sps_residual_coding_info_present_in_sh_flag.

[0124]

[0126] For example, one control flag controls the rice parameter of the conversion skip block. The slice header is transmitted to indicate whether transmission and transmission of shift and / or offset parameters for deriving the rice parameters of the transform block are enabled or disabled. If the control flag is transmitted as enabled, one syntax element is transmitted further for each transform skip slice to indicate the rice parameter of that slice, and two syntax elements are transmitted further for each transform slice to indicate the shift and / or offset parameters for deriving the rice parameter of that slice. If the control flag is transmitted as disabled (e.g., set to "0"), no further syntax elements are transmitted at lower levels to indicate the rice parameter of the transform skip slice, and the default rice parameter (e.g., 1) is used for all transform skip slices. No further syntax elements are signaled at lower levels to indicate the shift and / or offset parameters for deriving the rice parameter of the transform slice, 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, where TH is a predetermined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italic font in Table 24. It is worth noting that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_index can be encoded in different ways and / or have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits written first (left to right), can also be used to encode / decode the same syntax elements.

[0125]

[0127] Figure 7 shows a video decoding method. This method can be applied, for example, to an encoder. In step 1710, the encoder can receive the video input. In step 1712, the encoder can transmit the Rice parameters of a binary codeword for encoding syntax elements. The encoded syntax elements may include the abs_remainder of the transform skip residual coding. In step 1714, the encoder can entropically encode the video bitstream based on the Rice parameters and the video input.

[0126]

[0128] Slice header syntax [Table 29]

[0127]

[0129] sh_residual_coding_rice_flag equal to 1 is: A sh_residual_coding_rice_flag equal to 0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index may exist in the current slice, while sh_residual_coding_rice_flag equal to 0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_residual_coding_rice_index do not exist in the current slice.

[0128]

[0130] sh_residual_coding_rice_shift is abs_ Specifies the shift parameter used in the rice parameter derivation process for readinder[] and dec_abs_level[]. If sh_residual_coding_rice_shift does not exist, the value of sh_residual_coding_rice_shift is assumed to be equal to 0.

[0129]

[0131] sh_residual_coding_rice_offset is abs Specifies the offset parameter used in the rice parameter derivation process for _remainder[] and dec_abs_level[]. If sh_residual_coding_rice_offset does not exist, the value of sh_residual_coding_rice_offset is assumed to be equal to 0.

[0130]

[0132] sh_ts_residual_coding_rice_index is r Rice parameters used in the esidual_ts_coding() syntax structure Specify the value. If sh_ts_residual_coding_rice_index does not exist, the value of sh_ts_residual_coding_rice_index is assumed to be equal to 0.

[0131] [Table 30]

[0132] [Table 31-1] [Table 31-2]

[0133]

[0133] In another example, one control flag is set to the sequence parameter set (or sequence parameter set) The extended syntax for the transition parameter set range is transmitted to indicate whether the transmission of the rice parameters of the transformation skip block and the transmission of shift and / or offset parameters for deriving the rice parameters within the transformation block are enabled or disabled. When the control flag is transmitted as enabled, one syntax element is transmitted further for each transformation skip slice to indicate the rice parameters of that slice, and two syntax elements are transmitted further for each transformation slice to indicate the shift and / or offset parameters for deriving the rice parameters of that slice. When the control flag is transmitted as disabled (e.g., set to "0"), no further syntax elements are transmitted at a lower level to indicate the rice parameters of the transformation skip slices, and the default rice parameter (e.g., 1) is used for all transformation skip slices, and no further syntax elements are transmitted at a lower level to indicate the shift and / or offset parameters for deriving the rice parameters of the 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. Here, TH is a predetermined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italic font in Table 27. It is worth noting that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be encoded in different ways and / or have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits written first (left to right) as the left bit, can also be used to encode / decode the same syntax element.

[0134]

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

[0135]

[0135] sps_residual_coding_info_prese equal to 1 nt_in_sh_flag specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx may exist within the SH syntax structure referencing the SPS. sps_residual_coding_info_present_in_sh_flag equal to 0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx do not exist within the SH syntax structure referencing the SPS. If sps_residual_coding_info_present_in_sh_flag does not exist, the value of sps_residual_coding_info_present_in_sh_flag is assumed to be equal to 0.

[0136]

[0136] Slice Header Syntax [Table 33]

[0137]

[0137] sh_residual_coding_rice_shift is abs_ Specifies the shift parameter used in the rice parameter derivation process for remainder[] and dec_abs_level[]. If sh_residual_coding_rice_shift does not exist, the value of sh_residual_coding_rice_shift is assumed to be equal to 0.

[0138]

[0138] sh_residual_coding_rice_offset is abs Specifies the offset parameter used in the rice parameter derivation process for _remainder[] and dec_abs_level[]. If sh_residual_coding_rice_offset does not exist, the value of sh_residual_coding_rice_offset is assumed to be equal to 0.

[0139]

[0139] sh_ts_residual_coding_rice_idx is res Specifies the rice parameter used for the idual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_index does not exist, the value of sh_ts_residual_coding_rice_index is assumed to be equal to 0.

[0140] [Table 34]

[0141] [Table 35-1] [Table 35-2]

[0142]

[0140] In yet another example, one syntax element is applied to each transformation skip slice. The two syntax elements are signaled for each transformed slice to indicate the rice parameter of that slice, and the two syntax elements are signaled for each transformed slice to indicate the shift parameter and / or offset parameter for deriving the rice parameter of that slice. An example of the corresponding decoding process based on the VVC draft is shown below. Changes to the WC draft are shown in bold italics in Table 31. Note that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset, and sh_ts_residual_coding_rice_idx can be encoded in different ways and / or have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a fixed pattern bit string using n bits with the left bit written first (left to right), can also be used to encode / decode the same syntax elements.

[0143]

[0141] Slice Header Syntax [Table 36]

[0144]

[0142] sh_ts_residual_coding_rice_idx is res Specifies the rice parameter used for the idual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx does not exist, the value of sh_ts_residual_coding_rice_idx is assumed to be equal to 0.

[0145]

[0143] sh_residual_coding_rice_offset is abs Specifies the offset parameter used in the rice parameter derivation process for _remainder[] and dec_abs_Level[]. If sh_residual_coding_rice_offset does not exist, the value of sh_residual_coding_rice_offset is assumed to be equal to 0.

[0146]

[0144] sh_ts_residual_coding_rice_idx is res Specifies the rice parameter used for the idual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_index does not exist, the value of sh_ts_residual_coding_rice_index is assumed to be equal to 0.

[0147] [Table 37]

[0148] [Table 38-1] [Table 38-2]

[0149]

[0145] In yet another example, one control flag expands the picture parameter set range. The syntax is transmitted in Zhang syntax and indicates whether the transmission of the rice parameter for the transform skip block and the transmission of the shift and / or offset parameters for deriving the rice parameter within the transform block are enabled or disabled. When the control flag is transmitted as enabled, one syntax element is further transmitted to indicate the rice parameter for the transform skip residual coding of that picture, and two syntax elements are further transmitted for regular residual coding to indicate the shift and / or offset parameters for deriving the rice parameter of that picture. When the control flag is transmitted as disabled (e.g., set to "0"), no further syntax elements are transmitted at a lower level to indicate the rice parameter for the transform skip residual coding, and the default rice parameter (e.g., 1) is used for all transform skip residual coding, and no further syntax elements are transmitted at a lower level to indicate the shift and / or offset parameters for deriving the rice parameter for regular residual coding, and the default shift and / or offset parameters (e.g., 0) are used for all regular residual coding. An example of the corresponding decoding process based on the VVC draft is shown below. Here, TH is a predetermined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italic font in Table 34. It is worth noting that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_idx can be encoded in different ways and / or have a maximum value. For example, u(n), an unsigned integer using n bits, or f(n), a bit string of a fixed pattern using n bits written in order from left to right, can also be used to encode / decode the same syntax element.

[0150]

[0146] Extended Syntax for Picture Parameter Set Range [Table 39]

[0151]

[0147] pps_residual_coding_info_flag equal to 1 pps_residual_coding_rice_shift, pps_residual_coding_rice_offset, and pps_ts_residual_coding_rice_index may exist in the current picture. A 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. If pps_residual_coding_info_flag does not exist, its value is assumed to be equal to 0.

[0152]

[0148] pps_residual_coding_rice_shift is abs Specifies the shift parameter used in the rice parameter derivation process for _remainder[] and dec_abs_level[]. If pps_residual_coding_rice_shift does not exist, the value of pps_residual_coding_rice_shift is assumed to be equal to 0.

[0153]

[0149] pps_residual_coding_rice_offset is ab Specifies the offset parameter used in the rice parameter derivation process for s_remainder[] and dec_abs_level[]. If pps_residual_coding_rice_offset does not exist, the value of pps_residual_coding_rice_offset is assumed to be equal to 0.

[0154]

[0150] pps_ts_residual_coding_rice_idx is re Specifies the rice parameter used for the sidual_ts_coding() syntax structure. If pps_ts_residual_coding_rice_index does not exist, its value is assumed to be equal to 0.

[0155] [Table 40]

[0156] [Table 41-1] [Table 41-2]

[0157]

[0151] According to one or more examples of this disclosure, encoding a particular syntax element It has been proposed to use different RICE parameters, e.g., abs_remainder for transform skip residual coding, and to shift and offset the parameters to derive the RICE parameters used for abs_remainder / dec_abs_level in normal residual coding, and to decide which to use according to the specific coding information of the current block, e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile, and / or according to a new flag associated with TB / CB / slice / picture / sequence level, e.g., sps_residual_coding_info_present_in_sh_flag.

[0158]

[0152] In one example, one control flag is transmitted in the slice header, and the conversion skip block This indicates whether the process for deriving the rice parameter of a block and the process for deriving the shift and / or offset parameters of the rice parameter of a transform block are enabled or disabled. When the control flag is transmitted as enabled, the rice parameter may differ under different conditions depending on the specific encoding information of the current block, e.g., quantization parameters and bit depth. The shift and / or offset parameters for deriving the rice parameter in normal residual coding may also differ under different conditions depending on the specific encoding information of the current block, e.g., quantization parameters and bit depth. When the control flag is transmitted 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. Here, 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 and italic font in Table 37. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0159]

[0153] Slice Header Syntax [Table 42]

[0160]

[0154] sh_residual_coding_rice_flag equal to 1 is, Specifies that the bit-depth-based rice parameter derivation process is used for the current slice. A sh_residual_coding_rice_flag equal to 0 specifies that the bit-depth-based rice parameter derivation process is not used for the current slice.

[0161] [Table 43]

[0162] [Table 44-1] [Table 44-2]

[0163]

[0155] In yet another example, the corresponding decryption process based on the VVC draft is as follows: This is shown, where TH is a predetermined threshold (e.g., 18, 19). Changes to the VVC draft are shown in bold and italic font in Table 40. It is worth noting that the same logic can actually be implemented in different ways. For example, the same Rice parameters can also be derived using a specific equation or lookup table.

[0164] [Table 45-1] [Table 45-2]

[0165]

[0156] According to another aspect of this disclosure, the values ​​of these coding tools are generally General constraint control, the same as other constraint information. It is proposed to add a constraint that a flag must be set to provide information.

[0166]

[0157] For example, sps_ts_residual_coding_ric equal to 1 e_present_in_sh_flag specifies that sh_ts_residual_coding_rice_idx may exist within an SH syntax structure referencing an SPS. sps_ts_residual_coding_rice_present_in_sh_flag equal to 0 specifies that sh_ts_residual_coding_rice_idx does not exist within an SH syntax structure referencing an SPS. 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.

[0167] [Table 46]

[0168] [Table 47]

[0169]

[0158] In another example, pps_ts_residual_coding_rice_f When lag is equal to 1, it specifies that pps_ts_residual_coding_rice_index may exist in the current picture. When pps_ts_residual_coding_rice_flag is equal to 0, it specifies that pps_ts_residual_coding_rice_idx does not exist in the current picture. According to this disclosure, in order to provide the same general constraint control as other flags, it has been proposed to add the syntax element gci_no_ts_residual_coding_rice_constraint_flag to the general constraint information syntax. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. The added parts are highlighted in italics.

[0170]

Table 48

[0171]

Table 49

[0172]

[0159] In yet another example, the sps_rice_adaptation_e nabled_flag equal to 1 indicates that the Rice parameter for the binarization of abs_remainder[ ] and dec_abs_ level can be derived by an expression.

[0173]

[0160] 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]))), and the lists Tx[ ] and Rx[ ] are specified as follows: Tx ]={32,128,512,2048}>>(1523)Rx[ ]={0, 2, 4, 6, 8}

[0174]

[0161] According to this disclosure, in order to provide the same general constraint control as other flags, general constraint It is proposed to add the syntax element gci_no_rice_adaptation_constraint_flag to the information syntax. An example of the VVC draft decoding process is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics.

[0175] [Table 50]

[0176] [Table 51]

[0177]

[0162] The proposed rice parameter adaptation method is conversion skip residual coding (TS Since it is used only for RC, the proposed method may only be effective when TSRC is enabled. Similarly, in one or more embodiments of the present disclosure, it is proposed to add a single bti stream 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.

[0178]

[0163] In yet another example, sps_range_extension_f is equal to 1. lag specifies that the sps_range_extension() syntax structure exists within the SPSRBSP syntax structure. If sps_range_extension_flag is equal to 0, it specifies 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 to the general constraint information syntax 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.

[0179] [Table 52]

[0180] [Table 53]

[0181]

[0164] Figure 9 shows a video encoding method according to an example of the present disclosure. This method is, for example, This can be applied to a decoder. In step 1902, the decoder may receive a Sequence Parameter Set (SPS) Range Extension flag, which indicates whether the syntax structure sps_range_extension exists in the Slice Head (SH) Raw Byte Sequence Payload (RBSP) syntax structure based on the value of the SPS Range Extension flag.

[0182]

[0165] In step 1904, the determination is made that the value of the SPS range extension flag is equal to 1. In response, the decoder can determine that sps_range_extension exists within the SHRBSP syntax structure.

[0183]

[0166] In step 1906, in response to the determination that the value of the range extension flag is equal to 0 Thus, the decoder can determine that the sps_range_extension does not exist in the SHRBSP syntax structure.

[0184]

[0167] In yet another example, the sps_cabac_bypass_alig nment_enabled_flag equal to 1 is aligned before the bypass decoding of the syntax elements sb_coded_flag[ ][ ], abs_remainder[ ], dec_abs_Level[n] and coeff_sign_flag[ ]. When the sps_cabac_bypass_alignment_enabled_flag is equal to 0, it specifies that the value of ivlCurrRange is not aligned before bypass decoding. According to this disclosure, in order to provide the same general constraint control as other flags, it has been proposed to add the syntax element gci_no_cabac_bypass_alignment_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.

[0185]

Table 54

[0186]

Table 55

[0187]

[0168] FIG. 10 shows a video coding method according to an example of the present disclosure. This method, for example This can be applied to the decoder. In step 2002, the decoder may receive a Sequence Parameter Set (SPS) alignment enable flag, which indicates 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 valid SPS alignment values.

[0188]

[0169] In step 2004, if the value of the SPS alignment enable flag is equal to 1 In response to this decision, the decoder can determine that the ivlCurrRange was aligned before bypass decoding.

[0189]

[0170] In step 2006, if the value of the SPS alignment enable flag is equal to 0 In response to this decision, the decoder can determine that the ivlCurrRange was not aligned before bypass decoding.

[0190]

[0171] In yet another example, extended_precision_pr equals 1. The `processing_flag` specifies that the extended dynamic range can be used for the conversion coefficients, while a conversion process equal to 0, `extended_precision_processing_flag`, specifies that the 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` to the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process for a VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics.

[0191] [Table 56]

[0192] [Table 57]

[0193]

[0172] Figure 11 shows a video encoding method according to an example of the present disclosure. This method is, for example, This can be applied to the decoder. In step 2102, the decoder can receive an extended precision processing flag during the conversion process based on the value of the extended precision processing flag and indicating whether extended dynamic range is adopted for the conversion coefficients.

[0194]

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

[0195]

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

[0196]

[0175] In yet another example, persistent_rice_adapt is equal to 1. ation_enabled_flag is set to abs_remainder[ ] and dec The _abs_level binarization rice parameter derivation can be initialized at the start of each subblock using mode-dependent statistics accumulated from previous subblocks. A persistent_rice_adaptation_enabled_flag equal to 0 specifies that previous subblock states are 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 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.

[0197] [Table 58]

[0198] [Table 59]

[0199]

[0176] Figure 12 shows a video encoding method according to an example of the present disclosure. This method is, for example, This can be applied to the decoder. In step 2202, the decoder may receive a persistent_rice_adaptation_enabled 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, taking into account mode-dependent statistics accumulated from previous subblocks based on the value of persistent_rice_adaptation_enabled_flag.

[0200]

[0177] In step 2204, persistent_rice_adapta In response to the determination that the value of tion_enabled_flag is equal to 1, the decoder can employ mode-dependent statistics accumulated from previous subblocks to determine that the Rice parameter derivation for binarization is initialized at the beginning of each subblock.

[0201]

[0178] In step 2206, if the value of the persistent Rice adaptation enable flag is 0 In response to this decision, the decoder may decide that the previous subblock state is not adopted in the derivation of the Rice parameter.

[0202]

[0179] In yet another example, sps_rrc_rice_extensio equals 1. n_flag is abs_remainder[ ] and dec_abs_Level Specifies that the extension of the Rice parameter derivation to the binarization of [ ] is valid. An equal sps_rrc_rice_extension_flag indicates that extension of the rice parameter derivation 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 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 shown in italics below.

[0203] [Table 60]

[0204] [Table 61]

[0205]

[0180] Figure 17 shows a method for video decoding according to an example of the present disclosure. This method is For example, it can be applied 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.

[0206]

[0181] In step 2704, the value of the SPS Rice extension flag is equal to 1. In response to this, the decoder can determine that an extension of the Rice parameter derivation for binarization is valid.

[0207]

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

[0208]

[0183] In yet another example, sps_persistent_rice_a is equal to 1. daptation_enabled_flag is abs_remainder[ ] And the derivation of the Rice parameter for binarization of dec_abs_level[ ] is as follows: Specifies that the parameters are initialized at the start of each TU using statistics accumulated from the previous TU. If sps_persistent_rice_adaptation_enabled_flag is equal to 0, it specifies that the previous TU state is not used in the derivation of the rice parameters. According to this disclosure, it is proposed to add the syntax element gci_no_persistent_rice_adaptation_enabled_flag to the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process of the VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are shown in italics below.

[0209] [Table 62]

[0210] [Table 63]

[0211]

[0184] Figure 18 shows a method for video decoding according to an example of the present disclosure. This method is For example, this can be applied to a decoder. In step 2802, the decoder may receive an SPS Rice adaptive enable flag indicating whether the Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the start of each transformation unit using statistics accumulated from previous TUs.

[0212]

[0185] In step 2804, the value of the SPS Rice adaptation enable flag is equal to 1. In response to this decision, the decoder may decide that the Rice parameter derivation for binarization is initialized at the beginning of each TU using statistics accumulated from previous TUs.

[0213]

[0186] In step 2806, the value of the SPS Rice adaptation enable flag is equal to 0. In response to this decision, the decoder can decide that the previous TU state is not adopted in the derivation of the Rice parameter.

[0214]

[0187] In yet another example, sps_reverse_last_sig_coeff _enabled_flag is equal to 1, specifying that sps_reverse_last_sig_coeff_enabled_flag exists in the slice_header() syntax structure that references SPS. sps_reverse_last_sig_coeff_enabled_flag is equal to 0, specifying that sps_reverse_last_sig_coeff_enabled_flag does not exist in 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 to the general constraint information syntax 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.

[0215] [Table 64]

[0216] [Table 65]

[0217]

[0188] If sh_reverse_last_sig_coeff_flag is equal to 1, it specifies that the coordinates of the final significance coefficient are encoded relative to ((Log2ZoTbwidth<<1)-1,(Log2ZoTbHeight<<1)-1) for each transformed block of the current slice. If sh_reverse_last_sig_coeff_flag is equal to 0, it specifies that the coordinates of the final significance coefficient are encoded relative to (0,0) for each transformed block of the current slice. If it does not exist, the value of sh_reverse_last_sig_coeff_flag is assumed to be equal to 0.

[0218]

[0189] Figure 19 shows a method for video decoding according to an example of the present disclosure. This method can be applied, for example, to a decoder. In step 2902, the decoder can receive an enable flag for the final significance of the SPS, indicating whether the enable flag for the inverted coordinates of the final significance of the SH is present in the slice header syntax structure that references the SPS.

[0219]

[0190] In step 2904, in response to the determination that the value of the enable flag for the inverted coordinate of the final significance coefficient of SPS is equal to 1, the decoder can determine that the enable flag for the final significance coefficient of SH is present in the slice header syntax structure that references SPS.

[0220]

[0191] In step 2906, in response to the determination that the value of the enable flag for the inverted coordinate of the final significance coefficient of SPS is equal to 0, the decoder may determine that the enable flag for the final significance coefficient of SH is not present in the slice header syntax structure referring to SPS.

[0221]

[0192] In yet another example, sps_transform_precisi is equal to 1. The `on_adaptation_enabled_flag` specifies that downshifts in the scaling process of transformation coefficients and the transformation process 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` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for a VVC draft is shown below. Changes to the VVC draft are highlighted. Added portions are highlighted in italics.

[0222] [Table 66]

[0223] [Table 67]

[0224]

[0193] Figure 20 shows a method for video decoding according to an example of the present disclosure. This method is For example, this can be applied 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.

[0225]

[0194] In step 3004, the value of the SPS conversion accuracy adaptive enable flag is equal to 1. In response to this decision, the decoder may decide that the downshifts in the scaling process of the transformation coefficients and the transformation process of the scaled transformation coefficients are adaptively assigned by examining the coefficient values ​​of the inverse quantization and inverse transformation.

[0226]

[0195] In yet another example, sps_high_throughput_flag being equal to 1 specifies that all residual coding syntax elements are coded in bypass mode, except for the final significance coefficient position of the RRC, and that alignment is required only once after the final significance coefficient position of the RRC and at the beginning of the TB of the TSRC. According to this disclosure, it is proposed to add the syntax element gci_no_high_throughput_flag to the general constraint information syntax to provide the same general constraint control as the other flags. An example of the decoding process for a VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics.

[0227] [Table 68]

[0228] [Table 69]

[0229]

[0196] Figure 21 shows a method for video decoding according to an example of the present disclosure. This method is For example, it can be applied to a decoder. In step 3102, the decoder can receive an SPS high-throughput flag indicating whether the syntax elements in residual coding are coded through bypass mode.

[0230]

[0197] In step 3104, in response to the determination that the value of the SPS high-throughput flag is equal to 1, the decoder may determine that all syntax elements of the residual coding are coded through bypass mode, except for the final significance coefficient position of the normal residual coding (RRC). Alignment is performed after the final significance coefficient position of the RRC and at the beginning of the transform block (TB) of the transform skip residual coding (TSRC).

[0231]

[0198] The above method can be implemented using a device that includes one or more circuits. This includes application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components. The device may use the circuit in combination with other hardware or software components to perform the methods described above. Each module, submodule, unit, or subunit disclosed above may be implemented at least partially using one or more circuits.

[0232]

[0199] Determination of Rice Parameters

[0233]

[0200] On the encoder side, TSRC coding derives the best Rice parameters This may require multiple encoding paths. This multi-pass encoding may not be suitable for the design of actual hardware encoders. To solve this problem, low-latency TSRC encoding schemes have also been proposed. According to one or more examples of this disclosure, it is proposed to derive the rice parameters according to specific encoding information of the current slice, e.g., quantization parameters and / or encoding bit depth associated with the slice / picture / sequence, and / or hash ratios associated with the slice / picture / sequence level. Various methods can be used to derive the rice parameters. Some exemplary methods are shown below. Note that the following methods can be applied independently or in combination.

[0234]

[0201] 1. The Rice parameters described in the above embodiments are the time resolution of the video (for example) It may also depend on the video resolution, which includes both the frame rate and spatial resolution (e.g., the width and height of the picture).

[0235]

[0202] 2. Rice parameters are sequence level, picture level, slice level It can vary in the sequence level, picture level, slice level, and / or any pre-configured area. In one particular example, different Rice values ​​are used for pictures with different time layer IDs (related to nuh_temporal_id_plusl specified in the VVC specification). Alternatively, the Rice parameter may include a value determined based on the sequence level, picture level, slice level, and / or any pre-configured area. For example, Rice parameter = Clip3(1,8,(TH-QP) / 6), where TH is a pre-configured threshold (e.g., 18, 19).

[0236]

[0203] 3. The Rice parameter is the encoding information between the current slice and the previous slice. Depending on the change in information, it may be set to a default value, e.g., 1. In one particular example, if the time layer ID changes compared to the previous picture, the default Rice value is used for the picture. Alternatively, if AQ is greater than TH, the default Rice value is used for the picture, where AQ is calculated as abs(QPcurrent-QPprevious) and TH is a pre-configured threshold. Rice parameter (e.g., 0, 5). For example, if the hash ratio from the intrablock copy mode of the current slice is greater than TH, the Rice parameter = 1, where TH is a pre-configured threshold, e.g., Max(41*(number of CTUs),4200).

[0237]

[0204] 4. abs_remaind encoded in the previous slice according to the encoding order. The rice parameter for each slice based on the value of er. In one particular example, after one slice is encoded, the number of bins for binarization of abs_remainder using different rice parameters is calculated and then used to determine the rice parameter for the next slice. For example, the rice parameter that achieved the smallest number of bins in the previous slice is selected for the current slice. In another example, if the current slice and the previous slice use the same QP, the rice parameter that achieved the smallest number of bins in the previous slice is selected for the current slice. Otherwise, the number of bins produced using the default rice parameter (i.e., 1) in the previous slice is scaled by TH before being compared with other rice parameters, and the rice parameter that results in the smallest number of bins is selected for the current slice. TH is a pre-set threshold, e.g., 0.9.

[0238]

[0205] 5. abs_remain encoded in the previous slice according to the encoding order The rice parameters for each slice, based on the value of der, are as follows: The rice parameter can be adjusted according to changes in the encoded information between the current slice and the previous slice. In a particular example, the rice parameter that achieves the minimum number of bins in the previous slice is selected for the current slice. Also, if AQ is greater than TH, the rice value can be adjusted, where AQ is calculated as abs(QPcurrent-QPprevious) and TH is a pre-set threshold. Rice parameter (e.g., 0, 5). The adjustment may involve adding a pre-set offset (e.g., +1, -1) or scaling by a pre-set value.

[0239]

[0206] Figure 16 shows an example of low-latency transform-skip residual coding (TSRC) according to the present disclosure. The flowchart of the method is shown. This method can be applied, for example, to an encoder. In step 2602, the encoder can derive the hash parameters based on the encoding information of the current slice of video. The encoding information may include one or more of the following parameters: quantization parameters or encoding bit depth associated with the slice, picture, or sequence of video, or the hash ratio associated with the slice, picture, or sequence of video.

[0240]

[0207] Note that the above encoder method can be applied to the decoder side. In certain cases, it is not necessary to signal the Rice parameters to the decoder; the encoder / decoder derives the Rice parameters using the same method.

[0241]

[0208] Figure 8 shows the computing environment coupled with the user interface 1860. The computing environment 1810 is shown. The computing environment 1810 can be part of a data processing server. The computing environment 1810 includes a processor 1820, memory 1840, and an I / O interface 1850.

[0242]

[0209] The processor 1820 is typically used for display, data acquisition, data communication, and image processing. It controls the overall operation of the computing environment 1810, including operations related to logic. Processor 1820 may include one or more processors that execute instructions to perform all or part of the steps in the method described above. Furthermore, processor 1820 may include one or more modules that facilitate interaction between processor 1820 and other components. The processor may be a central processing unit (CPU), a microprocessor, a single-chip machine, a GPU, etc.

[0243]

[0210] Memory 1840 supports the operation of computing environment 1810. Therefore, it is configured to store various types of data. Memory 1840 may include certain software 1842. Examples of such data include instructions for any application or method to operate on the computing environment 1810, video datasets, image data, etc. Memory 1840 can be implemented using any type of volatile or non-volatile memory device, 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, or a combination thereof.

[0244]

[0211] The I / O interface 1850 connects to the processor 1820 and the keyboard, etc. It provides an interface between the click wheel, buttons, and other peripheral interface modules. Buttons include, but are not limited to, a home button, a scan start button, and a scan stop button. The I / O interface 1850 can be coupled with encoders and decoders.

[0245]

[0212] In some embodiments, computing is used to carry out the above method. A non-temporary computer-readable storage medium containing multiple programs, such as those contained in memory 1840, which can be executed by processor 1820 within environment 1810, is also provided. For example, the non-temporary computer-readable storage medium may be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0246]

[0213] A non-temporary computer-readable storage medium has one or more processors. It stores multiple programs that are executed by a computing device, and when these programs are executed by one or more processors, they cause the computing device to perform the motion prediction method described above.

[0247]

[0214] In some embodiments, the computing environment 1810 uses the above method To perform this function, it 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 gate arrays (FPGAs), graphics processing units (GPUs), controllers, microcontrollers, microprocessors, or other electronic components.

[0248]

[0215] Figure 13 shows video blocks coded in parallel according to some implementations of the present disclosure. This block diagram shows an exemplary system 10 for encoding and decoding. 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 can 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, etc. In some implementations, the source device 12 and destination device 14 have wireless communication capabilities.

[0249]

[0216] In some implementations, the destination device 14 is decoded via link 16. Link 16 can receive encoded video data. Link 16 may comprise any type of communication medium or device that can move encoded video data from source device 12 to destination device 14. For example, Link 16 may comprise a communication medium that allows source device 12 to directly transmit encoded video data to 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 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 useful for facilitating communication from source device 12 to destination device 14.

[0250]

[0217] In some other implementations, the encoded video data is output to interface 22 The encoded video data can be transmitted from to the storage device 32. The encoded video data in the storage device 32 can 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), read-only compact disc memory (CD-ROM), flash memory, volatile or non-volatile memory, or other suitable digital storage media for storing encoded video data. In a further example, the storage device 32 may be a so The destination device 14 can be a file server or another intermediate storage device capable of holding encoded video data generated by the storage device 12. The destination device 14 can 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 encoded video data and sending encoded video data to the destination device 14. Examples of file servers include a web server (e.g., a website), a File Transfer Protocol (FTP) server, a Network Attached Storage (NAS) device, or a local disk drive. The destination device 14 can access the encoded video data through any standard data connection, including wireless channels (e.g., wireless fidelity (Wi-Fi) connection), wired connections (e.g., digital subscriber line (DSL), cable modem, etc.), or a combination of both suitable for accessing encoded video data stored on the file server. Transmission of encoded video data from the storage device 32 may be via streaming transmission, download transmission, or a combination of both.

[0251]

[0218] As shown in Figure 13, the source device 12 is a video source. The system includes 18, a video encoder 20, and an output interface 22. The video source 18 may include sources such as video imaging devices, 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 that generates 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 can form a camera phone or video phone. However, the implementation described herein is generally applicable to video coding and is also applicable to wireless and / or wired applications.

[0252]

[0219] Captured video, pre-captured video, or computer-generated video The video may be encoded by a video encoder 20. The encoded video data may be transmitted directly to the destination device 14 via the output interface 22 of the source device 12. The encoded video data may also (or instead) be stored in 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.

[0253]

[0220] The destination device 14 has an input interface 28, a video decoder 30, and This includes a display device 34. The input interface 28 includes a receiver and / or modem that can receive encoded video data via link 16. The encoded video data communicated via link 16 or provided on the storage device 32 may include various syntax elements generated by the video encoder 20 for use by the video decoder 30 in decoding the video data. Such syntax elements may be contained within the encoded video data, which is transmitted over a communication medium, stored on a storage medium, or stored on a file server.

[0254]

[0221] In some implementations, the destination device 14 is an integrated display device, It may include a display device 34, which may be 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 comprise any of a variety of display devices, such as a liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, or another type of display device.

[0255]

[0222] The video encoder 20 and video decoder 30 support VVC, HEVC, MP It may operate in accordance with proprietary or industry standards such as EG-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 may be configured to encode video data according to any of these current or future standards. Similarly, the video decoder 30 of the destination device 14 may be configured to decode video data according to any of these current or future standards.

[0256]

[0223] The video encoder 20 and the video decoder 30 are each suitable for various purposes. The video encoder and / or decoder may be implemented as either an encoder and / or decoder circuit, and may be 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 partially implemented in software, the electronic device may store software instructions in a suitable non-temporary computer-readable medium and use one or more processors to execute the instructions in hardware to perform the video encoding / decoding operations disclosed herein. Each of the video encoder 20 and video decoder 30 may be comprised of one or more encoders or decoders, any of which may be integrated as part of a composite encoder / decoder (CODEC) within their respective devices.

[0257]

[0224] Figure 14 shows an exemplary video encoding by some implementations described in this application. This is a block diagram of D20. The video encoder 20 can perform intra-predictive coding and inter-predictive coding of video blocks within a video frame. Intra-predictive coding reduces or removes spatial redundancy of video data within a particular video frame or picture, depending on spatial predictions. Inter-predictive coding reduces or removes temporal redundancy of video data within adjacent video frames or pictures in a video sequence, depending on temporal predictions. Note that the term "frame" may be used synonymously with the terms "image" or "picture" in the field of video coding.

[0258]

[0225] As shown in Figure 14, the video encoder 20 has a video data memory 40, The video encoder comprises a prediction processing unit 41, a DPB (Decoded Picture Buffer) 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 comprises a motion estimation unit 42, a motion compensation unit 44, a splitting 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 a deblocking filter, can 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 deblocking filter, another in-loop filter, such as a sample-adaptive offset (SAO) filter and / or an adaptive in-loop filter (ALF), may also be used to filter the output of the adder 62. In some examples, the in-loop filter may be omitted, and the decoded video 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.

[0259]

[0226] The video data memory 40 is encoded by the components of the video encoder 20. The video data can be stored in the video data memory 40. This can be obtained, for example, from the video source 18 shown in Figure 13. The DPB64 is a buffer that stores reference video data (e.g., reference frames or pictures) used by the video encoder 20 when encoding the video data (e.g., in intra or interpredictive coding mode). The video data memory 40 and DPB64 can be formed by any of a variety of memory devices. In various examples, the video data memory 40 may be on-chip with the other components of the video encoder 20 or off-chip with respect to those components.

[0260]

[0227] As shown in Figure 14, the division unit 45 within the prediction processing unit 41 is video Upon receiving data, the video data is divided into video blocks. This division may include dividing video frames into slices, tiles (e.g., sets of video blocks), or other larger coding units (CUs) according to a pre-configured division structure, such as the Quad-Tree (QT) structure associated with the video data. A video frame can be considered as a two-dimensional array or matrix of samples with sample values. Samples in the array are sometimes called pixels or pels. The number of samples in the horizontal and vertical (or axis) directions of the array or image determines the size and / or resolution of the video frame. A video frame can be divided into multiple video blocks, for example, by using QT division. A video block can also be considered as a two-dimensional array or matrix of samples with sample values, although it is a smaller dimension than a video frame. The number of samples in the horizontal and vertical (or axis) directions of the video block determines the size of the video block. A video block can be further divided into one or more block divisions or subblocks (which may form blocks again). For example, QT division, binary-tree (BT) division, triple-tree (TT) division, or any combination thereof can be used repeatedly. It should be noted that the terms “block” or “video block” as used herein can refer to a portion of a frame or picture, particularly a rectangular (square or non-square) portion. For example, with reference 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., an Encoded Tree Block (CTB), Encoded Block (CB), Prediction Block (PB), or Translating Block (TB), and / or a subblock.

[0261]

[0228] The prediction processing unit 41 processes the error results (for example, the coding rate and the level of distortion). Based on this, one of several possible predictive coding modes may be selected for the current video block, such as one or more intra predictive coding modes or one of several inter predictive coding modes. The prediction processing unit 41 feeds the resulting intra or inter predictive coding block to the adder 50 to generate a residual block, which is then fed to the adder 62 to reconstruct the coded block for later use as part of a reference frame. The prediction processing unit 41 also provides syntax elements such as motion vectors, intra mode indicators, and syntax information such as division information to the entropy coding unit 56.

[0262]

[0229] To select the appropriate intra predictive coding mode for the current video block, The intra-prediction processing unit 46 within the measurement 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 being coded, in order to provide spatial predictions. The motion estimation unit 42 and motion compensation unit 44 within the prediction processing unit 41 perform inter-predictive coding of the current video block for one or more predicted blocks in one or more reference frames, in order to provide temporal predictions. The video encoder 20 may perform multiple coding passes to select an appropriate coding mode for each block of video data, for example. Cut.

[0263]

[0230] In some implementations, the motion estimation unit 42 generates motion vectors. The interprediction mode of the current video frame is determined by this, which indicates 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 can specify the video frames in the sequence as P frames or B frames. The intraBC unit 48 can determine vectors for intraBC encoding, such as block vectors, in a similar manner to how the motion estimation unit 42 determines the motion vectors for interprediction, or it can determine the block vectors using the motion estimation unit 42.

[0264]

[0231] The predicted block of the video block is the video block encoded in terms of pixel difference. This may be a block or reference block of the reference frame that is considered to closely match, or may correspond to them, which may be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics. In some implementations, the video encoder 20 can calculate the values ​​of pixel positions of the reference frame stored in the DPB64 that are less than an integer. For example, the video encoder 20 can interpolate the values ​​of quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Thus, the motion estimation unit 42 can perform motion search on all pixel positions and fractional pixel positions and output motion vectors with fractional pixel precision.

[0265]

[0232] The motion estimation unit 42 determines the position of the video block based on the first reference frame sill. The motion vector of a video block in the interpredictive coded frame is calculated by comparing it with the position of the predicted block in a reference frame selected from the first (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 transmits the calculated motion vector to the motion compensation unit 44, and then to the entropy coding unit 56.

[0266]

[0233] Motion compensation performed by motion compensation unit 44 is performed by motion estimation unit 42 This may include fetching or generating a prediction block based on the motion vector determined by the motion compensation unit 44. Upon receiving the motion vector of the current video block, the motion compensation unit 44 may identify the prediction block pointed to by the motion vector in one of the reference frame lists, retrieve that prediction block from the DPB 64, and transfer that 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 luminance difference components or saturation difference components, or both. The motion compensation unit 44 may also generate syntax elements associated with the video block of the video frame, which are used by the video decoder 30 when decoding the video block of the video frame. Syntax elements may include, for example, syntax elements that define the motion vector used to identify the prediction block, any flags indicating the prediction mode, or any other syntax information described herein. Note that the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are shown separately for conceptual purposes.

[0267]

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

[0268]

[0235] In another example, the intraBC unit 48 is the motion estimation unit 42 and motion The compensation unit 44 can be used in whole or in part to perform such functions for intra-block copy prediction according to the implementations described herein. In either case, for intra-block copies, the predicted block may be a block that is considered to closely match the encoded block in terms of pixel difference, which can be determined by SAD, SSD, or other difference metrics, and the identification of the predicted block may include the calculation of pixel position values ​​less than integers.

[0269]

[0236] Whether the predicted block is from the same frame according to the intra prediction, The video encoder 20 can form a residual video block by subtracting the pixel values ​​of the predicted block from the pixel values ​​of the currently encoded video block, thereby forming a pixel difference value, which may be from different frames according to the predictor. The pixel difference value that forms the residual video block may include both luminance component differences and saturation component differences.

[0270]

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

[0271]

[0238] The prediction processing unit 41 uses interpretation or intraprediction to determine the current video After determining the prediction block of the oblock, the adder 50 predicts from the current video block. A residual video block is formed by subtracting blocks. The residual video data within 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.

[0272]

[0239] The conversion processing unit 52 then sends the resulting conversion coefficients to the quantization unit 54. The data can be transmitted. The quantization unit 54 further reduces the bit rate by quantizing the conversion coefficients. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be changed by adjusting the quantization parameters. In some examples, the quantization unit 54 may perform a scan of the matrix containing the quantization conversion coefficients. Alternatively, the entropy coding unit 56 may perform the scan.

[0273]

[0240] Following quantization, the entropy coding unit 56 uses the following to perform quantum The conversion coefficients are entropically encoded into the video bitstream. Examples include context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), stochastic interval-partitioned entropy (PIPE) coding, or other entropy coding methods or techniques. The encoded bitstream can then be 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 the video decoder 30 or retrieval by the video decoder 30. The entropy coding unit 56 can also entropically encode the motion vector and other syntax elements of the current video frame being encoded.

[0274]

[0241] The inverse quantization unit 58 and the inverse transformation processing unit 60 each perform inverse quantization. The motion compensation unit 44 applies an inverse transform to reconstruct the residual video block in the pixel region to generate a reference block for predicting other video blocks. As described above, the motion compensation unit 44 can generate a motion-compensated prediction block from one or more reference blocks of frames stored in the DPB64. The motion compensation unit 44 can also apply one or more interpolation filters to the prediction block to compute pixel values ​​less than integers for use in motion estimation.

[0275]

[0242] The adder 62 generates the reconstructed residual block by the motion compensation unit 44. The created motion compensation prediction block is added to generate a reference block for storage in the DPB64. The reference block can then be used by the intraBC unit 48, the motion estimation unit 42, and the motion compensation unit 44 as a prediction block to interpret another video block in a subsequent video frame.

[0276]

[0243] Figure 15 shows an exemplary video decoder 30 in several implementations of the present application. This is a block diagram. The video decoder 30 comprises 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 comprises a motion compensation unit 82, an intra-prediction unit 84, and an intra-BC unit 85. The video decoder 30 can perform a decoding process that is almost 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 can generate prediction data based on motion vectors received from the entropy decoding unit 80, while the intra-prediction unit 84 can generate prediction data based on an intra-prediction mode indicator received from the entropy decoding unit 80.

[0277]

[0244] In some examples, the video decoder 30 unit implements the implementation of this application. It can be tasked with performing the following. 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 can perform the implementation of the present application 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 predictive processing unit 81, such as the motion compensation unit 82.

[0278]

[0245] The video data memory 79 is decoded by the other components of the video decoder 30. The video data memory 79 can store video data, such as an encoded video bitstream, which is to be encoded. The video data stored in the video data memory 79 can 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 the 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 an encoded picture buffer (CPB) that stores encoded video data from an encoded video bitstream. The DPB 92 of the video decoder 30 stores reference video data used by the video decoder 30 when decoding the video data (e.g., in intra or inter-predictive encoding mode). The video data memory 79 and DPB 92 may be formed by any of various memory devices, including dynamic random access memory (DRAM), synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and DPB 92 are shown in Figure 15 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.

[0279]

[0246] During the decoding process, the video decoder 30 encodes the video frames. The video decoder 30 receives an encoded video bitstream representing the lock and associated syntax elements. The video decoder 30 can receive syntax 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 quantization coefficients, motion vectors or intra-predictive mode indicators, and other syntax elements. The entropy decoding unit 80 then transfers the motion vectors or intra-predictive mode indicators and other syntax elements to the prediction processing unit 81.

[0280]

[0247] Video frame as intra predictive coding (I) frame or other type When encoded as an intra-coded prediction block of a 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 transmitted intra-prediction mode and reference data from previously decoded blocks of the current frame.

[0281]

[0248] Video frames are interpredictively coded (i.e., B or P) as frames When encoded, the motion compensation unit 82 of the prediction processing unit 81 generates one or more prediction blocks for the video block of the current video frame based on the motion vector and other syntax elements received from the entropy decoding unit 80. Each prediction block may be generated from a reference frame in one of the reference frame lists. The video decoder 30 uses the reference frame stored in the DPB 92 to determine the prediction block. Using the technique of constructing a font, the reference frame list, list 0, and list 1 can be constructed.

[0282]

[0249] In some examples, the video block is an intraBC model as described herein. When encoded according to the code, the intraBC unit 85 of the prediction processing unit 81 generates a predicted block for the current video block based on the block vector and other syntax elements received from the entropy decoding unit 80. The predicted block may be within the same reconfigured region of the picture as the current video block set by the video encoder 20.

[0283]

[0250] Motion compensation unit 82 and / or intra BC unit 85 are motion vector The motion compensation unit 82 determines the prediction information for the video blocks of the current video frame by analyzing the Toll and other syntax elements, and then uses the prediction information to generate the prediction blocks for the current video block being decoded. For example, the motion compensation unit 82 uses some of the received syntax elements to determine the prediction mode used to encode the video blocks of the video frame (e.g., intra-prediction or inter-prediction), the inter-prediction frame type (e.g., B or P), structural information of one or more reference frame lists of the frame, the motion vector for each inter-prediction encoded video block of the frame, the inter-prediction status for each inter-prediction encoded video block of the frame, and other information for decoding the video blocks in the current video frame.

[0284]

[0251] Similarly, the intra BC unit 85 receives a portion of the syntax elements, for example For example, a flag may be used to determine that the current video block was predicted using intraBC mode, and the configuration information of the video block of the frame should be stored in the reconstruction area, including the DPB92, the block vector of each intraBC predicted video block in the frame, the intraBC prediction status of each intraBC predicted video block in the frame, and other information for decoding the video block in the current video frame.

[0285]

[0252] The motion compensation unit 82 also performs video encoding during video block encoding. Interpolation can also be performed using the interpolation filter used by 20, and interpolation values ​​can be calculated for pixels of the reference block that are less than an integer. In this case, the motion compensation unit 82 can determine the interpolation filter to be used by the video encoder 20 from the received syntax elements and use that interpolation filter to generate the predicted block.

[0286]

[0253] The inverse quantization unit 86 determines the degree of quantization within the video frame. The quantization transformation coefficients provided in the bitstream and entropy-decoded by the entropy decoding unit 80 are inversely quantized using the same quantization parameters calculated by the video encoder 20 for each video block. 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 to reconstruct the residual blocks in the pixel region.

[0287]

[0254] Motion compensation unit 82 or intra BC unit 85 is vector and other After generating a predicted block of the current video block based on syntax 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 the intraBC unit 85. In-loop filters 91, such as a deblocking filter, SAO filter, and / or ALF, can be placed between the adder 90 and the DPB 92 for further processing of the decoded video block. In some examples, the in-loop filters 91 may be omitted, and the decoded video block may be provided directly to the DPB 92 by the adder 90. Next, within a given frame... The decoded video blocks are stored in the DPB92, which stores reference frames used for subsequent motion compensation in the next video block. The DPB92, or a separate memory device, can also store the decoded video for later display on a display device, such as the display device 34 in Figure 13.

[0288]

[0255] The descriptions in this disclosure are provided for illustrative purposes only and are not exhaustive. This disclosure is not intended to be limited to, or to any other extent. A number of 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.

[0289]

[0256] The examples illustrate the principles of the present disclosure and will be useful to others skilled in the art in various implementations. To facilitate understanding of the disclosure, the underlying principles and various implementations have been selected and explained in order to make the most of them, with various modifications to suit the specific intended use. Therefore, it should 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 also intended to be included within the scope of this disclosure.

Claims

1. A method for video decoding of multipurpose video coding (VVC), A step of receiving an enable flag for the inverted coordinates of the final significance coefficient of the SPS, which indicates whether the flag for the inverted coordinates of the final significance coefficient of the slice header (SH) exists in the slice header syntax structure that references the sequence parameter set (SPS), A step of receiving an enable flag for the inverted coordinates of the final significance coefficient of the General Constraint Information (GCI) syntax, wherein when the value of the enable flag for the inverted coordinates of the final significance coefficient of the GCI is equal to 1, the value of the enable flag for the inverted coordinates of the final significance coefficient of the SPS becomes equal to 0. A method that includes [a certain feature].

2. In response to the determination that the value of the activation flag for the inverted coordinate of the final significance coefficient of the SPS is equal to 1, the step of determining that the flag for the inverted coordinate of the final significance coefficient of the SH exists in the slice header syntax structure that references the SPS, A method for video decoding according to claim 1, further comprising the step of determining, in response to the determination that the value of the enable flag for the inverted coordinates of the final significance coefficient of the SPS is equal to 0, that the flag for the inverted coordinates of the final significance coefficient of the SH does not exist in the slice header syntax structure that references the SPS.

3. The method for video decoding according to claim 1, wherein the bit depth of the video data is 11.

4. The method for video decoding according to claim 1, wherein the bit depth of the video data is 12.

5. A method for video decoding of multipurpose video coding (VVC), The steps include receiving a Sequence Parameter Set (SPS) high-throughput flag indicating whether syntax elements in residual coding are coded through bypass mode, In response to the determination that the value of the SPS high-throughput flag is equal to 1, the steps include determining that all syntax elements in the residual coding are coded in bypass mode, except for the final significance coefficient position of the normal residual coding (RRC), and that alignment is performed after the final significance coefficient position of the RRC and at the beginning of the transform block (TB) of the transform skip residual coding (TSRC), A step of receiving a GCI high-throughput flag in the General Constraint Information (GCI) syntax, wherein if the value of the GCI high-throughput flag is equal to 1, the value of the SPS high-throughput flag becomes equal to 0. A method that includes [a certain feature].

6. A method for video encoding using multipurpose video coding (VVC), A step of signaling an enable flag for the inverted coordinates of the final significance coefficient of the SPS, which indicates whether the flag for the inverted coordinates of the final significance coefficient of the slice header (SH) exists in the slice header syntax structure that references the sequence parameter set (SPS), A step of signaling an enable flag for the inverted coordinates of the final significance coefficient of the General Constraint Information (GCI) syntax, wherein when the value of the enable flag for the inverted coordinates of the final significance coefficient of the GCI is equal to 1, the value of the enable flag for the inverted coordinates of the final significance coefficient of the SPS becomes equal to 0. A method that includes [a certain feature].

7. When the value of the activation flag for the inverted coordinates of the final significance coefficient of the SPS is equal to 1, the value of the activation flag for the inverted coordinates of the final significance coefficient of the SPS indicates that the flag for the inverted coordinates of the final significance coefficient of the SH exists in the slice header syntax structure that references the SPS. The method for video coding according to claim 6, wherein when the value of the enable flag for the inverted coordinates of the final significance coefficient of the SPS is equal to 0, the value of the enable flag for the inverted coordinates of the final significance coefficient of the SPS indicates that the flag for the inverted coordinates of the final significance coefficient of the SH does not exist in the slice header syntax structure that references the SPS.

8. The method for video encoding according to claim 6, wherein the bit depth of the video data is 11.

9. The method for video encoding according to claim 6, wherein the bit depth of the video data is 12.

10. A method for video encoding using multipurpose video coding (VVC), A step of signaling a sequence parameter set (SPS) high-throughput flag indicating whether syntax elements in residual coding are coded through bypass mode, wherein the value of the SPS high-throughput flag is equal to 1, indicating that all syntax elements in residual coding are coded in bypass mode, except for the final significance coefficient position of normal residual coding (RRC), and alignment is performed after the final significance coefficient position of RRC and at the beginning of the transform block (TB) of transform skip residual coding (TSRC). A step of transmitting a GCI high-throughput flag in the General Constraint Information (GCI) syntax, wherein when the value of the GCI high-throughput flag is equal to 1, the value of the SPS high-throughput flag becomes equal to 0. A method that includes [a certain feature].

11. One or more processors, A memory configured to store instructions executable by one or more processors, An apparatus for video coding, wherein the one or more processors are configured to perform the method according to any one of claims 1 to 10 when executing the instructions.

12. A non-temporary computer-readable storage medium for video decoding that stores computer-executable instructions, When the instruction is executed by one or more computer processors, the one or more computer processors will: The method described in any one of claims 1, 2, and 5 is performed on the bitstream, or A non-temporary computer-readable storage medium for generating a bitstream by performing the method described in any one of claims 6, 7, and 10, and for storing the generated bitstream.

13. The non-temporary computer-readable storage medium according to claim 12, wherein the bit depth of the video data is 11.

14. The non-temporary computer-readable storage medium according to claim 12, wherein the bit depth of the video data is 12.

15. A computer program comprising instructions for execution by a computing device having one or more processors, wherein when the instructions are executed by the one or more processors, the computing device shall Perform the method described in any one of claims 1 to 5 on the bitstream, or A computer program that generates a bitstream by performing the method described in any one of claims 6 to 10, and stores the generated bitstream.

16. A method for storing a bitstream, A step of generating a bitstream by performing the method for video encoding according to any one of claims 6, 7, and 10, The steps include storing the bitstream and A method for providing this.

17. The method according to claim 16, wherein the bit depth of the video data is 11.

18. The method according to claim 16, wherein the bit depth of the video data is 12.

Images