Residual and coefficient coding for video coding

Abstract

Methods, apparatuses and non-transitory computer-readable storage medium for video coding are provided. A method for video coding includes receiving, by a decoder, a sequence parameter set (SPS) range extension flag, indicating whether a syntax structure sps_range_extension is present in a slice header (SH) raw byte sequence payload (RBSP) syntax structure based on a value of the SPS range extension flag.

Description

[0001] This application is a divisional application of the patent application filed on January 25, 2022, with application number 202280012987.1 and invention title "Residual and Coefficient Coding for Video Coding". Cross-references to related applications

[0002] This application is based on and claims priority to provisional application No. 63 / 145,964, filed on February 4, 2021, the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to video coding and compression. Specifically, this disclosure relates to improvements and simplifications in residual and coefficient coding for video coding. Background Technology

[0004] 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 Universal Video Coding (VVC), Joint Explore Test Model (JEM), High Efficiency Video Coding (H.265 / HEVC), High-Level Video Coding (H.264 / AVC), Moving Picture Experts Group (MPEG) coding, and so on. Video coding typically uses prediction methods that utilize redundancy present in video images or sequences (e.g., inter-frame prediction, intra-frame prediction, etc.). A key goal of video coding technology is to compress video data to a lower bitrate while avoiding or minimizing video quality degradation. Summary of the Invention

[0005] Examples of methods and apparatus for video encoding are provided in this disclosure.

[0006] According to a first aspect of this disclosure, a method for video encoding and decoding is provided. The method may include: receiving a Sequence Parameter Set (SPS) range extension flag by a decoder, the SPS range extension flag indicating, based on its value, the presence of a syntax structure `sps_range_extension` in the Stripe Header (SH) Raw Byte Sequence Payload (RBSP) syntax structure.

[0007] According to a second aspect of this disclosure, a method for video encoding and decoding is provided. The method may include: receiving a Sequence Parameter Set (SPS) alignment enable flag by a decoder, the SPS alignment enable flag indicating, based on its value, whether to align the index ivlCurrRange before performing bypass decoding on syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flag.

[0008] According to a third aspect of this disclosure, a method for video encoding and decoding is provided. The method may include: receiving an extended precision processing flag by a decoder, the extended precision processing flag indicating, based on its value, whether extended dynamic range is employed for transform coefficients and during transform processing.

[0009] According to a fourth aspect of this disclosure, a method for video encoding and decoding is provided. The method may include: receiving a persistent rice adaptive enable flag by a decoder, the persistent rice adaptive enable flag indicating, based on its value, whether to initialize rice parameter derivation for abs_maining and dec_abs_level binarization at the beginning of each sub-block, each sub-block employing mode-related statistics accumulated from previous sub-blocks.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the scope of this disclosure. Attached Figure Description

[0011] The accompanying drawings, which are incorporated herein and form part of this specification, are consistent with the present disclosure and, together with the specification, serve to explain the basic principles of the present disclosure.

[0012] Figure 1 This is a block diagram of an encoder based on an example of this disclosure.

[0013] Figure 2 This is a block diagram of a decoder based on an example of this disclosure.

[0014] Figure 3A This is an example of block partitioning in a multi-type tree structure, based on the content of this disclosure.

[0015] Figure 3B This is an example of block partitioning in a multi-type tree structure, based on the content of this disclosure.

[0016] Figure 3C This is an example of block partitioning in a multi-type tree structure, based on the content of this disclosure.

[0017] Figure 3D This is an example of block partitioning in a multi-type tree structure, based on the content of this disclosure.

[0018] Figure 3E This is an example of block partitioning in a multi-type tree structure, based on the content of this disclosure.

[0019] Figure 4This is an example of an image with an 18x12 luminance CTU, based on the content of this disclosure.

[0020] Figure 5 This is an illustration of an image with an 18x12 luminance CTU, as exemplified by the present disclosure.

[0021] Figure 6A This is an illustration of examples of ternary (TT) and binary (BT) partitioning not permitted in VTM, based on examples of this disclosure.

[0022] Figure 6B This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0023] Figure 6C This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0024] Figure 6D This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0025] Figure 6E This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0026] Figure 6F This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0027] Figure 6G This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0028] Figure 6H This is an example illustration of an example of TT and BT partitioning that is not allowed in VTM, based on the content of this disclosure.

[0029] Figure 7 This is an example of a residual encoding / decoding structure for a transform block, based on the content of this disclosure.

[0030] Figure 8 This is an example of a residual codec structure for transforming skip blocks, based on the content of this disclosure.

[0031] Figure 9 This is an example based on the content of this disclosure, illustrating two scalar quantizers.

[0032] Figure 10A This is a diagram illustrating state transitions based on examples of this disclosure.

[0033] Figure 10BThis is a diagram illustrating the quantizer selection based on an example of the content of this disclosure.

[0034] Figure 11 This is an illustration of a template for selecting a probability model based on the contents of this disclosure.

[0035] Figure 12 This is an illustration of an example of a block encoded in a palette pattern according to this disclosure.

[0036] Figure 13 This is an illustration of using a palette predictor to signal palette entries in accordance with this disclosure.

[0037] Figure 14A This is a diagram of a horizontal scan based on the content of this disclosure.

[0038] Figure 14B This is an illustration of a vertical and horizontal scan based on the content of this disclosure.

[0039] Figure 15A This is an illustration of a sub-block-based index map scan for a color palette, based on this disclosure.

[0040] Figure 15B This is an illustration of a sub-block-based index map scan for a color palette, based on this disclosure.

[0041] Figure 16 This is an example of a method for encoding video signals, based on the content of this disclosure.

[0042] Figure 17 This is an example of a method for encoding video signals, based on the content of this disclosure.

[0043] Figure 18 This is a diagram illustrating a computing environment coupled with a user interface, based on examples of this disclosure.

[0044] Figure 19 Based on examples from this disclosure, methods for video encoding and decoding are shown.

[0045] Figure 20 Based on examples from this disclosure, methods for video encoding and decoding are shown.

[0046] Figure 21 Based on examples from this disclosure, methods for video encoding and decoding are shown.

[0047] Figure 22 Based on examples from this disclosure, methods for video encoding and decoding are shown.

[0048] Figure 23 The following is a block diagram illustrating an example system for encoding and decoding video blocks, based on examples of this disclosure.

[0049] Figure 24 This is a block diagram illustrating an exemplary video encoder according to an example of this disclosure.

[0050] Figure 25 This is a block diagram illustrating an exemplary video decoder according to an example of this disclosure. Detailed Implementation

[0051] Reference will now be made in detail to exemplary embodiments, some examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings, wherein the same numerals in different drawings denote the same or similar elements unless otherwise stated. The embodiments set forth in the following description of exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with aspects related to this disclosure, as set forth in the appended claims.

[0052] The terminology used herein is for describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein is intended to represent and cover any one or all possible combinations of one or more of the associated listed items.

[0053] It should be understood that although the terms “first,” “second,” “third,” etc., may be used herein to describe various types of information, such information should not be limited by these terms. These terms are merely used to distinguish information of one category from information of another. For example, without departing from the scope of this disclosure, first information may be referred to as second information; similarly, second information may be referred to as first information. As used herein, the term “if” may be understood, depending on the context, to mean “when,” “once,” or “in response to a judgment.”

[0054] The first version of the HEVC standard was completed in October 2013, offering approximately 50% bitrate savings or equivalent perceptual quality compared to its predecessor, H.264 / MPEG AVC. While HEVC offered significant coding improvements over its predecessor, evidence suggests that even higher coding efficiency can be achieved using additional coding tools. Building on this, both VCEG and MPEG began exploring new coding technologies for future video coding standardization. In October 2015, ITU-T VECG and ISO / IEC MPEG established a Joint Video Exploration Team (JVET) to conduct significant research on advanced technologies that could significantly improve coding efficiency. JVET maintains a reference software called the Joint Exploration Model (JEM) by integrating several additional coding tools on top of the HEVC Test Model (HM).

[0055] In October 2017, the ITU-T and ISO / IEC issued a joint call for proposals (CfP) on video compression exceeding HEVC capabilities. In April 2018, at the 10th JVET meeting, 23 CfP responses were received and evaluated, indicating that compression efficiency was approximately 40% higher than HEVC. Based on these evaluation results, JVET launched a new project to develop a next-generation video coding standard called Multifunctional Video Coding (VVC). That same month, a reference software codebase called the VVC Test Model (VTM) was established to demonstrate a reference implementation of the VVC standard.

[0056] Like HEVC, VVC is built on a block-based hybrid video coding framework.

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

[0058] 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 inter-frame prediction method or an intra-frame prediction method.

[0059] The prediction residual, representing the difference between the current video block (a portion of video input 110) and its predictor (a portion of block predictor 140), is sent from adder 128 to transform 130. The transform coefficients are then sent from transform 130 to quantization 132 for entropy reduction. The quantization coefficients are then fed into entropy coding 138 to generate a compressed video bitstream. Figure 1 As shown, prediction-related information 142 from the intra / inter-frame mode decision 116 (e.g., video block partitioning information, motion vectors (MV), reference picture index, and intra-frame prediction mode) is also fed into the compressed bitstream 144 via entropy coding 138. The compressed bitstream 144 includes the video bitstream.

[0060] In encoder 100, additional circuitry associated with the decoder is required to reconstruct pixels for prediction. First, the prediction residual is reconstructed via inverse quantization 134 and inverse transform 136. This reconstructed prediction residual is combined with block predictor 140 to generate unfiltered reconstructed pixels for the current video block.

[0061] Spatial prediction (or "intra-frame prediction") uses the pixels of samples (called reference samples) from coded neighboring blocks in the same video frame as the current video block to predict the current video block.

[0062] Timing prediction (also known as "inter-frame prediction") uses reconstructed pixels from encoded video pictures to predict the current video block. Timing prediction reduces the inherent temporal redundancy in the video signal. The timing prediction signal for a given coding unit (CU) or coding block is typically transmitted by one or more MVs, which indicate the amount and direction of motion between the current CU and its timing reference. Further, if multiple reference pictures are supported, an additional reference picture index is transmitted, which identifies which reference picture in the reference picture memory the timing prediction signal originates from.

[0063] Motion estimation 114 receives video input 110 and signals from image buffer 120, and outputs motion estimation signals to motion compensation 112. Motion compensation 112 receives video input 110, signals from image buffer 120, and motion estimation signals from motion estimation 114, and outputs motion compensation signals to intra / inter-frame mode decision 116.

[0064] After performing spatial and / or temporal predictions, the intra / inter-frame mode decision 116 in encoder 100 selects the optimal prediction mode, for example, based on a rate-distortion optimization method. Then, block predictor 140 is subtracted from the current video block, and the resulting prediction residuals are decorrelated using transform 130 and quantization 132. The obtained quantization residual coefficients are inversely quantized by inverse quantization 134 and inversely transformed by inverse transform 136 to form the reconstructed residuals, which are then added back to the prediction block to form the reconstructed CU signal. Further loop filtering 122 (e.g., deblocking filter, sample adaptive offset (SAO), and / or adaptive loop filter (ALF)) can be applied to the reconstructed CU before it is placed in the reference picture storage of picture buffer 120 and used for encoding future video blocks. To form the output video bitstream 144, the coding mode (inter-frame or intra-frame), prediction mode information, motion information, and quantized residual coefficients are all sent to entropy coding unit 138 for further compression and packing to form the bitstream.

[0065] Figure 1 A block diagram of a general block-based hybrid video coding system is presented. The input video signal is processed block by block (called a coding unit (CU)). In VTM-1.0, a CU can reach 128x128 pixels. However, unlike HEVC, which partitions blocks solely based on quadtrees, VVC partitions a coding tree unit (CTU) into CUs based on quadtrees / binaries / tritrees to accommodate different local features. By definition, a coding tree block (CTB) is an NxN sample block with a value of N; therefore, partitioning the components into CTBs is a form of partitioning. A CTU includes the CTB of luminance samples from an image with three sample arrays, two corresponding CTBs of chrominance samples, or the CTB of samples from a monochrome image or an image encoded using three separate color planes and syntax structures for coding samples. Furthermore, the concept of multiple partitioning unit types in HEVC is removed; that is, in VVC, there is no longer a separation of CUs, prediction units (PUs), and transform units (TUs); instead, each CU is always used as the basic unit for prediction and transform without further partitioning. In a multi-type tree structure, a CTU is first partitioned using a quadtree structure. Then, the leaf nodes of each quadtree can be further partitioned using binary and ternary tree structures. For example... Figure 3A , 3B As shown in 3C, 3D, and 3E, there are five types of partitioning: quadrilateral partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning.

[0066] Figure 3A According to this disclosure, a diagram is shown for depicting block quaternion partitioning in multi-type tree structures.

[0067] Figure 3B According to this disclosure, a diagram is shown for depicting block vertical binary partitioning in a multi-type tree structure.

[0068] Figure 3C According to this disclosure, a diagram is shown for depicting block-level binary partitioning in a multi-type tree structure.

[0069] Figure 3D According to this disclosure, a diagram is shown for depicting block vertical ternary partitioning in a multi-type tree structure.

[0070] Figure 3E According to this disclosure, a diagram is shown for depicting block-level ternary partitioning in a multi-type tree structure.

[0071] exist Figure 1 In the encoder, spatial prediction and / or temporal prediction can be performed. Spatial prediction (or "intra-frame prediction") uses pixels from samples (called reference samples) of coded adjacent blocks in the same video picture / strip to predict the current video block. Spatial prediction reduces the spatial redundancy inherent in the video signal. Temporal prediction (also known as "inter-frame prediction" or "motion-compensated prediction") uses reconstructed pixels from coded video pictures to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in the video signal. The temporal prediction signal for a given CU is typically represented by one or more motion vectors (MVs) that indicate the amount and direction of motion between the current CU and its temporal reference. Additionally, if multiple reference pictures are supported, an extra reference picture index is sent to identify which reference picture in the reference picture memory the temporal prediction signal comes from. After spatial and / or temporal prediction, a mode decision block in the encoder selects the best prediction mode (e.g., based on rate-distortion optimization methods). The prediction block is then subtracted from the current video block, and the prediction residual is decorrelated and quantized using a transform. The quantized residual coefficients undergo inverse quantization and inverse transform to form the reconstructed residuals, which are then added back to the prediction block to form the reconstructed CU signal. Further loop filtering (e.g., deblocking filter, Sample Adaptive Offset (SAO), and Adaptive Loop Filter (ALF)) can be applied to the reconstructed CU before it is stored in the reference image and used to encode future video blocks. To form the output video bitstream, the coding mode (inter-frame or intra-frame), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit for further compression and packing to form the bitstream.

[0072] Figure 2 A general block diagram of a video decoder for VVC is shown. Specifically, Figure 2A typical block diagram of decoder 200 is shown. Decoder 200 has a bitstream 210, entropy decoding 212, inverse quantization 214, inverse transform 216, adder 218, intra / inter-frame mode selection 220, intra-frame prediction 222, memory 230, loop filter 228, motion compensation 224, image buffer 226, prediction-related information 234, and video output 232.

[0073] Decoder 200 is similar to the one located in Figure 1 The reconstruction-related part is located in the encoder 100. In the decoder 200, the input video bitstream 210 is first decoded by entropy decoding 212 to derive the quantized coefficient levels and prediction-related information. Then, the quantized coefficient levels are processed by inverse quantization 214 and inverse transform 216 to obtain the reconstructed prediction residuals. The block predictor mechanism implemented in the intra / inter-frame mode selector 220 is configured to perform intra-frame prediction 222 or motion compensation 224 based on the decoded prediction information. A set of unfiltered reconstructed pixels is obtained by adding the reconstructed prediction residuals from inverse transform 216 to the prediction output generated by the block predictor mechanism using adder 218.

[0074] Before the reconstructed blocks are stored in the image buffer 226, which serves as a reference image storage, they can be further processed by the loop filter 228. The reconstructed video in the image buffer 226 can be sent to drive the display device, as well as to predict future video blocks. With the loop filter 228 enabled, filtering operations are performed on these reconstructed pixels to derive the final reconstructed video output 232.

[0075] Figure 2 A general block diagram of a block-based video decoder is given. First, at the entropy decoding unit, the video bitstream is entropy-decoded. The coding mode and prediction information are sent to the spatial prediction unit (if intra-frame coding) or the temporal prediction unit (if inter-frame coding) to form prediction blocks. The residual transform coefficients are sent to the inverse quantization unit and the inverse transform unit to reconstruct the residual blocks. The prediction blocks and residual blocks are then added together. Before being stored in the reference image store, the reconstructed blocks may undergo further loop filtering. Finally, the reconstructed video from the reference image store is sent to drive the display device and is used to predict future video blocks.

[0076] Generally speaking, the basic intra prediction scheme used in VVC is the same as that in HEVC, but several modules are further extended and / or improved, such as intra-segmentation (ISP) coding mode, extended intra prediction with wide-angle intra-direction, position-dependent intra prediction combination (PDPC), and 4-tap intra interpolation.

[0077] The division of images, tile groups, tiles, and CTUs in VVC

[0078] In VVC, a tile is defined as a CTU (Covered Unit) representing a rectangular region within a specific tile column and row in an image. A tile group is an integer number of tiles in an image, exclusively contained within a single NAL (Non-Alternating Range) unit. Essentially, the concept of a tile group is the same as that of a stripe defined in HEVC. For example, an image can be divided into tile groups and individual tiles. A tile is a sequence of CTUs covering a rectangular region of the image. A tile group contains multiple tiles of the image. Two tile group modes are supported: raster scan tile group mode and rectangular tile group mode. In raster scan tile group mode, a tile group contains a sequence of tiles from a raster scan of the image. In rectangular tile group mode, a tile group contains multiple tiles of the image that collectively form a rectangular region of the image. The tiles within a rectangular tile group are arranged according to the raster scan order of the tile group.

[0079] Figure 4 An example of raster scan tile grouping for an image is shown, where the image is divided into 12 tiles and 3 raster scan tile groups. Figure 4 This includes tiles 410, 412, 414, 416, and 418. Each tile has 18 CTUs. Specifically, Figure 4 An image with an 18x12 luminance CTU is shown, which is divided into 12 tiles and 3 tile groups (informative). The three tile groups are as follows: (1) the first tile group includes tiles 410 and 412, (2) the second tile group includes tiles 414, 416, 418, 420 and 422, and (3) the third tile group includes tiles 424, 426, 428, 430 and 432.

[0080] Figure 5 An example of rectangular tile grouping of an image is shown, in which the image is divided into 24 tiles (6 tile columns and 4 tile rows) and 9 rectangular tile groups. Figure 5 This includes tiles 510, 512, 514, 516, 518, 520, 522, 524, 526, 528, 530, 532, 534, 536, 538, 540, 542, 544, 546, 548, 550, 552, 554, and 556. Specifically, Figure 5An image with an 18x12 luminance CTU is shown, which is divided into 24 tiles and 9 tile groups (informative). Tile groups contain tiles, and tiles contain CTUs. The 9 rectangular tile groups include: (1) two tiles 510 and 512, (2) two tiles 514 and 516, (3) two tiles 518 and 520, (4) four tiles 522, 524, 534 and 536, (5) four tile groups 526, 528, 538 and 540, (6) four tiles 530, 532, 542 and 544, (7) two tiles 546 and 548, (8) two tiles 550 and 552, and (9) two tiles 554 and 556.

[0081] Large-size transformation with high-frequency zeroing in VVC

[0082] In VTM4, large block size transforms up to 64×64 are enabled, primarily for higher resolution video (e.g., 1080p and 4K sequences). For transform blocks with a size (width or height, or both) equal to 64, high-frequency transform coefficients are zeroed out, thus retaining only low-frequency coefficients. For example, for an M×N transform block, where M is the block width and N is the block height, when M equals 64, only the transform coefficients in the leftmost 32 columns are retained. Similarly, when N equals 64, only the transform coefficients in the first 32 rows are retained. When transform skip mode is used for large blocks, the entire block is used without zeroing out any values.

[0083] Virtual Pipeline Data Unit (VPDU) in VVC

[0084] Virtual Pipeline Data Units (VPDUs) are defined as non-overlapping units in an image. In a hardware decoder, multiple pipeline stages process consecutive VPDUs simultaneously. In most pipeline stages, the VPDU size is roughly proportional to the buffer size, so keeping the VPDU size small is important. In most hardware decoders, the VPDU size can be set to the maximum transform block (TB) size. However, in VVC, ternary tree (TT) and binary tree (BT) partitioning can lead to an increase in VPDU size.

[0085] To maintain the VPDU size at 64×64 luminance samples, the following specification partitioning constraints are applied in VTM5 (modified using syntax signaling):

[0086] CUs with a width or height, or both width and height equal to 128, are not allowed to be split into TT segments.

[0087] For a 128xN CU (i.e., width equal to 128 and height less than 128) where N ≤ 64, horizontal BT is not allowed.

[0088] For Nx128 CUs with N ≤ 64 (i.e., height equal to 128 and width less than 128), vertical BTs are not allowed.

[0089] Figure 6A , 6B 6C, 6D, 6E, 6F, 6G and Figure 6H Examples of TT and BT partitions that are not allowed in VTM are shown.

[0090] Transform coefficient encoding and decoding in VVC

[0091] Transform coefficient encoding and decoding in VVC is similar to HEVC because they both use non-overlapping coefficient groups (also known as CGs or sub-blocks). However, there are some differences between them. In HEVC, each CG of a coefficient has a fixed 4x4 size. In VVC draft 6, the CG size depends on the TB size. Therefore, various CG sizes (1x16, 2x8, 8x2, 2x4, 4x2, and 16x1) are provided in VVC. CGs within a coded block and transform coefficients within a CG are encoded according to a predefined scan order.

[0092] To limit the maximum number of context-coded bits per pixel, the maximum number of context-coded bits (CCB) for a TB is derived using the area of ​​the TB and the type of video components (e.g., luma vs. chroma). The maximum number of context-coded bits is equal to TB_zosize. 1.75. Here, TB_zosize indicates the number of samples within TB after the coefficients are zeroed. It should be noted that coded_sub_block_flag is a flag indicating whether CG contains non-zero coefficients, regardless of CCB counts.

[0093] Coefficient zeroing is an operation performed on a transform block to force coefficients located in a certain region of the transform block to be 0. For example, in the current VVC, the 64x64 transform has an associated zeroing operation. Therefore, transform coefficients located outside the top-left 32x32 region within the 64x64 transform block are forced to be 0. In fact, in the current VVC, for any transform block with a size greater than 32 along a certain dimension, a coefficient zeroing operation is performed along that dimension to force coefficients outside the top-left 32x22 region to be 0.

[0094] In the transform coefficient encoding and decoding in VVC, the variable `remBinsPass1` is first set to the maximum number of allowed context-coded bits (MCCB). During encoding, the variable is reduced by one each time context-coded bits are sent using a signal. When `remBinsPass1` is greater than or equal to 4, coefficients are first sent using the syntaxes `sig_coeff_flag`, `abs_level_gt1_flag`, `par_levelflag`, and `abs_lovel_gt3_flag`, all using context-coded bits in the first channel. In the second channel, the hierarchy information of the remaining coefficients is encoded using the syntax elements of `abs_remainder` with Golomb-Rice code and bypass-coded bits. When `remBinsPass1` becomes less than 4 during encoding in the first channel, the current coefficient is not encoded during encoding in the first channel, but instead, it is directly encoded in the second channel using Golomb-Rice code and bypass-coded bits with the syntax elements of `dec_abs_level`. The derivation process of the `rice` parameter of `dec_abs_level[]` is shown in Table 3. After all the above-described encoding levels, the sign (sign_flag) at all scan positions where sig_coeff_flag equals 1 is finally encoded as bypass bits. Figure 7 The process is described below. For each TB, `remBinsPass1` is reset. A conversion is performed at most once per TB: for `sig_coeff_flag`, `abs_level_gt1_blag`, `par_level_flag`, and `abs_lovel_gt3_flagg`, using context-coded bits to convert to bypass-coded bits for the remaining coefficients. For a coefficient subblock, if `remBinsPass1` is less than 4 before encoding its first coefficient, the entire coefficient subblock is encoded using bypass-coded bits.

[0095] Figure 7 A diagram of the residual encoding / decoding structure used for transform blocks is shown.

[0096] The unified (identical) rice parameter (RicePara) derivation is used for the syntax of signaling abs_remainder and dec_abs_level. The only difference is that the base level will be used for encoding abs_remainder and dec_abs_level. baseLevel The values ​​are set to 4 and 0 respectively. The Rice parameter is determined not only based on the sum of the absolute levels of the five adjacent transform coefficients in the local template, but also based on the corresponding baseline level, as shown below:

[0097] RicePara = RiceParTable[ max(min( 31, sumAbs – 5 baseLevel), 0) ]

[0098] The syntax and related semantics of residual encoding and decoding in the current VVC specification draft are shown in Tables 1 and 2, respectively. Table 1 can also be found in the appendix of the VVC specification. Table 1. Syntax of Residual Encoding and Decoding Table 2. Semantics of Residual Encoding and Decoding Table 3. Derivation of Rice parameters for abs_remainder[] and dec_abs_level[] Table 4. cRiceParam Specification Based on locSumAbs

[0099] Residual encoding and decoding of transform skip mode in VVC

[0100] Unlike HEVC, which uses a single residual encoding / decoding scheme to encode both transform coefficients and transform skip coefficients, VVC employs two separate residual encoding / decoding methods for transform coefficients and transform skip coefficients (i.e., residuals), respectively.

[0101] In transform skip mode, the statistical properties of the residual signal differ from those of the transform coefficients, and no energy compression is observed around the low-frequency components. Modifications to the residual encoding / decoding to account for the different signal characteristics of the (spatial) transform skip residual include:

[0102] The final x / y position is not sent using a signal;

[0103] When all previous flags are equal to 0, except for DC sub-blocks, encode coded_sub_block_flag for each sub-block;

[0104] Contextual modeling of sig_coeff_flag with two adjacent coefficients;

[0105] par_level_flag uses only one context model;

[0106] There are more than 5, 7, or 9 additional flags;

[0107] Derivation of the modified rice parameter for remainder binarization;

[0108] The context modeling of the symbol flag is determined based on the top-left adjacent coefficient value, and the symbol flag is parsed after sig_coeff_flag to put all the context-encoded bits together.

[0109] like Figure 8 As shown, syntax elements sig_coeff_flag , coeff_sign_flag , abs_level_gt1_flag and par_level_flag In the first channel, residual samples are encoded one by one in an interleaved manner, and then in the second channel... abs_level_gtX_flag Bit-plane encoding is performed in the third channel. abs_mainder coding.

[0110] Channel 1: sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, and par_level_flag

[0111] Channel 2: abs_level_gt3_flag, abs_level_gt5_flag, abs_level_gt7_flag, and abs_evel_gt9_flag

[0112] Channel 3: abs_remainder

[0113] Figure 8 A diagram of the residual codec structure used for transforming skip blocks is shown.

[0114] Tables 5 and 2 illustrate the syntax and related semantics of residual encoding / decoding used for transform skip modes in the current VVC draft specification. Table 5 can also be found in the appendix of the VVC specification. Table 5. Syntax for Residual Encoding / Decoding for Transforming Skip Modes

[0115] Quantification

[0116] In the current VVC, the maximum QP value has been expanded from 51 to 63, and the initial QP signal has changed accordingly. When encoding non-zero values ​​of slice_qp_delta, the initial value of SliceQpY can be modified at the slice segment layer. For transform skip blocks, the minimum allowed quantization parameter (QP) is defined as 4 because when QP equals 4, the quantization step size becomes 1.

[0117] Furthermore, the same HEVC scalar quantization is used in conjunction with a new concept called dependent scalar quantization. Dependent scalar quantization refers to a method where the set of permissible reconstructable values ​​for transform coefficients depends on the values ​​of transform coefficient levels preceding the current transform coefficient level in the reconstruction order. The main effect of this method is that, compared to the traditional independent scalar quantization used in HEVC, the permissible reconstructable vectors are compressed more densely in an N-dimensional vector space (where N represents the number of transform coefficients in the transform block). This means that for a given average number of permissible reconstructable vectors per N-dimensional unit volume, the average distortion between the input vector and the most recently reconstructed vector is reduced. The dependent scalar quantization method is implemented by: (a) defining two scalar quantizers with different reconstruction levels, and (b) defining a procedure for switching between the two scalar quantizers.

[0118] exist Figure 9 The two scalar quantizers used are shown (denoted by Q0 and Q1). The position of the available reconstruction level is uniquely specified by the quantization step size Δ. The scalar quantizer (Q0 or Q1) used is signaled non-explicitly in the bitstream. Instead, the quantizer used for the current transform coefficient is determined based on the parity of the transform coefficient level preceding the current transform coefficient in the encoding / reconstruction order.

[0119] Figure 9 A diagram illustrating the two scalar quantizers used in the proposed dependency quantization method is shown.

[0120] like Figure 10A and Figure 10BAs shown, switching between two scalar quantizers (Q0 and Q1) is achieved through a state machine with four quantizer states (QState). QState can take four distinct values: 0, 1, 2, and 3. It is uniquely determined by the parity of the transform coefficient levels preceding the current transform coefficient in the encoding / reconstruction order. At the start of inverse quantization of the transform block, the state is set to 0. The transform coefficients are reconstructed in scan order (i.e., in the same order as entropy decoding). After reconstructing the current transform coefficient, the state is updated as shown in Figure 10, where k represents the value of the transform coefficient level.

[0121] Figure 10A The diagram illustrates the state transitions that depend on quantization.

[0122] Figure 10B A table illustrating the selection of quantizers for the proposed dependent quantization is shown.

[0123] It also supports sending default scaling matrices and user-defined scaling matrices via signals. Default mode scaling matrices are flat, with 16 elements for all TB sizes. IBC and intra-frame coding modes currently share the same scaling matrix. Therefore, for the USER_DEFINED matrix, the number of MatrixType and MatrixType_DC are updated as follows:

[0124] MatrixType: 30 = 2 (intra & IBC / inter = 2) × 3 (Y / Cb / Cr components) × 5 (square TB size: luminance is 4×4 to 64×64, chrominance is 2×2 to 32×32).

[0125] MatrixType_DC: 14 = 2 (intra&IBC / inter is 2 × Y component is 1) × 3 (TB size: 16×16, 32×32, 64×64) + 4 (intra&IBC / inter is 2 × Cb / Cr component is 2) × 2 (TB size: 16×16, 32×32).

[0126] The DC values ​​are encoded for the following scaling matrices: 16×16, 32×32, and 64×64. For TBs smaller than 8×8, all elements of a scaling matrix are signaled. If the TB is larger than or equal to 8×8, only 64 elements of an 8×8 scaling matrix are signaled as the base scaling matrix. To obtain square matrices larger than 8×8, the 8×8 base scaling matrix is ​​upsampled (by copying elements) to the corresponding square size (i.e., 16×16, 32×32, 64×64). When the high-frequency coefficients of the 64-point transform are zeroed, the corresponding high frequencies of the scaling matrix are also zeroed. That is, if the width or height of the TB is greater than or equal to 32, only the left or upper half of the coefficients are retained, and the remaining coefficients are assigned zero. Furthermore, the number of elements signaled for a 64×64 scaling matrix is ​​reduced from 8×8 to three 4×4 submatrices because the bottom right 4×4 element is never used.

[0127] Context modeling for transform coefficient encoding and decoding

[0128] The choice of the probabilistic model for the syntax element associated with the absolute value of the transform coefficient level depends on the value of the absolute level in the local neighborhood or the absolute level of the partial reconstruction. Figure 11 The template used is shown in the image.

[0129] Figure 11 This diagram illustrates the template used to select the probabilistic model. The black square indicates the current scan position, and the square with an "x" represents the local neighborhood used.

[0130] The chosen probabilistic model depends on the sum of the absolute levels (or partially reconstructed absolute levels) in the local neighborhood and the number of absolute levels greater than 0 in the local neighborhood (given by the number of sig_coeff_flags equal to 1). Context modeling and binarization depend on the following metrics of the local neighborhood:

[0131] numSig: The number of non-zero levels in the local neighborhood;

[0132] sumAbs1: The sum of the absolute levels (absLevel1) of the partially reconstructed parts in the local neighborhood after the first pass;

[0133] sumAbs: The sum of the reconstructed absolute levels in the local neighborhood;

[0134] Diagonal position (d): The sum of the horizontal and vertical coordinates of the current scan position within the transform block.

[0135] Based on the values ​​of numSig, sumAbs1, and d, select the probabilistic model for encoding sig_coeff_flag, abs_level_gt1_flag, par_levelflag, and abs_lovel_gt3_flag. Based on the values ​​of sumAbs and numSig, select the Rice parameter for binarizing abs_remainer and dec_abs_level.

[0136] In the current VVC, the simplified 32-point MTS (also known as RMTS32) is based on skipping high-frequency coefficients to reduce the computational complexity of 32-point DST-7 / DCT-8. Furthermore, it is accompanied by coefficient encoding changes, including all types of zeroing (i.e., the existing zeroing of high-frequency components in RMTS32 and DCT2). Specifically, binarization of the last non-zero coefficient position encoding is encoded based on a reduced TU size, and the context model selection for encoding the last non-zero coefficient position is determined by the original TU size. Additionally, 60 context models are used to encode the sig_coeff_flag of the transform coefficients. The selection of the context model index is based on the sum of the maximum value in the five previously reconstructed absolute levels called locSumAbsPass1 and the state dependent on the quantization QState, as follows:

[0137] If cIdx equals 0, then the derivation of ctxInc is as follows: ctxInc = 12 Max(0, QState – 1) + Min( ( locSumAbsPass1 + 1 ) >> 1, 3 ) + ( d < 2 ? 8 : ( d < 5 ?4 : 0 ) )

[0138] Otherwise (cIdx is greater than 0), ctxInc is derived as follows: ctxInc = 36 + 8 Max(0, QState - 1) + Min( ( locSumAbsPass1 + 1 ) >> 1, 3 ) + ( d < 2 ? 4 : 0 )

[0139] Palette mode

[0140] The basic idea behind the palette pattern is that samples in a CU are represented by a small set of representative color values. This set is called the palette. Color values ​​excluded from the palette can also be indicated by sending color values ​​as escape colors, for which the values ​​of the three color components are directly represented as signals in the bitstream. This is in... Figure 12 As shown in the image.

[0141] Figure 12 An example of a block encoded in a palette pattern is shown. Figure 12 This includes 1210 and 1220 color palettes encoded in a palette pattern.

[0142] exist Figure 12 In this context, the palette size is 4. The first three samples are reconstructed using palette entries 2, 0, and 3, respectively. Blue samples represent escape symbols. The CU level flag `palette_escape_val_present_flag` indicates whether an escape symbol exists in the CU. If an escape symbol exists, the palette size is increased by one, and the last index is used to indicate the escape symbol. Therefore, in Figure 12 In the middle, index 4 is assigned to the escape symbol.

[0143] For decoding palette-encoded blocks, the decoder needs the following information:

[0144] Palette table;

[0145] Palette index.

[0146] If the palette index corresponds to an escape symbol, additional overhead is sent using signaling to indicate the corresponding color value of the sample.

[0147] In addition, on the encoder side, it is necessary to export a suitable color palette for use with the CU.

[0148] For the derivation of the lossy encoded palette, an improved k-means clustering algorithm is used. The first sample from a block is added to the palette. Then, for each subsequent sample from that block, the sum of absolute differences (SAD) between the sample and each color in the current palette is calculated. If the distortion of each component is less than a threshold corresponding to the minimum SAD of the palette entry, the sample is added to the cluster belonging to that palette entry. Otherwise, the sample is added as a new palette entry. When the number of samples mapped to a cluster exceeds the threshold, the center of that cluster is updated and becomes the palette entry for that cluster.

[0149] In the next step, the clusters are sorted in descending order of usage. Then, the palette entry corresponding to each entry is updated. Typically, the cluster center is used as the palette entry. However, to account for the cost of encoding palette entries, rate-distortion analysis is performed to analyze whether any entry from the palette predictor is more suitable as the updated palette entry than the cluster center. This process continues until all clusters are processed or the maximum palette size is reached. Finally, if a cluster has only one sample and the corresponding palette entry is not in the palette predictor, that sample is converted to an escape symbol. Additionally, duplicate palette entries are removed, and their clusters are merged.

[0150] After palette derivation, each sample in the block is assigned the index of the nearest (SAD) palette entry. The sample is then assigned to either 'INDEX' or 'COPY_ABOVE' mode. For each sample, either 'INDEX' or 'COPY_ABOVE' mode can be used. The cost of the encoding mode is then calculated. The mode with the lower cost is selected.

[0151] For encoding palette entries, maintain the palette predictor. The maximum size of the palette and the palette predictor are signaled in the SPS. The palette predictor is initialized at the beginning of each CTU line, each strip, and each tile.

[0152] For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette. This is in Figure 13 As shown in the image.

[0153] Figure 13 This demonstrates the use of a palette predictor to signal palette entries. Figure 13 This includes the previous color palette 1310 and the current color palette 1320.

[0154] The reuse flag is sent using zero-run-length encoding. Then, the number of new palette entries is signaled using zero-order exponent Golomb code. Finally, the component values ​​of the new palette entries are signaled.

[0155] The palette index is encoded using horizontal and vertical transverse scanning, such as... Figure 14A and 14B As shown. Using palette_transpose_flag, the scan order is explicitly signaled in the bitstream.

[0156] Figure 14A A horizontal scan is shown.

[0157] Figure 14B A vertical horizontal scan is shown.

[0158] For the encoding of the palette index, a palette mode based on line coefficient groups (CG) is used. This mode divides the CU into multiple segments with 16 samples based on a traversal scan pattern, such as... Figure 15A and Figure 15B As shown, for each CG, the index run, palette index value, and escape mode quantized color are encoded / parsed sequentially.

[0159] Figure 15A A sub-block-based index graph scan for a color palette is shown.

[0160] Figure 15B A sub-block-based index graph scan for a color palette is shown.

[0161] Palette indices are encoded using two primary palette sample modes, 'INDEX' and 'COPY_ABOVE'. As previously described, an index equal to the maximum palette size is assigned to the escape symbol. In 'COPY_ABOVE' mode, the palette index of the sample in the previous row is copied. In 'INDEX' mode, the palette index is explicitly sent by signal. The encoding order of the palette run encoding in each segment is as follows:

[0162] For each pixel, a context-coded binary bit `run_copy_flag=0` is signaled, indicating whether the pixel has the same pattern as the previous pixel; that is, whether both the previously scanned pixels and the current pixel are of run type `COPY_ABOVE`, or whether both the previously scanned pixels and the current pixel are of run type `INDEX` and have the same index value. Otherwise, `run_copy_flag=1` is signaled.

[0163] If a pixel's pattern differs from the previous pixel's, a context-coded binary bit, `copy_above_palette_indices_flag`, is sent, indicating the pixel's running type (i.e., INDEX or COPY_ABOVE). If the sample is in the first row (horizontal traversal scan) or the first column (vertical traversal scan), the decoder does not need to resolve the running type because the INDEX mode is used by default. Furthermore, if the previously resolved running type was COPY_ABOVE, the decoder does not need to resolve the running type. After a period of pixel encoding is performed on the palette, the index values ​​of the INDEX mode (palette_idx_idc) and the quantization escape color (paletter_escape_val) are bypassed and encoded.

[0164] Improvements in residual and coefficient coding

[0165] In VVC, when encoding transform coefficients, a uniform (identical) rice parameter (RicePara) derivation is used to send the syntax for abs_remainder and dec_abs_level signals. The only difference is the base level for abs_remainder and dec_abs_level encoding. baseLevel They are set to 4 and 0 respectively. The Rice parameter is determined not only based on the sum of the absolute levels of the five adjacent transform coefficients in the local template, but also based on the corresponding base level, as shown below:

[0166] RicePara = RiceParTable[ max(min( 31, sumAbs – 5 baseLevel), 0) ]

[0167] In other words, the binary codewords for the syntax elements `abs_remainder` and `dec_abs_level` are adaptively determined based on the level information of adjacent coefficients. Since this codeword determination is performed on a per-sample basis, additional logic is required to handle this codeword adaptation for coefficient encoding.

[0168] Similarly, when encoding residual blocks in transform skip mode, syntax elements are adaptively determined based on the level information of adjacent residual samples. abs_remainder The binary codeword.

[0169] Furthermore, when encoding syntax elements related to residual encoding / decoding or transform coefficient encoding / decoding, the choice of probabilistic model depends on the level information of adjacent levels, which requires additional logic and additional context models.

[0170] In the current design, the escape sample points are binarized by calling a third-order Exp-Golomb binarization process. Its performance has room for further improvement.

[0171] In the current VVC, two different level mapping schemes are available, applied to rule transformations and transform skipping, respectively. Each level mapping scheme is associated with different conditions, mapping functions, and mapping positions. For blocks with rule transformations applied, a level mapping scheme is used after the number of context-coded bits (CCB) exceeds the limit. Table 2 shows the derivation of the mapping position (denoted as ZeroPos[n]) and the mapping result (denoted as AbsLevel[xC][yC]). For blocks with transform skipping applied, another level mapping scheme is used before the number of context-coded bits (CCB) exceeds the limit. Table 5 shows the derivation of the mapping position (denoted as predCoeff) and the mapping result (denoted as AbsLevel[xC][yC]). From a standardization perspective, this non-uniform design may not be optimal.

[0172] For HEVC configuration files exceeding 10 bits, setting `extended_precision_processing_flag` to 1 specifies that extended dynamic range is used for coefficient resolution and inverse transform processing. In the current VVC, residual encoding / decoding of transform coefficients or skipping encoding of transforms exceeding 10 bits is reported as a significant performance degradation. There is room for further performance improvement.

[0173] The proposed method

[0174] In this disclosure, several methods are proposed to address the problems mentioned in the section on improvements to residual and coefficient coding. It is worth noting that these methods can be applied individually or in combination.

[0175] According to the first aspect of this disclosure, it is proposed to use a fixed set of binary codewords to encode certain syntax elements (e.g., abs_remainder) in residual encoding and decoding. Different methods can be used to form the binary codewords. Some example methods are listed below.

[0176] First, use the same procedure as currently used in VVC to determine the codeword for abs_remainder, but always choose a fixed rice parameter (e.g., 1, 2, or 3).

[0177] Second, fixed-length binarization.

[0178] Third, truncate Rice binarization.

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

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

[0181] Sixth, finite k-order Exp-Golomb binarization.

[0182] According to a second aspect of this disclosure, it is proposed to use a fixed set of codewords to encode certain syntax elements (e.g., abs_remainder and dec_abs_level) in transform coefficient encoding and decoding. Different methods can be used to form the binary codewords. Some example methods are listed below.

[0183] First, use the same procedure as the one used in the current VVC to determine the codewords for abs_remainder and dec_abs_level, but with a fixed rice parameter (e.g., 1, 2, or 3). The value of baseLevel can still be different for abs_remainder and dec_abs_level used in the current VVC. (For example, set baseLevel to 4 and 0 for encoding abs_remainder and dec_abs_level, respectively).

[0184] Secondly, the same procedure is used as in the current VVC to determine the codewords for abs_remainder and dec_abs_level, but with fixed rice parameters (e.g., 1, 2, or 3). The baseLevel values ​​for abs_remainder and dec_abs_level are chosen to be the same, for example, 0 for both or 4 for both.

[0185] Third, fixed-length binarization.

[0186] Fourth, truncated Rice binarization.

[0187] Fifth, truncate the binary (TB) binarization process.

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

[0189] Seventh, Finite k-order Exp-Golomb binarization

[0190] According to a third aspect of this disclosure, it is proposed to use a single context to encode syntax elements related to residual encoding / decoding or coefficient encoding (e.g., abs_level_gtx_flag), and context selection based on level information from adjacent decoding can be removed.

[0191] According to the fourth aspect of this disclosure, a variable set of binary codewords is proposed for use in residual coding and decoding to encode certain syntax elements (e.g., abs_remainder), and the selection of the binary codeword set is determined based on certain encoding information of the current block (e.g., quantization parameters (QP) associated with TB / CB and / or slices, the prediction mode of the CU (e.g., IBC mode or intra-frame or inter-frame mode) and / or slice type (e.g., I-slice, P-slice, or B-slice)). Different methods can be used to derive this variable set of binary codewords; some example methods are listed below.

[0192] First, it uses the same process as the current VVC used to determine the codeword for abs_remainder, but with different rice parameters.

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

[0194] Third, finite k-order Exp-Golomb binarization. Table 6. Rice parameter determination based on QP value

[0195] The same method explained in the fourth aspect also applies to transform coefficient coding. According to the fifth aspect of this disclosure, a variable set of binary codewords is proposed for encoding certain syntax elements (e.g., abs_remainder and dec_abs_level) in transform coefficient coding and decoding, and the selection of the binary codeword set is determined based on certain coding information of the current block (e.g., quantization parameters (QP) associated with TB / CB and / or stripes, the prediction mode of the CU (e.g., IBC mode or intra-frame or inter-frame mode) and / or stripe type (e.g., I-strip, P-strip, or B-strip)). Similarly, different methods can be used to derive this variable set of binary codewords; some example methods are listed below.

[0196] First, it uses the same process as the current VVC used to determine the codeword for abs_remainder, but with different rice parameters.

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

[0198] Third, finite k-order Exp-Golomb binarization.

[0199] In the methods described above, different rice parameters can be used to derive different sets of binary codewords. For a given residual sample block, the rice parameter used is based on CU QP (denoted as QP). CU) rather than determined by adjacent level information. A specific example is shown in Table 6, where TH1 to TH4 are predefined thresholds satisfying (TH1<TH2<TH3<TH4), and K0 to K4 are predefined rice parameters. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameter from the QP value of the current CU, as shown in Table 6.

[0200] According to the fifth aspect of the present disclosure, a set of parameters and / or thresholds associated with codeword determination for syntax elements used in transform coefficient encoding and decoding and / or transform skip residual encoding and decoding is signaled into the bitstream. When the syntax elements are encoded by an entropy encoder (e.g., arithmetic coding), the determined codewords are used as binary codewords.

[0201] It is worth noting that the set of parameters and / or thresholds may be a complete set or a subset of all parameters and thresholds associated with the codeword determination of the syntax elements. This set of parameters and / or thresholds can be signaled at different levels in the video bitstream. For example, such information can be signaled at the sequence level (e.g., sequence parameter set), picture level (e.g., picture parameter set and / or picture header), slice level (e.g., slice header), coding tree unit (CTU) level, or coding unit (CU) level.

[0202] In one example, the rice parameter for determining the codeword used to encode the abs_remainder syntax in transform skip residual encoding and decoding is signaled in the slice header, picture header, PPS and / or SPS. When a CU is encoded in transform skip mode and the CU is associated with the aforementioned slice header, picture header, PPS and / or SPS, etc., the signaled rice parameter is used to determine the codeword for encoding the abs_remainder syntax.

[0203] According to the sixth aspect of the present disclosure, the set of parameters and / or thresholds associated with codeword determination as shown in the first and second aspects is used for syntax elements of transform coefficient encoding and decoding and / or transform skip residual encoding and decoding. Moreover, different sets can be used depending on whether the current block contains luma residuals / coefficients or chroma residuals / parameters. When the syntax elements are encoded by an entropy encoder (e.g., arithmetic coding), the determined codewords are used as binary codewords.

[0204] In one example, the codewords of the abs_remainder associated with the transform residual encoding / decoding used in the current VVC are used for both the luma and chroma blocks, but the luma and chroma blocks use different fixed rice parameters. (For example, K1 is used for the luma block and K2 is used for the chroma block, where K1 and K2 are integers.)

[0205] According to the seventh aspect of this disclosure, a set of parameters and / or thresholds associated with the determination of codewords for syntax elements used in transform coefficient encoding / decoding and / or transform skip residual encoding / decoding are signaled into a bitstream. Different sets may be signaled for luma and chroma blocks. When the syntax elements are encoded by an entropy encoder (e.g., arithmetic encoding), the determined codewords are used as binary codewords.

[0206] The same approach explained above also applies to escape value encoding in palette mode, such as palette_escape_val.

[0207] According to the eighth aspect of this disclosure, different sets of binary codewords can be derived using different k-order Exp-Golomb binarizations for encoding escape values ​​in palette mode. In one example, for a given block of escape samples, based on the block's QP value (denoted as QP...),... CU This determines the Exp-Golomb parameter used (i.e., the value of k). The same example shown in Table 6 can be used to derive the value of parameter k based on a given QP value for that block. Although four different thresholds (from TH1 to TH4) are listed in this example, the value can be derived based on these thresholds and QP. CU Five different k values ​​(from K0 to K4) are derived, but it's worth noting that this number of thresholds is for illustrative purposes only. In practice, different numbers of thresholds can be used to divide the entire QP value range into different numbers of QP value segments, and for each QP value segment, different k values ​​can be used to derive the corresponding binary codewords for encoding the escape values ​​of blocks encoded in palette mode. It's also worth noting that in practice, the same logic can be implemented in different ways. For example, certain equations or lookup tables can be used to derive the same rice parameters.

[0208] According to the ninth aspect of this disclosure, a set of parameters and / or thresholds associated with determining the codeword for the syntax elements used for escape samples are signaled into a bitstream. When the syntax elements of the escape samples are encoded by an entropy encoder (e.g., arithmetic encoding), the determined codeword is used as a binary codeword.

[0209] It is worth noting that this set of parameters and / or thresholds can be a complete set or a subset of all parameters and thresholds associated with codeword determination for syntax elements. This set of parameters and / or thresholds can be signaled at different levels within the video bitstream. For example, this information can be signaled at the sequence level (e.g., sequence parameter set), picture level (e.g., picture parameter set and / or picture header), stripe level (e.g., stripe header), coding tree unit (CTU) level, or coding unit (CU) level.

[0210] In one example, based on this aspect, the k-th order of Exp-Golomb binarization is used to determine the codewords used to encode the palette_escape_val syntax in palette mode, and the value of k is signaled to the decoder in the bitstream. The value of k can be signaled at different levels, for example, in the stripe header, picture header, PPS and / or SPS, etc. When the CU is encoded in palette mode and the CU is associated with the aforementioned stripe header, picture header, PPS and / or SPS, etc., the signaled Exp-Golomb parameters are used to determine the codewords used to encode the palette_escape_val syntax.

[0211] Coordination of hierarchical mappings used for transforming skip modes and rule transformation modes.

[0212] According to the tenth aspect of this disclosure, the same conditions for applying hierarchical mapping are also applied to transform skip mode and regular transform mode. In one example, it is proposed that hierarchical mapping be applied after the number of context-coded bits (CCB) exceeds the limits of transform skip mode and regular transform mode. In another example, it is proposed that hierarchical mapping be applied before the number of context-coded bits (CCB) exceeds the limits of transform skip mode and regular transform mode.

[0213] According to the eleventh aspect of this disclosure, the same method for deriving the mapping positions in a hierarchical mapping is used in both a transformation skip mode and a rule transformation mode. In one example, it is proposed to apply the method for deriving the mapping positions in a hierarchical mapping used in a transformation skip mode to a rule transformation mode. In another example, it is proposed to apply the method for deriving the mapping positions in a hierarchical mapping used in a rule transformation mode to a transformation skip mode.

[0214] According to the twelfth aspect of this disclosure, the same hierarchical mapping method is applied to both the transform skip mode and the rule transform mode. In one example, it is proposed that the hierarchical mapping function used in the transform skip mode is also applied to the rule transform mode. In another example, it is proposed that the hierarchical mapping function used in the rule transform mode is also applied to the transform skip mode.

[0215] Simplified derivation of Rice parameters in residual encoding and decoding

[0216] According to aspect thirteen of this disclosure, when encoding syntax elements of abs_remainder / dec_abs_level using Golomb-rice codes, it is proposed to derive rice parameters using simple logic (e.g., shift or division operations) instead of lookup tables. According to this disclosure, lookup tables as specified in Table 4 can be removed. In one example, the rice parameter cRiceParam is derived as: cRiceParam = (locSumAbs >> n), where n is a positive number (e.g., 3). It is worth noting that in practice, the same result can be achieved using other different logic (e.g., division by a value equal to the power of 2). An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate the changes, and italic fonts are used to show the deleted content. Table 7. Derivation of Rice parameters

[0217] According to aspect fourteen of this disclosure, it is proposed that when encoding the syntax elements of abs_remainder / dec_abs_level using Golomb-rice codes, fewer adjacent positions should be used to derive the rice parameter. In one example, it is suggested that only two adjacent positions be used to derive the rice parameter when encoding the syntax elements of abs_remainder / dec_abs_level. The corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 8. Derivation of Rice parameters

[0218] In another example, it is proposed that when encoding the syntax elements of abs_remainder / dec_abs_level, only one adjacent position is used to deduce the rice parameter. The corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 9. Derivation of Rice's parameters

[0219] According to the fifteenth aspect of this disclosure, when encoding the syntax elements abs_mainder / dec_abs_level using Golomb rice codes, it is proposed to use different logic to adjust the value of locSumAbs based on the value of baseLevel to derive the rice parameter. In one example, it is expressed as "(locSumAbs - baseLevel 5) The form "alpha + beta" applies additional scaling and offset operations. When the value of alpha is 1.5 and the value of beta is 1, the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 10. Derivation of Rice parameters

[0220] According to the sixteenth aspect of this disclosure, it is proposed to use Golomb-rice codes to remove the trimming operation derived from the rice parameter in the abs_remainder / dec_abs_level syntax elements. An example of the decoding process in the VVC draft according to this disclosure is shown below, where bold and italic fonts illustrate the changes, and italic fonts are used to display the deleted content. Table 11. Derivation of Rice parameters

[0221] Based on currently available information, an example of the decoding process for the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 12. Derivation of Rice parameters

[0222] According to the seventeenth aspect of this disclosure, when encoding the syntax element abs_remainder / dec_abs_level using Golomb-rice codes, it is proposed to change the initial value of locSumAbs from 0 to a non-zero integer in order to derive the rice parameter. In one example, an initial value of 1 is assigned to locSumAbs, and the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate the changes, and italic fonts are used to display the deleted content. Table 13. Derivation of Rice parameters

[0223] According to the eighteenth aspect of this disclosure, it is proposed that when encoding syntax elements of abs_remainder / dec_abs_level using Golomb-rice codes, the maximum value of adjacent positional level values ​​should be used instead of their sum to derive the rice parameter. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 14. Derivation of Rice parameters

[0224] According to aspect nineteen of this disclosure, it is recommended that when encoding the syntax element abs_remainer / dec_abs_level using Golomb-rice codes, the rice parameter be derived based on the relative magnitude of each AbsLevel value in adjacent positions and the base level value. In one example, the rice parameter is derived based on the number of AbsLevel values ​​in adjacent positions that are greater than the base level. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 15. Derivation of Rice parameters

[0225] In another example, the rice parameter is derived based on the sum of (AbsLevel - baseLevel) values ​​of adjacent positions where the AbsLevel value is greater than the base level. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 16. Derivation of Rice parameters

[0226] Based on currently available information, an example of the decoding process for the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 17. Derivation of Rice parameters

[0227] Simplification of layer mapping position derivation in residual encoding and decoding

[0228] According to the twentieth aspect of this disclosure, it is proposed to remove QState from the derivation of ZeroPos[n] so that ZeroPos[n] is derived only from cRiceParam. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts are used to show the deleted content. Table 18. Derivation of Rice parameters

[0229] According to aspect twenty-one of this disclosure, it is proposed to derive ZeroPos[n] based on the value of locSumAbs. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 19. Derivation of Rice's parameters

[0230] According to aspect twenty-two of this disclosure, it is proposed to derive ZeroPos[n] based on the AbsLevel values ​​of adjacent positions. In one example, ZeroPos[n] is derived based on the maximum value among AbsLevel[xC+1][yC] and AbsLevel[xC][yC+1]. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 20. Derivation of Rice parameters

[0231] According to aspect twenty-three of this disclosure, cRiceParam and ZeroPos[n] are derived based on the maximum value of all AbsLevel values ​​at adjacent positions. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts are used to display deleted content. Table 21. Derivation of Rice parameters

[0232] The same method explained above also applies to the derivation of predCoeff in residual encoding and decoding of transform skip modes. In one example, the derivation of the variable predCoeff is as follows:

[0233] predCoeff = Max( absLeftCoeff, absAboveCoeff ) + 1

[0234] Residual encoding and decoding of transform coefficients

[0235] In this disclosure, to address the problems identified in the section on "Improvements in Residual and Coefficient Encoding," methods are provided to simplify and / or further improve existing designs for residual encoding and decoding. Generally, the main features of the techniques proposed in this disclosure are summarized below.

[0236] First, based on the current design, adjust the derivation of the rice parameters used in conventional residual encoding and decoding.

[0237] Secondly, the binary method used in conventional residual encoding and decoding was changed.

[0238] Third, the rice parameter derivation used in conventional residual encoding and decoding was changed.

[0239] Derivation of rice parameters in the current residual codec design

[0240] According to aspect twenty-four of this disclosure, a variable method is proposed for deriving rice parameters when encoding certain syntax elements (e.g., abs_remainder / dec_abs_level) in residual encoding / decoding, and the selection is determined based on certain encoding information of the current block (e.g., quantization parameters or encoding bit depth associated with TB / CB and / or stripe / profile) and / or based on new flags associated with TB / CB / strip / picture / sequence level (e.g., extended_precision_processing_flag). Different methods can be used to derive the rice parameters; some example methods are listed below.

[0241] First, cRiceParam = (cRiceParam<<a) + (cRiceParam> >b) +c, where a, b, and c are positive numbers, for example, {a, b, c} = {1, 0}. It is worth noting that in practice, the same result can be achieved using other different logic (e.g., multiplying by a value equal to the power of 2).

[0242] Second, cRiceParam = (cRiceParam<<a) +b, where a and b are positive numbers, for example {a,b}={1,1}. It is worth noting that in practice, other different logics may be used to achieve the same result (for example, multiplying by a value equal to the nth power of 2).

[0243] Third, cRiceParam = (cRiceParam a) +b, where a and b are positive numbers, for example {a,b}={1.5,0}. It is worth noting that in practice, other different logics may be used to achieve the same result (for example, multiplying by a value equal to the nth power of 2).

[0244] An example of the corresponding decoding procedure based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts are used to show the deleted content. The changes to the VVC draft are shown in bold and italic in Table 22. It is worth noting that the same logic may be implemented differently in practice. For example, certain equations or look-up tables may also be used to derive the same rice parameter according to the BitDepth value of the current CU / sequence. Table 22. Rice parameter derivation procedure

[0245] In another example, when BitDepth is greater than or equal to a predefined threshold (e.g., 10, 11, 12, 13, 14, 15 or 16), the Rice parameter cRiceParam is derived as follows: cRiceParam = (cRiceParam<<a)+(cRiceParam>>b)+c, where a, b and c are positive numbers (e.g., 1). The corresponding decoding procedure based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts are used to show the deleted content. The changes to the VVC draft are shown in bold and italic in Table 23. It is worth noting that the same logic may be implemented differently in practice. For example, certain equations or look-up tables may also be used to derive the same rice parameter according to the BitDepth value of the current CU / sequence. Table 23. Rice parameter derivation procedure

[0246] Binary method in residual coding and decoding for profiles exceeding 10 bits

[0247] According to the twenty-fifth aspect of the present disclosure, it is proposed to use a variable binary codeword set in residual codec to encode certain syntax elements (e.g., abs_remainder / dec_abs_level), and the selection is determined according to certain coding information of the current block (e.g., the quantization parameter or coding bit depth associated with TB / CB and / or slice / profile) and / or according to a new flag associated with the TB / CB / slice / picture / sequence level (e.g., extended_precision_processing_flag). Different methods can be used to derive the variable binary codeword set, and some example methods are listed below.

[0248] 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. According to the specific coding information of the current block (e.g., the quantization parameter or coding bit depth associated with TB / CB and / or slice / profile) and / or according to the syntax element (e.g., rice_parameter_value) associated with the TB / CB / slice / picture / sequence level, the fixed value may be different under different conditions. A specific example is shown in Table 24, where TH1 to TH4 are predefined thresholds satisfying (TH1<TH2<TH3<TH4), and K0 to K4 are predefined rice parameters. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameter according to the BitDepth value of the current CU / sequence, as shown in Table 24.

[0249] Second, fixed-length binarization.

[0250] Third, truncated Rice binarization.

[0251] Fourth, Truncated Binary (TB) binarization procedure.

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

[0253] Sixth, finite k-th order Exp-Golomb binarization. Table 24 . Bit depth-based Rice parameter determination

[0254] In one example, when the new flag (e.g., extended_precision_processing_flag) equals 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). This fixed value may vary under different conditions. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts show the deleted content. Table 25 shows the changes to the VVC draft in bold and italic. Table 25. Derivation of Rice parameters

[0255] In another example, when the new flag (e.g., extended_precision_processing_flag) equals 1, it is recommended to use a fixed value only for the rice parameter when encoding syntax elements of abs_remainder / dec_abs_level. The corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts indicate changes, and italic fonts show deleted content. Table 26 shows the changes to the VVC draft in bold and italic. Table 26. Derivation of Rice Parameters

[0256] In another example, when BitDepth is greater than or equal to a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), the uqfRice parameter cRiceParam is fixed to n, where n is a positive number (e.g., 4, 5, 6, 7, or 8). This fixed value may vary under different conditions. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16). Changes to the VVC draft are shown in bold and italics in Table 27, with bold and italics indicating changes and italics indicating deletions. Table 27. Derivation of Rice Parameters

[0257] In another example, when BitDepth is greater than a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), it is recommended to use a fixed value for the rice parameter only when encoding syntax elements of abs_remainder / dec_abs_level. The corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), with bold and italic fonts indicating changes, and italics used to show deleted content. Table 28 shows the changes to the VVC draft in bold and italics. Table 28. Derivation of Rice Parameters

[0258] Rice parameter derivation in residual encoding and decoding

[0259] According to the twenty-sixth aspect of this disclosure, a variable method for encoding certain syntax elements (e.g., abs_remainder / dec_abs_level) using rice parameter derivation in residual encoding / decoding is proposed, and the choice is determined based on certain encoding information of the current block (e.g., quantization parameters or encoded bit depth associated with TB / CB and / or stripe / brief) and / or based on a new flag associated with TB / CB / strip / picture / sequence level (e.g., extended_precision_processing_flag). Different methods can be used to derive the rice parameters; some example methods are listed below.

[0260] First, a method is proposed to use counters to derive the rice parameter. These counters are determined based on the values ​​of the encoded coefficients and certain encoding information for the current block (e.g., the complex ID). In a specific example, riceParameter = counter / a, where a is a positive number (e.g., 4), it maintains two counters (separated by luma / chroma). At the beginning of each stripe, these counters are reset to 0. Once encoding begins, if this is the first coefficient encoded in the sub-TU, the counters are updated as follows: if (coeffValue>= (3< <rice)) counter++ if (((coeffValue<<1)<(1<<riceParameter))&&(counter> 0)) counter--;

[0261] Second, a shift operation is proposed to be added to the derivation of the rice parameter in VVC. This shift is determined based on the value of the coding coefficients. An example of the corresponding decoding process based on the VVC draft is shown below, where the shift is determined according to the counter of Method 1, with bold and italic fonts indicating changes, and italic fonts showing deleted content. Table 29 shows the changes to the VVC draft in bold and italic. Table 29. Derivation of Rice Parameters

[0262] Third, a shift operation is proposed to be added to the derivation of the rice parameter in VVC. This shift is determined based on the specific encoding information of the current block, such as the encoded bit depth associated with the TB / CB and / or stripe profile (e.g., a 14-bit or 16-bit profile). An example of the corresponding decoding process based on the VVC draft is shown below, where the shift is determined according to the counter of Method 1, with changes indicated in bold and italics, and deleted content displayed in italics. The changes to the VVC draft are shown in bold and italics in Table 30. Table 30. Derivation of Rice Parameters

[0263] Residual encoding and decoding for transform skipping

[0264] According to aspect twenty-seven of this disclosure, it is proposed to use a variable set of binary codewords to encode certain syntax elements (e.g., abs_remainder) in transform skip residual encoding and decoding, and to determine this selection based on certain encoding information of the current block (e.g., quantization parameters or encoding bit depth associated with TB / CB and / or stripe / brief) and / or based on a new flag associated with the TB / CB / strip / picture / sequence level (e.g., extended_precision_processing_flag). Different methods can be used to derive this variable set of binary codewords; some example methods are listed below.

[0265] Second, the same process as the codeword for determining abs_remainder used in the current VVC is used, but a fixed rice parameter (for example, 2, 3, 4, 5, 6, 7 or 8) is always selected. According to certain coding information of the current block (for example, quantization parameter, frame type (for example, I, P or B), component ID (for example, luma or chroma), color format (for example, 420, 422 or 444), or coding bit depth associated with TB / CB and / or slice / profile) and / or according to syntax elements associated with the TB / CB / slice / picture / sequence level (for example, rice_parameter_value), this fixed value may vary under different conditions. A specific example is shown in Table 7, where TH1 to TH4 are predefined thresholds satisfying (TH1<TH2<TH3<TH4), and K0 to K4 are predefined rice parameters. It is worth noting that the same logic may be implemented differently in practice. For example, certain equations or lookup tables may also be used to derive the same rice parameter according to the BitDepth value of the current CU / sequence, as shown in Table 7.

[0266] Second, fixed-length binarization.

[0267] Third, truncated Rice binarization.

[0268] Fourth, Truncated Binary (TB) binarization process.

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

[0270] Sixth, finite k-th order Exp-Golomb binarization.

[0271] An example of the corresponding decoding process based on the VVC draft is shown below, where the changes to the VVC draft are shown in bold and italics in Table 31, and the deleted content is shown in italics. It is worth noting that the same logic may be implemented differently in practice. For example, certain equations or lookup tables may also be used to derive the same rice parameter. Table 31. Rice parameter derivation process

[0272] In another example, when a new flag (for example, extended_precision_processing_flag) is equal to 1, it is proposed to use only one fixed value for the rice parameter when encoding the syntax element of abs_remainder. The corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts show the deleted content. The changes to the VVC draft are shown in bold and italics in Table 32. Table 32. Derivation of Rice Parameters

[0273] In another example, when the new flag (e.g., extended_precision_processing_flag) equals 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). This fixed value may vary under different conditions. An example of the corresponding decoding process based on the VVC draft is shown below, where bold and italic fonts illustrate the changes, and italic fonts show the deleted content. Table 33 shows the changes to the VVC draft in bold and italic fonts. Table 33. Derivation of Rice Parameters

[0274] In another example, when BitDepth is greater than or equal to a predefined 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). This fixed value may vary under different conditions. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), with bold and italic text indicating changes, and italics used to show deleted content. Table 34 shows the changes for the VVC draft in bold and italics. Table 34. Derivation of Rice Parameters

[0275] In another example, a control flag is signaled in the stripe header to indicate whether signaling for the Rice parameter of the transform skip block is enabled or disabled. When the control flag is signaled to enable, a syntax element is further signaled for each transform skip stripe to indicate the Rice parameter for that stripe. When the control flag is signaled to disable (e.g., set to equal to "0"), no further syntax element is signaled at a lower level to indicate the Rice parameter for the transform skip stripe, and the default Rice parameter (e.g., 1) is used for all transform skip stripes. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2), with bold and italic fonts indicating changes, and italic fonts showing deleted content. Changes for the VVC draft are shown in bold and italic in Table 35. It is worth noting that sh_ts_residual_coding_rice_index can be encoded in different ways and / or can have a maximum value. For example, u(n) (an unsigned integer using n binary bits) or f(n) (a fixed-pattern binary string written (from left to right) using n binary bits, with the left binary bit first) can also be used to encode / decode the same syntax element.

[0276] Strip header syntax Table 35. Syntax of Residual Encoding and Decoding

[0277] A value of 1 for `sh_ts_residual_coding_rice_flag` indicates the presence of `sh_ts_sresidual_coding_lice_index` in the current slice. A value of 0 for `sh_ts_residual_coding_rice_flag` indicates its absence in the current slice. If `sh_ts_residual_coding_rice_flag` is absent, it is inferred that the value of `sh_ts_residual_coding_ric_flag` is 0. sh_ts_residual_coding_rice_indiex specifies the rice parameter used in the residual_ts_coding() syntax structure. Table 36. Derivation of Rice Parameters

[0278] In another example, a control flag is signaled in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether the signaling for the Rice parameter of the transform skip block is enabled or disabled. When the control flag is signaled to enable, a syntax element is further signaled for each transform skip stripe to indicate the Rice parameter for that stripe. When the control flag is signaled to disable (e.g., set to equal to "0"), no further syntax elements are signaled at a lower level to indicate the Rice parameter for the transform skip stripe, and the default Rice parameter (e.g., 1) is used for all transform skip stripes. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italics in Table 37, and deletions are shown in italics. It is worth noting that sh_ts_residual_coding_rice_idx can be encoded in different ways and / or can have a maximum value. For example, u(n) (an unsigned integer using n binary bits) or f(n) (a fixed-pattern binary string written (from left to right) using n binary bits, with the left binary bit first) can also be used to encode / decode the same syntax element.

[0279] Sequence Parameter Set RBSP Syntax Table 37. Syntax of Residual Encoding and Decoding

[0280] A value of 1 for `sps_ts_residual_coding_rice_present_in_sh_flag` indicates that `sh_ts_residual_coding_ric_idx` exists in the SH syntax structure referencing SPS. A value of 0 for `sps_ts_residual_coding_rice_present_in_sh_flag` indicates that `sh_ts_residual_coding_ric_idx` does not exist in the SH syntax structure referencing SPS. When `sps_ts_residual_coding_rice_present_in_sh_flag` does not exist, it is inferred that the value of `sps_ts_residual_coding_rice_present_in_sh_flag` is 0.

[0281] Strip header syntax Table 38. Syntax of Residual Encoding and Decoding

[0282] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. Table 39. Derivation of Rice Parameters

[0283] In another example, a syntax element is signaled for each transform skipped strip to indicate the Rice parameter for that strip. An example of the corresponding decoding process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold and italics in Table 40. It is worth noting that sh_ts_residual_coding_rice_idx can be encoded in different ways and / or can have a maximum value. For example, the same syntax element can also be encoded / decoded using u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string written (from left to right) using n bits, with the left bit first).

[0284] Strip header syntax Table 40. Syntax of Residual Encoding and Decoding

[0285] `sh_ts_residual_coding_rice_idx` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `sh_ts_residual_coding_rice_idx` is not present, its value is assumed to be 0. Table 41. Derivation of Rice parameters

[0286] In another example, a control flag is signaled in the picture parameter set range extension syntax to indicate whether signaling for the Rice parameter of the transform skip block is enabled or disabled. When the control flag is signaled to be enabled, a syntax element is further signaled to indicate the Rice parameter for that picture. When the control flag is signaled to be disabled (e.g., set to equal to "0"), no further syntax element is signaled at a lower level to indicate the Rice parameter used for the transform skip strip, and the default Rice parameter (e.g., 1) is used for all transform skip strips. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italics in Table 42. It is worth noting that pps_ts_residual_coding_rice_idx can be encoded in different ways and / or can have a maximum value. For example, u(n) (an unsigned integer using n binary bits) or f(n) (a fixed-pattern binary string written (from left to right) using n binary bits, with the left binary bit first) can also be used to encode / decode the same syntax element.

[0287] Image parameter set range extension syntax Table 42. Syntax of Residual Encoding and Decoding

[0288] A value of 1 for `pps_ts_residual_coding_rice_flag` indicates that `pps_ts_residual_coding_lice_index` exists in the current image. A value of 0 for `pps_ts_residual_coding_rice_idx` indicates that `pps_ts_residual_coding_rice_idx` does not exist in the current image. If `pps_ts_residual_coding_rice_flag` does not exist, it is inferred that the value of `pps_ts_residual_coding_rice_flag` is 0.

[0289] pps_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. Table 43. Derivation of Rice Parameters

[0290] In another example, it is recommended to encode the syntax element `abs_remainder` using only the varying `rice` parameter. The value of the applied `rice` parameter can be determined based on specific encoding information of the current block (e.g., block size, quantization parameters, bit depth, transform type, etc.). In one specific embodiment, it is recommended to adjust the `rice` parameter based on the encoded bit depth and quantization parameters applied to a CU. The corresponding decoding process based on the VVC draft is shown below, with changes to the VVC draft shown in bold and italics in Table 44, and deletions shown in italics. It is worth noting that the same logic can be implemented differently in practice. For example, the same `rice` parameter can also be derived using certain equations or lookup tables. Table 44. Derivation of Rice Parameters

[0291] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 33 or 34). Changes to the VVC draft are shown in bold and italics in Table 45, and deletions are shown in italics. It is worth noting that the same logic can be implemented differently in practice. For example, the same rice parameters can also be derived using certain equations or lookup tables. Table 45. Derivation of Rice Parameters

[0292] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH A and TH B It is a predefined threshold (e.g., TH). A =8,TH B =33 or 34). The changes to the VVC draft are shown in bold and italics in Table 46, and the deleted items are shown in italics. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters. Table 46. Derivation of Rice Parameters

[0293] In another example, when the new flag (e.g., extended_precision_processing_flag) equals 1, it is proposed to encode the syntax elements of abs_remainder using only the changed rice parameter. The value of this change can be determined based on specific encoding information of the current block (e.g., block size, quantization parameters, bit depth, transform type, etc.). In one specific embodiment, it is proposed to adjust the rice parameter based on the encoded bit depth and quantization parameters applied to a CU. The corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold and italics in Table 47. It is worth noting that the same logic can be implemented differently in practice. For example, the same rice parameter can also be derived using certain equations or lookup tables. Table 47. Derivation of Rice Parameters

[0294] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). Changes to the VVC draft are shown in bold and italics in Table 48. It is worth noting that the same logic can be implemented differently in practice. For example, the same rice parameters can also be derived using certain equations or lookup tables. Table 48. Derivation of Rice Parameters

[0295] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH A and TH B It is a predefined threshold (e.g., TH). A =8,TH B =18 or 19). The changes to the VVC draft are shown in bold and italics in Table 49. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters. Table 49. Derivation of Rice Parameters

[0296] Figure 16A method for video encoding is illustrated. This method can be applied, for example, to an encoder. In step 1610, the encoder can receive video input. For example, the video input can be a real-time stream. In step 1612, the encoder can obtain quantization parameters based on the video input. For example, the quantization parameters can be calculated by a quantization unit in the encoder. In step 1614, the encoder can derive rice parameters based on at least one predefined threshold, encoding bit depth, and quantization parameters. For example, rice parameters can be used to signal the syntax of abs_remainder and dec_abs_level. In step 1616, the encoder can entropy encode the video bitstream based on the rice parameters. For example, the video bitstream can be entropy encoded to generate a compressed video bitstream.

[0297] In another example, when BitDepth is greater than 10, it is recommended to use only a fixed value (e.g., 2, 3, 4, 5, 6, 7, or 8) for the rice parameter when encoding the syntax elements of abs_remainder. This fixed value may vary under different conditions depending on the specific encoding information of the current block (e.g., quantization parameters). The corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). Changes to the VVC draft are shown in bold and italics in Table 50. It is worth noting that the same logic can be implemented differently in practice. For example, the same rice parameter can also be derived using certain equations or lookup tables. Table 50. Derivation of Rice Parameters

[0298] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH A and TH B It is a predefined threshold (e.g., TH). A =8,TH B =18 or 19). The changes to the VVC draft are shown in bold and italics in Table 51. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters. Table 51. Derivation of Rice Parameters

[0299] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 33 or 34). Changes to the VVC draft are shown in bold and italics in Table 52. It is worth noting that the same logic can be implemented differently in practice. For example, the same rice parameters can also be derived using certain equations or lookup tables. Table 52. Derivation of Rice Parameters

[0300] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH A and TH B It is a predefined threshold (e.g., TH). A =8,TH B =33 or 34). The changes to the VVC draft are shown in bold and italics in Table 53. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters. Table 53. Derivation of Rice Parameters

[0301] It is worth noting that the formulas used to calculate specific rice parameters in the above explanation are merely examples 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 parameters for the transform skip mode based on the encoded bits and the applied quantization parameters). Furthermore, it should be mentioned that current VVC designs allow for changes to the applied quantization parameters at the block group level. Therefore, the proposed rice parameter adjustment scheme can provide flexible adaptation to the rice parameters for the transform skip mode at the block group level.

[0302] Signaling information used for regular residual encoding / decoding and transform skip residual encoding / decoding

[0303] According to the twenty-eighth aspect of this disclosure, it is proposed to signal the rice parameters of binary codewords (used to encode certain syntax elements (e.g., abs_remainder in transform skip residual encoding and decoding), shift and offset parameters for deriving the rice parameters of abs_remainder / dec_abs_level for regular residual encoding and decoding, and to determine whether to signal based on specific encoding information of the current block (e.g., quantization parameters or encoding bit depth associated with TB / CB and / or stripe / brief) and / or based on a new flag associated with TB / CB / strip / picture / sequence level (e.g., sps_residual_coding_info_present_in_sh_flag).

[0304] In one example, a control flag is signaled in the stripe header to indicate whether signaling for the Rice parameter of the transform skip block is enabled or disabled, as well as signaling for the offset and / or shift parameters used to derive the Rice parameter in the transform block. When the control flag is signaled to enable, a syntax element is further signaled for each transform skip strip to indicate the Rice parameter of that strip, and two syntax elements are further signaled for each transform strip to indicate the offset and / or shift parameters used to derive the Rice parameter of that strip. When the control flag is signaled to disable (e.g., set to equal to "0"), no further syntax elements are signaled at a lower level to indicate the Rice parameter for the transform skip strip, and the default Rice parameter (e.g., 1) is used for all transform skip strips. Similarly, no further syntax elements are signaled at a lower level to indicate the offset and shift parameters used to derive the Rice parameter of the transform strip, and the default offset and / or shift parameters (e.g., 0) are used for all transform strips. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italics in Table 54. 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 differently and / or can have maximum values. For example, the same syntax element can also be encoded / decoded using u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string written (from left to right) using n bits, with the left bit first).

[0305] Figure 17A method for video decoding is illustrated. This method can be applied, for example, to an encoder. In step 1710, the encoder can receive video input. In step 1712, the encoder can send a rice parameter of binary codewords using a signal for encoding syntax elements. The encoded syntax elements may include abs_remainder in transform skip residual encoding / decoding. In step 1714, the encoder can perform entropy encoding on the video bitstream based on the rice parameter and the video input.

[0306] Strip header syntax Table 54. Syntax of Residual Encoding and Decoding

[0307] A value of 1 for `sh_residual_coding_rice_flag` indicates that `sh_resideual_coding_rice_shift`, `sh_residaal_coding_rice_offset`, and `sh_residual_coding_rice_index` exist in the current slice. A value of 0 for `sh_residual_coding_rice_shift`, `sh_residaal_coding_rice_offset`, and `sh_resdial_coding_rice_index` do not exist in the current slice.

[0308] `sh_residual_coding_rice_shift` specifies the shift parameter used in the derivation of the rice parameters for `abs_remainer[]` and `dec_abs_level[]`. When `sh_residual_coding_rice_shift` is not present, the value of `sh_resideal_coding_rice_shift` is inferred to be 0.

[0309] `sh_residual_coding_rice_offset` specifies the offset parameter used in the derivation of the rice parameters for `abs_remainer[]` and `dec_abs_level[]`. When `sh_residual_coding_rice_offset` is not present, the value of `sh_resideal_coding_rice_offset` is inferred to be 0.

[0310] `sh_ts_residual_coding_rice_index` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `sh_ts_residual_coding_rice_index` is not present, its value is assumed to be 0. Table 55. Derivation of Rice Parameters Table 56. Derivation of Rice Parameters

[0311] In another example, a control flag is signaled in the sequence parameter set (or in the sequence parameter set range extension syntax) to indicate whether signaling for enabling or disabling the Rice parameter of the transform skip block, as well as signaling for the offset and / or shift parameters used to derive the Rice parameter in the transform block, is enabled or disabled. When the control flag is signaled to enable, a syntax element is further signaled for each transform skip strip to indicate the Rice parameter of that strip, and two syntax elements are further signaled for each transform strip to indicate the offset and / or shift parameters used to derive the Rice parameter of that strip. When the control flag is signaled to disable (e.g., set to equal to "0"), no further syntax elements are signaled at a lower level to indicate the Rice parameter for the transform skip strip, and the default Rice parameter (e.g., 1) is used for all transform skip strips. No further syntax elements are signaled at a lower level to indicate the offset and shift parameters used to derive the Rice parameter of the transform strip, and the default offset and / or shift parameter (e.g., 0) is used for all transform strips. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italics in Table 57. 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 differently and / or can have maximum values. For example, the same syntax element can also be encoded / decoded using u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string written (from left to right) using n bits, with the left bit first).

[0312] Sequence Parameter Set RBSP Syntax Table 57. Syntax of Residual Encoding and Decoding

[0313] `sps_residual_coding_info_present_in_sh_flag` equal to 1 indicates that `sh_residual_coding_clice_shift`, `sh_resideual_coding_rice_offset`, and `sh_ts_resideural_coding_rice_idx` exist in the SH syntax structure referencing SPS. `sps_residual_coding_info_present_in_sh_flag` equal to 0 indicates that `sh_residual_coding_rice_shift`, `sh_resideual_coding_rice_offset`, and `sh_ts_resideural_coding_rice_idx` do not exist in the SH syntax structure referencing SPS. When `sps_residual_coding_info_present_in_sh_flag` does not exist, it is inferred that the value of `sps_residual_codeing_info_present_insh_flg` is equal to 0.

[0314] Strip header syntax Table 58. Syntax of Residual Encoding and Decoding

[0315] `sh_residual_coding_rice_shift` specifies the shift parameter used in the derivation of the rice parameters for `abs_remainer[]` and `dec_abs_level[]`. When `sh_residual_coding_rice_shift` is not present, the value of `sh_resideal_coding_rice_shift` is inferred to be 0.

[0316] `sh_residual_coding_rice_offset` specifies the offset parameter used in the derivation of the rice parameters for `abs_remainer[]` and `dec_abs_level[]`. When `sh_residual_coding_rice_offset` is not present, the value of `sh_resideal_coding_rice_offset` is inferred to be 0.

[0317] `sh_ts_residual_coding_rice_idx` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `sh_ts_residual_coding_rice_index` is not present, the value of `sh_ts_sresidual_coding_lice_index` is assumed to be 0. Table 59. Derivation of Rice Parameters Table 60. Derivation of Rice Parameters

[0318] In another example, for each transform skipped stripe, a syntax element is signaled to indicate the Rice parameter for that stripe, and for each transform stripe, two syntax elements are signaled to indicate shift and / or offset parameters used to derive the Rice parameter for that stripe. An example of the corresponding decoding process based on the VVC draft is shown below. Changes to the VVC draft are shown in bold and italics in Table 61. 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 differently and / or can have maximum values. For example, the same syntax element can also be encoded / decoded using u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string written (from left to right) using n bits, with the left bit first).

[0319] Strip header syntax Table 61. Syntax of Residual Encoding and Decoding

[0320] `sh_ts_residual_coding_rice_idx` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `sh_ts_residual_coding_rice_idx` is not present, its value is assumed to be 0.

[0321] `sh_residual_coding_rice_offset` specifies the offset parameter used in the derivation of the rice parameters for `abs_remainer[]` and `dec_abs_level[]`. When `sh_residual_coding_rice_offset` is not present, the value of `sh_resideal_coding_rice_offset` is inferred to be 0.

[0322] `sh_ts_residual_coding_rice_idx` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `sh_ts_residual_coding_rice_index` is not present, the value of `sh_ts_residual_coding_ric_index` is assumed to be 0. Table 62. Derivation of Rice Parameters Table 63. Derivation of Rice Parameters

[0323] In another example, a control flag is signaled in the picture parameter set range extension syntax to indicate whether signaling for the Rice parameters of the transform skip block is enabled or disabled, as well as signaling for the offset and / or shift parameters used to derive the Rice parameters in the transform block. When the control flag is signaled to be enabled, a syntax element is further signaled to indicate the Rice parameters used for transform skip residual encoding / decoding of the picture, and two syntax elements are further signaled for regular residual encoding / decoding to indicate the offset and / or shift parameters used to derive the Rice parameters of the picture. When a control flag is signaled to be disabled (e.g., set to equal to "0"), no further signaling syntax elements are used at a lower level to indicate the Rice parameter for transform skip residual coding, and the default Rice parameter (e.g., 1) is used for all transform skip residual coding. Similarly, no further signaling syntax elements are used at a lower level to indicate the offset and / or shift parameters for the Rice parameter used to derive regular residual coding, and the default offset and / or shift 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, where TH is a predefined value (e.g., 0, 1, 2). Changes to the VVC draft are shown in bold and italics in Table 64. 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 differently and / or can have maximum values. For example, u(n) (an unsigned integer using n binary bits) or f(n) (a fixed-pattern binary string written (from left to right) using n binary bits, with the left binary bit first) can also be used to encode / decode the same syntax element.

[0324] Image parameter set range extension syntax Table 64. Syntax of Residual Encoding and Decoding

[0325] A value of 1 for `pps_residual_coding_info_flag` indicates that `pps_sresidual_coding_rice_shift`, `pps_residual_coding_rice_offset`, and `pps_ts_resideual_coding_rice_index` exist in the current image. A value of 0 for `pps_residual_coding_info_flag` indicates that `pps_sresidual_coding_rice_shift`, `pps_residual_coding_rice_offset`, and `pps_ts_resideual_coding_rice_idx` do not exist in the current image. When `pps_residual_coding_info_flag` does not exist, it is inferred that the value of `pps_residual_coding_info_flag` is 0.

[0326] pps_residual_coding_rice_shift specifies the shift parameter used in the derivation of the rice parameters for abs_remainer[] and dec_abs_level[]. When pps_residual_coding_rice_shift is not present, the value of pps_residual_coding_rice_shift is inferred to be 0.

[0327] `pps_residual_coding_rice_offset` specifies the offset parameter used in the derivation of the rice parameters for `abs_remainder[]` and `dec_abs_level[]`. When `pps_residual_coding_rice_offset` is not present, the value of `pps_residual_coding_ric_offset` is inferred to be 0.

[0328] `pps_ts_residual_coding_rice_idx` specifies the `rice` parameter used in the `residual_ts_coding()` syntax structure. If `pps_ts_residual_coding_rice_index` is not present, it is assumed that the value of `pps_ts_residual_coding_rice_index` is 0. Table 65. Derivation of Rice Parameters Table 66. Derivation of Rice Parameters

[0329] According to the twenty-ninth aspect of this disclosure, it is proposed to use different rice parameters to encode certain syntax elements (e.g., abs_remainder in transform skip residual encoding / decoding), to derive shift and offset parameters of the rice parameters for abs_remainder / dec_abs_level for regular residual encoding / decoding, and to determine which syntax element to use based on specific encoding information of the current block (e.g., quantization parameters or encoding bit depth associated with TB / CB and / or stripe / brief) and / or based on a new flag associated with TB / CB / strip / picture / sequence level (e.g., sps_residual_coding_info_present_in_sh_flag).

[0330] In one example, a control flag is signaled in the slice header to indicate whether the derivation process of the Rice parameter for transform skip blocks and the derivation process of the offset and / or shift parameters for the Rice parameter in transform blocks are enabled or disabled. When the control flag is signaled to be enabled, the Rice parameter may vary under different conditions depending on the specific encoding information of the current block (e.g., quantization parameters and bit depth). And the shift and / or offset parameters used to derive the Rice parameter in regular residual encoding and decoding may vary 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 signaled to be disabled (e.g., set to equal to "0"), the default Rice parameter (e.g., 1) is used for all transform skip slices, and the default offset and / or shift 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 A and TH B It is a predefined threshold (e.g., TH). A =8, TH B =18 or 19). The changes to the VVC draft are shown in bold and italics in Table 67. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters.

[0331] Strip header syntax Table 67. Syntax of Residual Encoding and Decoding

[0332] A value of 1 for `sh_residual_coding_rice_flag` indicates that the bit depth-dependent rice parameter derivation process is used in the current slice. A value of 0 for `sh_residual_coding_rice_flag` indicates that the bit depth-dependent rice parameter derivation process is not used in the current slice. Table 68. Derivation of Rice Parameters Table 69. Derivation of Rice Parameters

[0333] In another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). Changes to the VVC draft are shown in bold and italics in Table 70. It is worth noting that the same logic can be implemented differently in practice. For example, certain equations or lookup tables can also be used to derive the same rice parameters. Table 70. Derivation of Rice Parameters

[0334] According to another aspect of this disclosure, it is proposed to add constraints to the values ​​of the aforementioned coding tool flags to provide the same general constraint control as other constraints in the general constraint information.

[0335] For example, `sps_ts_residual_coding_rice_present_in_sh_flag` equal to 1 indicates that `sh_ts_residual_coding_ric_idx` exists in the SH syntax structure referencing SPS. `sps_ts_residual_coding_rice_present_in_sh_flag` equal to 0 indicates that `sh_ts_residual_coding_ric_idx` does not exist in the SH syntax structure referencing 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 other flags. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are highlighted. Added parts are highlighted in italics.

[0336] In another example, pps_ts_residual_coding_rice_flag equal to 1 indicates that pps_ts_residual_coding_rice_index is present in the current picture. pps_ts_residual_coding_rice_flag equal to 0 indicates that pps_ts_residual_coding_rice_idx is not present in the current picture. In accordance with the present disclosure, it is proposed to add a syntax element gci_no_ts_residual_coding_rice_constraint_flag in the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process of the VVC draft is shown below. Changes to the VVC draft are highlighted. The added part is highlighted in italics.

[0337] In another example, sps_rice_adaption_enabled_flag equal to 1 indicates that the rice parameter for binarization of abs_remaining[] and dec_abs_level can be derived by a formula.

[0338] The formula may include: RiceParam = RiceParam + shiftVal and shiftVal = (localSumAbs<Tx[ 0 ] ) ? Rx[ 0 ]: ( ( localSumAbs<Tx[ 1 ] ) ? Rx[ 1 ]: ( (localSumAbs<Tx[ 2 ] ) ? Rx[ 2 ]: ( ( localSumAbs<Tx[ 3 ] ) ? Rx[ 3 ]: Rx[4] )) ), where the lists Tx[] and Rx[] are specified as follows: Tx[ ]= { 32, 128, 512, 2048}>>(1523) Rx[ ]= { 0, 2, 4, 6, 8}

[0339] In accordance with the present disclosure, it is proposed to add a syntax element gci_no_rice_adaption_constraint_flag in the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process of the VVC draft is shown below. Changes to the VVC draft are highlighted. The added part is highlighted in italics.

[0340] Since the proposed rice parameter adaptation scheme is only used for Transform Skip Residual Coding (TSRC), the proposed method is only effective when TSRC is enabled. Accordingly, in one or more embodiments of this disclosure, it is proposed to add a bitstream constraint that requires the value of gci_no-rice_adaption_constraint to be 1 when the transform skip mode is disabled from the general constraint information level (e.g., when the value of gci_no_transform_skip_constraint_flag is set to 1).

[0341] In another example, `sps_range_extension_flag` equal to 1 indicates that the `sps_lange_extension()` syntax structure exists within the SPS RBSP syntax structure. `sps_range_extension_flag` equal to 0 indicates that the 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 decoding process in the VVC draft is shown below. Changes to the VVC draft are highlighted. Added sections are highlighted in italics.

[0342] Figure 19 An example of a method for video encoding according to this disclosure is shown. This method can be applied, for example, to a decoder. In step 1902, the decoder may receive a Sequence Parameter Set (SPS) range extension flag, the value of which indicates the presence of the syntax structure SPS_range_extension in the Strip Header (SH) Raw Byte Sequence Payload (RBSP) syntax structure.

[0343] In step 1904, in response to determining that the value of the SPS range extension flag is equal to 1, the decoder can determine that SPS_range_extension exists in the SHRBSP syntax structure.

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

[0345] In another example, `sps_cabac_bypass_alignment_enabled_flag` equal to 1 indicates that the value of `ivlCurrRange` can be aligned before the bypass decoding syntax elements `sb_coded_flang[][]`, `abs_remainder[]`, `dec_abs_level[n]`, and `coeff_sign_flag[]`. `sps_cabac_bypass_alignment_enabled_flag` equal to 0 indicates that the value of `ivlCurrRange` is not aligned before bypass decoding. According to this disclosure, it is proposed to add the syntax element `gci_no_cabac_bypass_aligment_constraint_flag` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are highlighted. Added sections are highlighted in italics.

[0346] Figure 20 An example of a method for video encoding according to this disclosure is shown. This method can, for example, be applied to a decoder. In step 2002, the decoder may receive a Sequence Parameter Set (SPS) alignment enable flag, which, based on the SPS alignment enable value, indicates whether the index ivlCurrRange is aligned before the bypass decoding syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flag.

[0347] In step 2004, in response to determining that the value of the SPS alignment enable flag is equal to 1, the decoder can determine that ivlCurrRange is aligned before bypass decoding.

[0348] In step 2006, in response to determining that the value of the SPS alignment enable flag is equal to 0, the decoder can determine that ivlCurrRange is not aligned before bypass decoding.

[0349] In another example, `extended_precision_processing_flag` equal to 1 indicates that extended dynamic range can be used for transform coefficients and transform processing. `extended_precision_processing_flag` equal to 0 indicates that extended dynamic range is not 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 other flags. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are highlighted. Added sections are highlighted in italics.

[0350] Figure 21 An example of a method for video encoding according to this disclosure is shown. This method can, for example, be applied to a decoder. In step 2102, the decoder may receive an extended precision processing flag, which, based on the value of the extended precision processing flag, indicates whether extended dynamic range is employed for the transform coefficients and during transform processing.

[0351] In step 2104, in response to determining that the value of the extended precision processing flag is equal to 1, the decoder can determine the extended dynamic range for the transform coefficients and apply it during the transform processing.

[0352] In step 2106, in response to determining that the value of the extended precision processing flag is 0, the decoder can determine that extended dynamic range is not used for the transform coefficients or during the transform processing.

[0353] In another example, `persistent_rice_adaption_enabled_flag` equal to 1 indicates that at the beginning of each sub-block, the binary rice parameter derivation for `abs_remaining[]` and `dec_abs_level` can be initialized using pattern-related statistics accumulated from previous sub-blocks. `persistent_rice_adaption_enabled_flag` equal to 0 indicates that the previous sub-block state is not used in the rice parameter derivation. According to this disclosure, it is proposed to add the syntax element `gci_no_persistent_rice_adaption_constraint_flag` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are highlighted. Added sections are highlighted in italics.

[0354] Figure 22 An example of a method for video encoding according to this disclosure is shown. This method can, for example, be applied to a decoder. In step 2202, the decoder may receive a persistent rice adaptive enable flag, which, based on the value of the persistent rice adaptive enable flag, indicates whether to initialize rice parameter derivations for abs_maining and dec_abs_level binarization at the beginning of each sub-block, each sub-block employing mode-related statistics accumulated from previous sub-blocks.

[0355] In step 2204, in response to determining that the value of the persistent rice adaptive enable flag is equal to 1, the decoder can determine to initialize the rice parameter derivation for binarization at the beginning of each sub-block, with each sub-block using mode-related statistics accumulated from previous sub-blocks.

[0356] In step 2206, in response to determining that the value of the persistent rice adaptive enable flag is 0, the decoder can determine that the previous sub-block state was not used in the rice parameter derivation.

[0357] The methods described above can be implemented using an apparatus comprising one or more circuits, including 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 apparatus can perform the methods described above using circuits combined with other hardware or software components. Each module, submodule, unit, or subunit disclosed above can be implemented, at least in part, using one or more circuits.

[0358] Figure 18 A computing environment 1810 coupled to a user interface 1860 is shown. The computing environment 1810 may be part of a data processing server. The computing environment 1810 includes a processor 1820, memory 1840, and I / O interface 1850.

[0359] Processor 1820 typically controls the overall operation of computing environment 1810, such as operations associated with display, data acquisition, data communication, and image processing. Processor 1820 may include one or more processors to execute instructions to perform all or some of the steps in the methods 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), microprocessor, microcontroller, GPU, etc.

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

[0361] I / O interface 1850 provides an interface between processor 1820 and peripheral interface modules (e.g., keyboard, click wheel, buttons, etc.). Buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. I / O interface 1850 can be coupled to encoders and decoders.

[0362] In some embodiments, a non-transitory computer-readable storage medium is also provided, which includes a plurality of programs (e.g., included in memory 1840) executable by a processor 1820 in computing environment 1810 for performing the methods described above. For example, the non-transitory computer-readable storage medium may be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

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

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

[0365] Figure 23 This is a block diagram of an example system 10 for parallel encoding and decoding of video blocks, based on some implementations of this disclosure. Figure 23As shown, system 10 includes a source device 12 that generates and encodes video data for later decoding by a destination device 14. The source device 12 and destination device 14 can be any of a 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, and so on. In some implementations, the source device 12 and destination device 14 are equipped with wireless communication capabilities.

[0366] In some implementations, destination device 14 may receive encoded video data to be decoded via link 16. Link 16 may include any type of communication medium or device capable of moving encoded video data from source device 12 to destination device 14. In one example, link 16 may include a communication medium that enables source device 12 to transmit encoded video data directly to destination device 14 in real time. The encoded video data may be modulated according to a communication standard (e.g., a wireless communication protocol) and transmitted to destination device 14. The communication medium may include any wireless or wired communication medium, such as radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network (e.g., a local area network, a wide area network, or a global network such as the Internet). The communication medium may include a router, switch, base station, or any other device that facilitates communication from source device 12 to destination device 14.

[0367] In some other implementations, encoded video data can be transferred from output interface 22 to storage device 32. The destination device 14 can then access the encoded video data in storage device 32 via input interface 28. Storage device 32 can include any of a variety of distributed or locally accessed data storage media, such as hard disks, Blu-ray discs, digital versatile optical discs (DVDs), compact disc read-only memory (CD-ROMs), flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In another example, storage device 32 can correspond to a file server or another intermediate storage device that can hold the encoded video data generated by source device 12. The destination device 14 can access the stored video data from storage device 32 via streaming or downloading. The file server can be any type of computer capable of storing encoded video data and transferring the encoded video data to destination device 14. Exemplary file servers include web servers (e.g., for websites), file transfer protocol (FTP) servers, network-attached storage (NAS) devices, or local disk drives. Destination device 14 can access the encoded video data via any standard data connection, including wireless channels (e.g., Wi-Fi connections), wired connections (e.g., Digital Subscriber Line (DSL), cable modems, etc.), or combinations thereof, suitable for accessing encoded video data stored on a file server. Transmission of the encoded video data from storage device 32 can be streaming, downloading, or a combination of both.

[0368] like Figure 23 As shown, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include a source such as a video capture device (e.g., a camera), a video archive containing previously captured video, a video feed interface receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as source video, or a combination of these sources. For example, if video source 18 is a camera in a security monitoring system, source device 12 and destination device 14 may form a camera phone or video phone. However, the implementation described in this application is generally applicable to video encoding and can be applied to wireless and / or wired applications.

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

[0370] Destination device 14 includes input interface 28, video decoder 30, and display device 34. Input interface 28 may include a receiver and / or modem and receives encoded video data via link 16. Encoded video data transmitted via link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use by video decoder 30 when decoding the video data. Such syntax elements may be included in encoded video data transmitted on a communication medium, stored on a storage medium, or stored on a file server.

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

[0372] Video encoder 20 and video decoder 30 can operate according to proprietary or industry standards (e.g., VVC, HEVC, MPEG-4, Part 10, AVC, or extensions of these standards). It should be understood that this application is not limited to any particular video encoding / decoding standard and can be applied to other video encoding / decoding standards. It is generally expected that the video encoder 20 of source device 12 can be configured to encode video data according to any of these current or future standards. Similarly, it is also generally expected that the video decoder 30 of destination device 14 can be configured to decode video data according to any of these current or future standards.

[0373] The video encoder 20 and video decoder 30 can be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic circuits, software, hardware, firmware, or any combination thereof. When implemented in part in software, the electronic device may store software instructions in a suitable non-transitory computer-readable medium and use one or more processors to execute the instructions in the hardware to perform the video encoding / decoding operations disclosed in this disclosure. Each of the video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, wherein any one may be integrated as part of a combined encoder / decoder (CODEC) in the respective device.

[0374] Figure 24This is a block diagram illustrating an exemplary video encoder 20 according to some implementations described in this application. The video encoder 20 can perform intra-frame and inter-frame predictive coding on video blocks within a video frame. Intra-frame predictive coding relies on spatial prediction to reduce or eliminate spatial redundancy in the video data within a given video frame or picture. Inter-frame predictive coding relies on temporal prediction to reduce or remove temporal redundancy in the video data within adjacent video frames or pictures of a video sequence. It should be noted that the term "frame" can be used as a synonym for the terms "image" or "picture" in the field of video coding.

[0375] like Figure 24 As shown, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a segmentation unit 45, an intra-frame prediction processing unit 46, and an intra-frame block copying (BC) unit 48. In some implementations, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction. A loop filter 63 (e.g., a deblocking filter) may be located between the adder 62 and the DPB 64 to filter block boundaries in order to remove block artifacts from the reconstructed video. In addition to the deblocking filter, another loop filter (e.g., a sample adaptive offset (SAO) filter and / or an adaptive loop filter (ALF)) may be used to filter the output of the adder 62. In some examples, the loop filter may be omitted, and the adder 64 can directly provide the decoded video blocks to the DPB 64. The video encoder 20 may take the form of a fixed or programmable hardware unit, or may be divided among one or more of the fixed or programmable hardware units shown.

[0376] The video data storage device 40 can store video data to be encoded by the components of the video encoder 20. For example, data can be stored from... Figure 23 The video source 18 shown receives video data from the video data memory 40. The DPB 64 is a buffer that stores reference video data (e.g., reference frames or pictures) for the video encoder 20 to encode the video data (e.g., in intra-frame or inter-frame predictive coding modes). The video data memory 40 and DPB 64 can be formed from any of a variety of storage devices. In various examples, the video data memory 40 may be on-chip with other components of the video encoder 20, or off-chip relative to those components.

[0377] like Figure 24As shown, after receiving video data, the segmentation unit 45 within the prediction processing unit 41 segments the video data into video blocks. This segmentation may also include dividing the video frame into strips, tiles (e.g., a set of video blocks), or other larger coding units (CUs) according to a predefined segmentation structure (e.g., a quadtree (QT) structure associated with the video data). A video frame is, or can be viewed as, a two-dimensional array or matrix of sample points with sample values. Sample points in this array can also be called pixels or primitives. The number of samples in the horizontal and vertical directions (or axes) of this array or image defines the size and / or resolution of the video frame. A video frame can be divided into multiple video blocks, for example, using QT segmentation. A video block is also, or can be viewed as, a two-dimensional array or matrix of sample points with sample values, although its dimension is smaller than that of the video frame. The number of samples in the horizontal and vertical directions (or axes) of the video block defines the size of the video block. A video block can also be divided into one or more block partitions or sub-blocks (which can then re-form blocks) by, for example, iteratively using QT partitioning, binary tree (BT) partitioning, or ternary tree (TT) partitioning, or any combination thereof. It should be noted that, as used herein, the term “block” or “video block” can be a portion of a frame or picture, particularly a rectangular (square or non-square) portion. For example, referring to HEVC and VVC, a block or video block can be or correspond to a coding tree unit (CTU), CU, prediction unit (PU), or transform unit (TU), and / or can be or correspond to a corresponding block (e.g., coding tree block (CTB), coding block (CB), prediction block (PB), or transform block (TB)) and / or correspond to a sub-block.

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

[0379] To select a suitable intra-predictive coding mode for the current video block, the intra-predictive processing unit 46 within the prediction processing unit 41 can perform intra-predictive coding of the current video block relative to one or more neighboring blocks in the same frame as the current block to be encoded, to provide spatial prediction. 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 relative to one or more prediction blocks in one or more reference frames, to provide temporal prediction. The video encoder 20 can perform multiple coding processes, such as selecting an appropriate coding mode for each video data block.

[0380] In some implementations, motion estimation unit 42 determines the inter-frame prediction mode for the current video frame by generating motion vectors that indicate the displacement of a video block within the current video frame relative to a prediction block within a reference video frame, based on a predetermined mode within the video frame sequence. Motion estimation performed by motion estimation unit 42 is the process of generating motion vectors that estimate the motion of video blocks. For example, the motion vectors may indicate the displacement of a video block within the current video frame or picture relative to a prediction block within a reference frame (which is relative to the current block encoded within the current frame). The predetermined mode may designate video frames in the sequence as P-frames or B-frames. Intra-frame BC unit 48 may determine the vectors (e.g., block vectors) for intra-frame BC encoding in a manner similar to that determined by motion estimation unit 42 for inter-frame prediction, or the block vectors may be determined using motion estimation unit 40.

[0381] The prediction block used for the video block can be, or can correspond to, a block or reference block of a reference frame, which is assumed to closely match the video block to be encoded in terms of pixel differences. Pixel differences can be determined using sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some implementations, the video encoder 20 can compute values ​​for sub-integer pixel positions of the reference frame stored in the DPB 64. For example, the video encoder 20 can interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Therefore, the motion estimation unit 42 can perform motion search relative to full-pixel positions and fractional-pixel positions, and output a motion vector with fractional-pixel precision.

[0382] The motion estimation unit 42 calculates the motion vector of the video block in the inter-frame predictive coding frame by comparing the position of the video block with the position of the predicted block of a reference frame selected from either the first reference frame list (list 0) or the second reference frame list (list 1), where each reference frame list in the first and second reference frame lists identifies one or more reference frames stored in the DPB 64. The motion estimation unit 42 sends the calculated motion vector to the motion compensation unit 44, and then to the entropy coding unit 56.

[0383] Motion compensation performed by motion compensation unit 44 may involve extracting or generating prediction blocks based on motion vectors determined by motion estimation unit 42. Upon receiving the motion vector of the current video block, motion compensation unit 44 may locate the prediction block pointed to by the motion vector in one of the reference frame lists, retrieve the prediction block from DPB 64, and forward the prediction block to adder 50. Adder 50 then forms a residual video block of pixel differences by subtracting the pixel values ​​of the prediction block provided by motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel differences forming the residual video block may include luma or chroma difference components, or both. Motion compensation unit 44 may also generate syntax elements associated with video blocks of a video frame for use by video decoder 30 when decoding video blocks of a video frame. Syntax elements may include, for example, syntax elements defining motion vectors for identifying prediction blocks, any flags indicating prediction modes, or any other syntax information described herein. It should be noted that motion estimation unit 42 and motion compensation unit 44 may be highly integrated, but are shown separately for illustrative purposes.

[0384] In some implementations, the intra-BC unit 48 can generate vectors and extract prediction blocks in a manner similar to that described above in combination with the motion estimation unit 42 and the motion compensation unit 44. However, the prediction blocks are in the same frame as the current block being encoded, and these vectors are called block vectors rather than motion vectors. Specifically, the intra-BC unit 48 can determine the intra-prediction mode to be used for encoding the current block. In some examples, the intra-BC unit 48 can encode the current block using various intra-prediction modes (e.g., during a separate encoding process) and test their performance through rate distortion analysis. Next, the intra-BC unit 48 can select an appropriate intra-prediction mode from the various tested intra-prediction modes to use and generate an intra-prediction mode indicator accordingly. For example, the intra-BC unit 48 can use rate distortion analysis for various tested intra-prediction modes to calculate rate distortion values ​​and select the intra-prediction model with the best rate distortion characteristics among the tested modes as the appropriate intra-prediction mode to use. Rate distortion analysis typically determines the amount of distortion (or error) between a coded block and the original uncoded block, as well as the bit rate (i.e., the number of bits) used to generate the coded block, where the original uncoded block is encoded to produce the coded block. Intra-frame BC unit 48 can calculate the ratio based on the distortion and rate of various coded blocks to determine which intra-frame prediction mode exhibits the optimal rate distortion value for that block.

[0385] In other examples, the intra-frame BC unit 48 may use, in whole or in part, the motion estimation unit 42 and the motion compensation unit 44 to perform these functions for intra-frame BC prediction according to the implementation described herein. In either case, for intra-block copying, the predicted block may be a block that is considered to closely match the block to be encoded 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 calculating values ​​for sub-integer pixel positions.

[0386] Regardless of whether the predicted block comes from the same frame predicted intra-frame or from different frames predicted inter-frame, 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 current video block being encoded, thus forming a pixel difference. The pixel difference forming the residual video block can include differences in luminance and chrominance components.

[0387] As described above, the intra-prediction processing unit 46 can perform intra-prediction on the current video block as an alternative to inter-prediction performed by the motion estimation unit 42 and the motion compensation unit 44, or intra-block copy prediction performed by the intra-BC unit 48. Specifically, the intra-prediction processing unit 46 can determine the intra-prediction mode to be used for encoding the current block. To this end, the intra-prediction processing unit 46 can encode the current block using various intra-prediction modes (e.g., during a separate encoding process), and the intra-prediction control unit 46 (or, in some examples, the mode selection unit) can select the appropriate intra-prediction mode to use from the tested intra-prediction modes. The intra-prediction processing unit 46 can provide information to the entropy coding unit 56 indicating the intra-prediction mode selected for the block. The entropy coding unit 56 can encode the information indicating the selected intra-prediction mode in the bitstream.

[0388] After prediction processing unit 41 determines the prediction block of the current video block through inter-frame prediction or intra-frame prediction, adder 50 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be included in one or more TUs and provided to transform processing unit 52. Transform processing unit 54 transforms the residual video data into residual transform coefficients using a transform such as discrete cosine transform (DCT) or a conceptually similar transform.

[0389] The transform processing unit 52 can send the obtained transform coefficients to the quantization unit 54. The quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process can also reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be modified by adjusting the quantization parameters. In some examples, the quantization unit 54 can then perform a scan of a matrix that includes the quantized transform coefficients. Alternatively, the entropy coding unit 56 can perform this scan.

[0390] After quantization, the entropy coding unit 56 entropy codes the quantized transform coefficients into a video bitstream using, for example, context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary algorithm coding (SBAC), probabilistic interval segmented entropy (PIPE) coding, or another entropy coding method or technique. The encoded bitstream can then be sent to the video decoder 30 (e.g., ...). Figure 23 (as shown), or archived in storage device 32 (such as...) Figure 23 (as shown in the diagram) so that it can be sent later to or retrieved by the video decoder 30. The entropy coding unit 56 can also entropy code the motion vectors and other syntax elements of the current video frame being encoded.

[0391] The inverse quantization unit 58 and the inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain to generate a reference block for predicting other video blocks. As described above, the motion compensation unit 44 can generate a motion-compensated prediction block based on one or more reference blocks of the frame stored in the DPB 64. The motion compensation unit 44 can also apply one or more interpolation filters to the prediction block to calculate the sub-integer pixel values ​​used in motion estimation.

[0392] Adder 62 adds the reconstructed residual block to the motion-compensated prediction block generated by motion compensation unit 44 to produce a reference block for storage in DPB 64. Then, intra-frame BC unit 48, motion estimation unit 42, and motion compensation unit 44 can use the reference block as the prediction block to perform inter-frame prediction for another video block in a subsequent video frame.

[0393] Figure 25 This is a block diagram illustrating an exemplary video decoder 30 according to some implementations of this application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra-frame prediction unit 84, and an intra-frame prediction (BC) unit 85. The video decoder 30 can perform operations in combination with the above. Figure 24 The encoding process of the video encoder 20 described is roughly the opposite of the decoding process. 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-frame prediction unit 84 can generate prediction data based on intra-frame prediction mode indicators received from the entropy decoding unit 80.

[0394] In some examples, a unit of the video decoder 30 may be assigned to perform an implementation of this application. Furthermore, in some examples, the implementation of this disclosure may be divided among one or more units of the video decoder 30. For example, the intra-frame BC unit 85 may perform an implementation of this application either alone or in combination with other units of the video decoder 30 (e.g., motion compensation unit 82, intra-frame prediction unit 84, and entropy decoding unit 80). In some examples, the video decoder 30 may not include the intra-frame BC unit 85, and the function of the intra-frame BC unit 85 may be performed by other components of the prediction processing unit 81 (e.g., motion compensation unit 82).

[0395] Video data memory 79 can store video data (e.g., encoded video bitstream) for decoding by other components of video decoder 30. The video data stored in video data memory 79 can be accessed via wired or wireless network communication, such as from storage device 32, a local video source (e.g., a camera), or by accessing a physical data storage medium (e.g., a flash drive or hard disk). Video data memory 79 may include an encoded picture buffer (CPB) that stores encoded video data from the encoded video bitstream. The DPB 92 of video decoder 30 stores reference video data for use by video decoder 30 when decoding video data (e.g., in intra-frame or inter-frame predictive coding modes). Video data memory 79 and DPB 92 can be formed from any of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM)) or other types of memory devices. For ease of illustration, ... Figure 25 The video data memory 79 and DPB 92 are described as two distinct components of the video decoder 30. However, it will be apparent to those skilled in the art that the video data memory 79 and DPB 92 may be provided by the same storage device or separate storage devices. In some examples, the video data memory 79 may be on-chip with other components of the video decoder 30, or off-chip relative to those components.

[0396] During decoding, the video decoder 30 receives an encoded video bitstream representing video blocks of encoded video frames and associated syntax elements. The video decoder 30 can receive video frame-level and / or video block-level syntax elements. The entropy decoding unit 80 of the video decoder 30 performs entropy decoding on the bitstream to generate quantization coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Then, the entropy decoding unit 80 forwards the motion vectors or intra-prediction mode indicators and other syntax elements to the prediction processing unit 81.

[0397] When a video frame is encoded as an intra-predictive coded (I) frame or an intra-coded prediction block in another type of frame, the intra-prediction unit 84 of the prediction processing unit 81 can generate prediction data for the video block of the current video frame based on the intra-frame mode transmitted by the signal and reference data from the previous decoded block of the current frame.

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

[0399] In some examples, when a video block is encoded according to the intra-BC mode described herein, the intra-BC unit 85 of the prediction processing unit 81 generates a prediction block for the current video block based on the block vector and other syntax elements received from the entropy decoding unit 80. These prediction blocks can be located within the reconstructed region of the same image as the current video block defined by the video encoder 20.

[0400] Motion compensation unit 82 and / or intra-frame BC unit 85 determine the prediction information of video blocks in the current video frame by parsing motion vectors and other syntax elements, and then use the prediction information to generate a prediction block for the current video block being decoded. For example, motion compensation unit 82 uses some of the received syntax elements to determine the prediction mode (e.g., intra-frame or inter-frame prediction) used to encode video blocks in the video frame, the inter-frame prediction frame type (e.g., B or P), the construction information of one or more reference frame lists for the frame, the motion vectors of each inter-frame prediction encoded video block in the frame, the inter-frame prediction state of each inter-frame prediction encoded video block in the frame, and other information used to decode video blocks in the current video frame.

[0401] Similarly, the intra-BC unit 85 can use some of the received syntax elements (e.g., flags) to determine whether the current video block was predicted using the intra-BC mode, which video blocks in the frame are in the reconstruction region and should be stored in the DPB 92, the block vector of each intra-BC predicted video block in the frame, the intra-BC prediction state of each intra-BC predicted video block in the frame, and other information for decoding the video blocks in the current video frame.

[0402] The motion compensation unit 82 can also perform interpolation using the interpolation filter used by the video encoder 20 during video block encoding to calculate the interpolation of sub-integer pixels of the reference block. In this case, the motion compensation unit 82 can determine the interpolation filter used by the video encoder 20 based on the received syntax elements and use the interpolation filter to generate the prediction block.

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

[0404] After the motion compensation unit 82 or the intra-frame BC unit 85 generates a prediction block for the current video block based on vectors and other syntax elements, the adder 90 reconstructs the decoded video block of the current video block by adding the residual block from the inverse transform processing unit 88 to the corresponding prediction block generated by the motion compensation unit 82 and the intra-frame BC unit 85. A loop filter 91, such as a deblocking filter, a SAO filter, and / or an ALF, may be located between the adder 90 and the DPB 92 to further process the decoded video block. In some examples, the loop filter 91 may be omitted, and the adder 90 may directly provide the decoded video block to the DPB 92. The decoded video block in a given frame is then stored in the DPB 92, which stores a reference frame for subsequent motion compensation of the next video block. The DPB 92, or a separate storage device, may also store the decoded video for later display on a display device (e.g., Figure 23 It is displayed on the display device 34).

[0405] The description in this disclosure is for illustrative purposes and is not intended to be exhaustive or limiting. Many modifications, variations, and alternative embodiments will be apparent to those skilled in the art from the teachings presented in the foregoing description and the accompanying drawings.

[0406] These examples were chosen and described only to explain the principles of this disclosure and to enable others skilled in the art to understand the various implementations of this disclosure and to best utilize the underlying principles and various embodiments with various modifications suited to the intended particular purpose. Therefore, it should be understood that the scope of protection of this disclosure is not limited to the specific examples of the disclosed implementations, and that various modifications and other implementations are also included within the scope of protection of this disclosure.

Claims

1. A method for video encoding, comprising: The value of the persistent rice adaptive enable flag is determined by the encoder. The value of the persistent rice adaptive enable flag indicates whether to use statistics accumulated from previous blocks to initialize the rice parameter derivation for binarization of two syntax elements at the beginning of each block. as well as The encoder sends the persistent rice adaptive enable flag via a signal.

2. The method for video encoding according to claim 1, wherein: The value of the persistent rice adaptive enable flag being equal to 1 indicates that the rice parameter derivation for binarization is initialized at the beginning of each block using statistics accumulated from the previous block. as well as The value of the persistent rice adaptive enable flag being equal to 0 indicates that the previous block state is not used in the rice parameter derivation.

3. The method for video encoding according to claim 1, further comprising: The encoder sends a persistent rice adaptive constraint flag via signaling in the general constraint information syntax to provide general constraint control for at least one of the other flags; and The fact that the value of the persistent rice adaptive constraint flag is equal to 1 indicates that the value of at least one of the other flags should be equal to 0.

4. The method for video encoding according to claim 1, further comprising: The encoder sends a persistent rice adaptive constraint flag via signaling in the general constraint information syntax to provide general constraint control for the persistent rice adaptive enable flag; and The fact that the value of the persistent rice adaptive constraint flag is equal to 1 indicates that the value of the persistent rice adaptive enable flag should be equal to 0.

5. A method for video decoding, comprising: The decoder receives a persistent rice adaptive enable flag, the persistent rice adaptive enable flag indicating, based on the value of the persistent rice adaptive enable flag, whether to use statistics accumulated from previous blocks at the beginning of each block to initialize the rice parameter derivation for binarization of two syntax elements.

6. The method for video decoding according to claim 5, further comprising: In response to determining that the value of the persistent rice adaptive enable flag is equal to 1, it is determined that at the beginning of each block, the rice parameter derivation for binarization is initialized using statistics accumulated from the previous block; as well as In response to determining that the value of the persistent rice adaptive enable flag is 0, it is determined that no previous block state was used in the rice parameter derivation.

7. The method for video decoding according to claim 5, further comprising: The decoder receives the persistent rice adaptive constraint flag from the general constraint information syntax to provide general constraint control for at least one of the other flags; as well as In response to determining that the value of the persistent rice adaptive constraint flag is equal to 1, it is determined that the value of at least one of the other flags should be equal to 0.

8. The method for video decoding according to claim 5, further comprising: The decoder receives the persistent rice adaptive constraint flag from the general constraint information syntax to provide general constraint control for the persistent rice adaptive enable flag; as well as In response to determining that the value of the persistent rice adaptive constraint flag is equal to 1, it is determined that the value of the persistent rice adaptive enable flag should be equal to 0.

9. An apparatus for video encoding and decoding, comprising: One or more processors; as well as A memory for storing instructions, wherein, when executed by the one or more processors, the instructions cause the one or more processors to perform the method according to any one of claims 1-8.

10. A computer program product comprising computer-executable instructions for video encoding and decoding, which, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1-8.

11. A non-transitory computer-readable storage medium for video encoding, storing a bit stream formed by computer-executable instructions that, when executed by a computing device having one or more processors, cause the one or more processors to perform the method for video encoding according to any one of claims 1-4.

12. A non-transitory computer-readable storage medium for video encoding, storing a bitstream and computer-executable instructions that, when executed by a computing device having one or more processors, cause the one or more processors to perform a method for video encoding according to any one of claims 1-4 to generate the bitstream.

13. A method for storing a bit stream, comprising: Perform the method according to any one of claims 1-4 to generate a bit stream; as well as Store the bit stream.

14. A method for transmitting a bit stream, comprising: Perform the method according to any one of claims 1-4 to generate a bit stream; as well as Transmit the bit stream.

Images