Residual and coefficient coding / decoding for video coding / decoding
By introducing new syntax elements and flag bits in video encoding and decoding, and optimizing the encoding and decoding process of residuals and coefficients, the problem of difficulty in maintaining video quality is solved in the prior art, and a more efficient video encoding efficiency is achieved.
Patent Information
- Application Number
- JP2023560156
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-03-29
- Filing Date
- 2022-03-25
- Publication Date
- 2025-04-30
- Estimated Expiration
- 2042-03-25
AI Technical Summary
Existing video encoding and decoding techniques are difficult to significantly reduce the bit rate while maintaining video quality when compressing video data, especially when using efficient video encoding standards such as HEVC and VVC.
Optimize the encoding and decoding process of residuals and coefficients by introducing new syntax elements and flag bits in video encoding and decoding, such as Sequence Parameter Set (SPS) range extension flag, SPS alignment enable flag, extended precision processing flag, and persistent metre adaptation enable flag.
These technical means help improve the efficiency of video encoding, reduce bit rate, while maintaining or improving video quality, especially when using high-efficiency video encoding standards.
Smart Images

Figure 0007670851000091 
Figure 0007670851000092 
Figure 0007670851000093
Abstract
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Application No. 63 / 167,621, filed March 29, 2021, the entire disclosure of which is incorporated herein by reference. [Technical field]
[0002] FIELD OF THE DISCLOSURE This disclosure relates to video encoding / decoding and compression. In particular, this disclosure relates to improvements and simplification of residual and coefficient encoding / decoding for video encoding / decoding. [Background technology]
[0003] A variety of video encoding and decoding techniques can be used to compress video data. Video encoding and decoding is performed according to one or more video encoding and decoding standards, including, for example, Versatile Video Coding (VVC), Joint Exploration Test Model (JEM), High Efficiency Video Coding and Decoding (H.265 / HEVC), Advanced Video Coding and Decoding (H.264 / AVC), and Moving Picture Experts Group (MPEG) encoding and decoding. Video encoding and decoding generally utilizes prediction methods (e.g., inter-prediction, intra-prediction, etc.) that rely on redundancy present in a video image or sequence. An important goal of video encoding and decoding techniques is to compress video data into a lower bitrate format while avoiding or minimizing video quality degradation. Summary of the Invention
[0004] Examples of the present disclosure provide methods and apparatus for video encoding and decoding.
[0005] According to a first aspect of the present disclosure, a method for video encoding and decoding is provided, the method including receiving a sequence parameter set (SPS) range extension flag by an SPS range extension flag decoder, the SPS range extension flag indicating whether a syntax structure sps_range_extension is present in a syntax structure of a slice header (SH) raw byte sequence payload (RBSP) based on a value of the SPS range extension flag.
[0006] According to a second aspect of the present disclosure, a method for video encoding / decoding is provided, the method including receiving, by a decoder, a sequence parameter set (SPS) alignment enable flag, the SPS alignment enable flag indicating whether an index ivlCurrRange is aligned before bypass decoding of syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flagn based on a value of the SPS alignment enable flag.
[0007] According to a third aspect of the present disclosure, there is provided a method for video encoding / decoding, the method including receiving, by a decoder, an extended precision processing flag, the extended precision processing flag indicating whether an extended dynamic range is used for transform coefficients during a transform process based on a value of the extended precision processing flag.
[0008] According to a fourth aspect of the present disclosure, there is provided a method for video encoding / decoding, the method including receiving, by a decoder, a persistent Rice adaptation enable flag, the persistent Rice adaptation enable flag indicating whether Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each sub-block with mode-related statistics accumulated from a previous sub-block based on a value of the persistent Rice adaptation enable flag.
[0009] It is to be understood that the foregoing summary and the following detailed description are exemplary and explanatory only and are not intended to be restrictive of the present disclosure. [Brief description of the drawings]
[0010] The drawings, which are incorporated in and constitute a part of this specification, illustrate examples consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure.
[0011] [Figure 1] FIG. 1 is a block diagram illustrating an encoder according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a block diagram illustrating a decoder according to an embodiment of the present disclosure. [Diagram 3] FIG. 3A is a diagram illustrating block partitions in a multi-type tree structure according to an embodiment of the present disclosure. FIG. 3B is a diagram illustrating block partitions in a multi-type tree structure according to an embodiment of the present disclosure. FIG. 3C is a diagram illustrating block partitions in a multi-type tree structure according to an embodiment of the present disclosure. FIG. 3D is a diagram illustrating block partitions in a multi-type tree structure according to an embodiment of the present disclosure. FIG. 3E is a diagram illustrating block partitions in a multi-type tree structure according to an embodiment of the present disclosure. [Figure 4] FIG. 4 is a diagram illustrating an image having 18×12 luminance CTUs according to an embodiment of the present disclosure. [Diagram 5] FIG. 5 is a diagram illustrating an image having 18×12 luminance CTUs according to an embodiment of the present disclosure. [Figure 6]FIG. 6A illustrates an example of ternary tree (TT) and binary tree (BT) partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6B illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6C illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6D illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6E illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6F illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6G illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. FIG. 6H illustrates an example of TT and BT partitions that are not allowed in a VTM, according to an embodiment of the present disclosure. [Figure 7] FIG. 7 is a diagram illustrating a residual encoding / decoding structure for a transform block according to an embodiment of the present disclosure. [Figure 8] FIG. 8 is a diagram illustrating a residual encoding / decoding structure for transform skip flags according to an embodiment of the present disclosure. [Figure 9] FIG. 9 is a diagram illustrating two scalar quantizers according to an embodiment of the present disclosure. [Figure 10] 10A and 10B are diagrams illustrating state transitions and quantizer selection, respectively, according to an embodiment of the present disclosure. [Figure 11] FIG. 11 is a diagram illustrating a template for selecting a probabilistic model in accordance with the present disclosure. [Figure 12] FIG. 12 is a diagram illustrating an example of a block encoded and decoded in palette mode according to the present disclosure. [Figure 13] FIG. 13 is a diagram illustrating the use of a palette predictor for signal palette entries in accordance with the present disclosure. [Figure 14] 14A and 14B are diagrams illustrating horizontal and vertical traverse scanning, respectively, in accordance with the present disclosure. [Figure 15]15A and 15B are diagrams illustrating index map traversal by sub-block for a palette in accordance with the present disclosure; [Figure 16] FIG. 16 is a method for encoding a video signal according to an embodiment of the present disclosure. [Figure 17] FIG. 17 is a method for encoding a video signal according to the present disclosure. [Figure 18] FIG. 18 illustrates a computing environment connected to a user interface according to an embodiment of the present disclosure. [Figure 19] FIG. 19 illustrates a method for video encoding and decoding according to an embodiment of the present disclosure. [Figure 20] FIG. 20 illustrates a method for video encoding and decoding according to an embodiment of the present disclosure. [Figure 21] FIG. 21 illustrates a method for video encoding and decoding according to an embodiment of the present disclosure. [Figure 22] FIG. 22 illustrates a method for video encoding and decoding according to an embodiment of the present disclosure. [Diagram 23] FIG. 23 is a block diagram illustrating an example system for encoding and decoding video blocks in accordance with an embodiment of this disclosure. [Figure 24] FIG. 24 is a block diagram illustrating an example video encoder according to an embodiment of the present disclosure. [Diagram 25] FIG. 25 is a block diagram illustrating an exemplary video decoder according to an embodiment of the disclosure. [Figure 26] FIG. 26 illustrates a low-delay transform skip residual coding and decoding (TSRC) method according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0012] Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the drawings in which the same numerals in different drawings represent the same or similar elements unless otherwise stated. The implementations described in the following description of exemplary embodiments do not represent all implementations consistent with the present disclosure. These are merely examples of apparatus and methods consistent with aspects related to the present disclosure as set forth in the appended claims.
[0013] The terms used in this disclosure are used only for the purpose of describing particular embodiments and are not intended to limit the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly dictates otherwise. Furthermore, as used herein, the term "and / or" is intended to indicate and include any and all possible combinations of one or more of the associated listed items.
[0014] In this specification, terms such as "first," "second," and "third" may be used to describe various types of information, but it should be understood that the information described should not be limited to these terms. These terms are used only to distinguish one type of information from another type of information. For example, the first information may be referred to as the second information, and similarly, the second information may be referred to as the first information, without departing from the scope of this disclosure. As used herein, the term "if" is understood to mean "when" or "once" or "subject to judgment," depending on the context.
[0015] The first version of the HEVC standard was finalized in October 2013 and provides approximately 50% bitrate savings or equivalent perceptual quality compared to its predecessor, the video encoding / decoding standard H.264 / MPEG AVC. While the HEVC standard provides significant encoding / decoding improvements compared to its predecessor, there is evidence that additional encoding / decoding tools can be utilized to achieve better encoding / decoding efficiency than HEVC. Based on this, both VCEG and MPEG have started to explore new encoding / decoding techniques for future video encoding / decoding standardization. ITU-T VECG and ISO / IEC MPEG formed the Joint Joint Video Experts Team (JVET) in October 2015 to begin significant research into advanced technologies that can achieve significant improvements in encoding / decoding efficiency. JVET maintains a reference software called the Joint Exploration Test Model (JEM) by integrating several additional encoding / decoding tools on top of the HEVC test model (HM).
[0016] In October 2017, ITU-T and ISO / IEC issued a joint call for proposals (CfP) for video compression with performance exceeding HEVC. In April 2018, the 10th JVET meeting received and evaluated 23 CfP responses showing compression efficiency gains of approximately 40% over HEVC. Based on these evaluation results, JVET initiated a new project to develop a next-generation video encoding / decoding standard called Versatile Video Coding (VVC). In the same month, a reference software code base called the VVC test model (VTM) was built to demonstrate a reference implementation of the VVC standard.
[0017] Like HEVC, VVC is built on a block-based hybrid video encoding and decoding framework.
[0018] Figure 1 shows a schematic diagram of a block-based video encoder for VVC. Specifically, Figure 1 shows an exemplary encoder 100. The encoder 100 has a video input 110, motion compensation 112, motion estimation 114, intra / inter mode decision 116, block predictor 140, adder 128, transform 130, quantization 132, prediction related information 142, intra prediction 118, image buffer 120, inverse quantization 134, inverse transform 136, adder 126, memory 124, in-loop filter 122, entropy coding 138 and bitstream 144.
[0019] At encoder 100, a video frame is divided into multiple video blocks for processing. For a given video block, a prediction is formed based on an inter-prediction method or an intra-prediction method.
[0020] A prediction residual, which indicates the difference between the current video block (part of the video input 110) and its predictor (part of the block predictor 140), is sent from the adder 128 to the transform 130. The transform coefficients are then sent from the transform 130 to the quantization 132 for entropy reduction. The quantized coefficients are then provided to the entropy coding 138 to generate a compressed video bitstream. As shown in FIG. 1, prediction related information 142 (e.g., video block partition information, motion vectors (MVs), reference picture indexes, intra prediction modes) from the intra / inter mode decision 116 is also provided by the entropy coding 138 and stored in the compressed bitstream 144. The compressed bitstream 144 comprises the video bitstream.
[0021] The encoder 100 also requires decoder-related circuitry to reconstruct pixels for prediction purposes. First, a prediction residual is reconstructed by inverse quantization 134 and inverse transform 136. The reconstructed prediction residual is combined with a block predictor 140 to generate unfiltered reconstructed pixels for the current video block.
[0022] Spatial prediction (or "intra prediction") predicts the current video block using pixels from samples (called reference samples) of previously coded neighboring blocks in the same video frame as the current video block.
[0023] Temporal prediction (also called "inter prediction") uses reconstructed pixels from a previously coded video image to predict a current video block. Temporal prediction reduces the temporal redundancy inherent in video signals. The temporal prediction signal for a given coding unit (CU) or coding block is typically signaled by one or more MVs that indicate the amount and direction of motion between the current CU and its temporal references. Furthermore, if multiple reference images are supported, a reference image index is additionally transmitted to identify which reference image in the reference image store the temporal prediction signal comes from.
[0024] Motion estimation 114 takes signals from video input 110 and image buffer 120 and outputs a motion estimation signal to motion compensation 112. Motion compensation 112 takes signals from video input 110, image buffer 120, and a motion estimation signal from motion estimation 114 and outputs a motion compensation signal to intra / inter mode decision 116.
[0025] After performing spatial prediction and / or temporal prediction, an intra / inter mode decision 116 in the encoder 100 selects an optimal prediction mode based, for example, on a rate-distortion optimization method. The block predictor 140 is then subtracted from the current video block by transform 130 and quantization 132 to decorrelate the resulting prediction residual. The resulting quantization residual coefficients are inverse quantized by inverse quantization 134 and inverse transformed by inverse transform 136 to form a reconstructed residual, which is then added back to the prediction block to form a reconstructed signal for the CU. The reconstructed CU may be applied with an in-loop filter 122, such as a deblocking filter, a sample adaptive offset (SAO), and / or an adaptive in-loop filter (ALF), before being placed in a reference image store of the image buffer 120 and used to encode future video blocks. To form the output video bitstream 144, the coding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit 138 for further compression and packaging to form the bitstream.
[0026] FIG. 1 is a block diagram of a generic block-based hybrid video coding system. An input video signal is processed in blocks (called CUs). In VTM-1.0, a CU can be up to 128×128 pixels. However, unlike HEVC, which partitions blocks based only on quadtrees, in VVC, one coding tree unit (CTU) is divided into CUs based on quadtrees / binarytrees / ternarytrees to adapt to changing local characteristics. By definition, a coding tree block (CTB) is an N×N sample block for some N value, and dividing components into CTBs is a kind of partition. A CTU includes a CTB of luma samples for an image with three sample arrays, two corresponding CTBs of chroma samples, or a CTB of samples for a monochrome image, or a CTB of samples for an image coded with three separate color planes and a syntax structure for sample coding. Also, the concept of multi-partition unit types in HEVC is removed, i.e., CUs, prediction units (PUs), and transform units (TUs) are no longer distinguished in VVC. Instead, each CU is always used as a base unit for both prediction and transformation without needing further partitioning. In the multi-type tree structure, one CTU is first partitioned by a quadtree structure. Then, the leaf node of each quadtree can be further partitioned by a binary tree structure and a ternary tree structure. As shown in Figure 3A, Figure 3B, Figure 3C, Figure 3D, Figure 3E, there are five types of partitioning types: quad partition, horizontal binary partition, vertical binary partition, horizontal ternary partition and vertical ternary partition.
[0027] FIG. 3A is a diagram illustrating a block quad partition in a multi-type tree structure according to the present disclosure.
[0028] FIG. 3B is a diagram illustrating a block vertical binary partition in a multi-type tree structure according to the present disclosure.
[0029] FIG. 3C is a diagram illustrating a horizontal binary partition of blocks in a multi-type tree structure according to the present disclosure.
[0030] FIG. 3D is a diagram illustrating a block vertical ternary partition in a multi-type tree structure according to the present disclosure.
[0031] FIG. 3E is a diagram illustrating a horizontal ternary partition of blocks in a multi-type tree structure according to the present disclosure.
[0032] In FIG. 1, spatial prediction and / or temporal prediction may be performed. Spatial prediction (or "intra prediction") predicts a current video block using pixels from samples (called reference samples) of coded neighboring blocks in the same video image / slice. Spatial prediction reduces inherent spatial redundancy in video signals. Temporal prediction (also called "inter prediction" or "motion compensated prediction") predicts a current video block using reconstructed pixels from a coded video image. Temporal prediction reduces inherent temporal redundancy in video signals. A temporal prediction signal for a given CU is typically signaled by one or more motion vectors (MVs) that indicate the amount and direction of motion between the current CU and its temporal references. Furthermore, if multiple reference images are supported, a reference image index is additionally transmitted to identify which reference image in the reference image store the temporal prediction signal comes from. After spatial and / or temporal prediction, a mode decision block in the encoder selects an optimal prediction mode based, for example, on a rate-distortion optimization method. 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 are inverse quantized and inverse transformed to form a reconstructed residual, which is then added back to the prediction block to form a reconstructed signal of the CU. In addition, the reconstructed CU may be applied with in-loop filters, such as a deblocking filter, a sample adaptive offset (SAO), and an adaptive in-loop filter (ALF), before being put into a reference picture store and used to encode future video blocks. To form an output video bitstream, the coding mode (inter or intra), prediction mode information, motion information, and the quantized residual coefficients are all sent to an entropy coding unit for further compression and packaging to form a bitstream.
[0033] Figure 2 shows a schematic block diagram of a video decoder for VVC. Specifically, Figure 2 shows a block diagram of an exemplary decoder 200. The decoder 200 includes a bitstream 210, an entropy decoding 212, an inverse quantization 214, an inverse transform 216, an adder 218, an intra / inter mode selection 220, an intra prediction 222, a memory 230, an in-loop filter 228, a motion compensation 224, an image buffer 226, prediction related information 234, and a video output 232.
[0034] The decoder 200 is similar to the reconstruction-related parts present in the encoder 100 of FIG. 1. In the decoder 200, the input video bitstream 210 is first decoded by entropy decoding 212 to derive quantized coefficient levels and prediction correlation information. The quantized coefficient levels are then processed by inverse quantization 214 and inverse transform 216 to obtain a reconstructed prediction residual. The block predictor mechanism implemented in the intra / inter mode selector 220 is configured to perform intra prediction 222 or motion compensation 224 based on the decoded prediction information. A summer 218 is used to sum the reconstructed prediction residual from the inverse transform 216 and the prediction output generated by the block predictor mechanism to obtain a set of unfiltered reconstructed pixels.
[0035] The reconstructed blocks may further pass through an in-loop filter 228 before being stored in an image buffer 226, which is used as a reference image store. The reconstructed video in the image buffer 226 may be transmitted to drive a display device or may be used to predict future video blocks. When the in-loop filter 228 is open, it performs a filtering operation on the reconstructed pixels to derive the final reconstructed video output 232.
[0036] FIG. 2 shows a schematic block diagram of a block-based video decoder. The video bitstream is first entropy decoded in an entropy decoding unit. The coding mode and prediction information are sent to a spatial prediction unit (if intra-coded) or a temporal prediction unit (if inter-coded) to form a prediction block. The residual transform coefficients are sent to an inverse quantization unit and an inverse transform unit to reconstruct the residual block. The prediction block and the residual block are then added. The reconstructed block may be further passed through an in-loop filter before being stored in a reference picture store. The reconstructed video in the reference picture store is then sent to be used to drive a display device and predict future video blocks.
[0037] In general, the base intra prediction scheme applied in VVC is the same as that of HEVC, except that some modules have been further extended and / or improved, such as intra sub-partition (ISP) coding mode, extended intra prediction with wide-angle intra direction, position-related intra prediction combining (PDPC) and 4-tap intra interpolation.
[0038] Images, tiles, tiles and CTU partitions in VVC
[0039] In VVC, a tile is defined as a rectangular region of CTUs in a particular tile column and a particular tile row in a picture. A tile group is a combination of an integer number of tiles that are contained in only a single NAL unit in a picture. Essentially, the concept of a tile group is the same as a slice defined in HEVC. For example, an image is divided into tile groups and tiles. A tile is a sequence of CTUs that covers a rectangular region of an image. A tile group contains multiple tiles of an image. Two modes of tile groups 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 raster scanned in an image. In rectangular tile group mode, a tile group contains multiple tiles that jointly form a rectangular region in an image. The tiles in a rectangular tile group follow the tile raster scan order of the tile group.
[0040] FIG. 4 shows an example of a raster scan tile group partition of an image, where the image is divided into 12 tiles and 3 raster scan tile groups. FIG. 4 shows tiles 410, 412, 414, and 416. 、 418 , 420, 422, 424, 426, 428, 430 and 432 Each tile has 18 CTUs. More specifically, FIG. 4 shows an image with 18×12 intensity CTUs partitioned into 12 tiles and three tile groups (informational). 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.
[0041] Figure 5 shows an example of a rectangular tile group partition of an image, where the image is partitioned into 24 tiles (6 tile columns and 4 tile rows) and 9 rectangular tile groups. Figure 5 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. More specifically, Figure 5 shows an image with an 18x12 luminance CTU partitioned into 24 tiles and 9 tile groups (informational). The tile groups contain tiles, and the tiles contain CTUs. The nine rectangular tile groups are: (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; and (5) four tiles 538, 539, 540, 541, 542, 543, 544, and 545. Ru5 26, 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.
[0042] Large block size conversion with high frequency return to zero in VVC.
[0043] VTM4 enables large block size transforms up to a maximum size of 64x64, which is primarily used for high resolution video, e.g., 1080p and 4K sequences. For transform blocks with size (width or height, or both width and height) equal to 64, high frequency transform coefficients are zeroed out so that only low frequency coefficients remain. For example, for an MxN transform block (where M is the block width and N is the block height), if M=64, only the left 32 columns of transform coefficients are kept. Similarly, if N=64, only the top 32 rows of transform coefficients are kept. When transform skip mode is used for large blocks, the entire block is used without zeroing out any values.
[0044] Virtual Pipeline Data Unit (VPDU) in VVC
[0045] A Virtual Pipeline Data Unit (VPDU) is defined as a non-overlapping unit in a picture. In a hardware decoder, consecutive VPDUs are processed simultaneously in multiple pipeline stages. It is important to keep the VPDU size small because it is roughly proportional to the buffer size in most pipeline stages. 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) partitions can increase the VPDU size.
[0046] In order to keep the VPDU size to 64x64 luma samples, the following standard partition limits (as modified by syntax signaling) apply to VTM5:
[0047] CUs with width or height, or both width and height, equal to 128 are not allowed to be TT split.
[0048] For 128×N CUs with N≦64 (i.e., width equal to 128 and height less than 128), no horizontal BT is allowed.
[0049] For N×128 CUs with N≦64 (i.e., height equals 128 and width less than 128), no vertical BT is allowed.
[0050] 6A, 6B, 6C, 6D, 6E, 6F, 6G, and 6H show examples of TT and BT partitions that are not allowed in a VTM.
[0051] Coding and Decoding of Transform Coefficients in VVC
[0052] The encoding and decoding of transform coefficients in VVC is similar to HEVC in using non-overlapping coefficient groups (also called CGs or sub-blocks). However, there are some differences between them. In HEVC, each CG of a coefficient has a fixed size of 4×4. In VVC Draft 6, the CG size becomes dependent on the TB size. Thus, in VVC, various CG sizes (1×16, 2×8, 8×2, 2×4, 4×2, and 16×1) are available. The CGs in a coding block and the transform coefficients in the CG are coded according to a predefined scan order.
[0053] To limit the maximum number of context-coded binary digits per pixel, the area of the TB and the type of video components (e.g., luma and chroma components) are used to derive the maximum number of context-coded binary digits (CCB) for a TB. The maximum number of context-coded binary digits is TB_zosize*1.75, where TB_zosize indicates the number of samples in the TB after the coefficients are reverted to zero. Note that coded_sub_block_flag, a flag indicating whether the CG contains a non-zero coefficient, is not considered for the CCB count.
[0054] Coefficient return to zero is an operation performed on a transform block to force coefficients located in a particular region of the transform block to zero. For example, in current VVC, a 64x64 transform has an associated return to zero operation. Thus, all transform coefficients outside the top-left 32x32 region within a 64x64 transform block are forced to zero. In effect, in current VVC, for any transform block whose size exceeds 32 along a particular dimension, a coefficient return to zero operation is performed to force coefficients outside the top-left 32x32 region to zero.
[0055] Transform coefficient encoding / decoding in VVC begins by setting the variable remBinsPass1 to the maximum number of context-coded binary digits allowed (MCCB). In the encoding process, this variable is decremented by one each time a context-coded binary digit is signaled. If remBinsPass1 is 4 or more, first signal the coefficients by the syntax elements sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag, all of which use context-coded binary digits in the first pass. In the second pass, code the remainder of the level information of the coefficients by the syntax element abs_remainder using Golomb-rice codes and bypass-coded binary digits. If remBinsPass1 is less than 4 when encoding in the first pass, the current coefficient is not encoded in the first pass and is directly encoded by the syntax element dec_abs_level using the Golomb-Rice code and bypass-coded binary digits in the second pass. The Rice parameter derivation process for dec_abs_level[ ] is derived as specified in Table 3. After all the above level encodings, the symbols (sign_flag) of all scan positions where sig_coeff_flag is equal to 1 are finally encoded as bypassed binary digits. Such a process is shown in Figure 7. Reset remBinsPass1 for each TB. The transition using context-coded binary digits for sig_coeff_flag, abs_level_gt1_flag, par_level_flag and abs_level_gt3_flag and bypass-coded binary digits for the remaining coefficients occurs at most once per TB. For a coefficient sub-block, if remBinsPass1 is less than 4 before encoding the first coefficient, then encode the entire coefficient sub-block using bypass-coded binary digits.
[0056] FIG. 7 is a diagram illustrating a residual coding and decoding structure for a transform block.
[0057] A unified (identical) Rice parameter (RicePara) derivation is used to signal the syntaxes abs_remainder and dec_abs_level. The only difference is that the base level baseLevel is set to 4 and 0 to code for abs_remainder and dec_abs_level, respectively. The Rice parameter is determined based on the sum of the absolute levels of the five adjacent transform coefficients in the local template as well as the corresponding base level as follows:
[0058] RicePara = RiceParTable[ max(min( 31, sumAbs - 5 * baseLevel), 0) ]
[0059] The syntax and associated semantics of residual coding and decoding in the current VVC draft specification are shown in Tables 1 and 2, respectively. . table How to read number 1 V VC specifications See It can be attached. [Table 1] JPEG0007670851000002.jpg246165JPEG0007670851000003.jpg251165JPEG00076708510 00004.jpg249167JPEG0007670851000005.jpg249169JPEG0007670851000006.jpg213167 [Table 2] JPEG0007670851000008.jpg249166JPEG0007670851000009.jpg89164 [Table 3] [Table 4]
[0060] Residual coding and decoding for transform skip mode in VVC
[0061] Unlike HEVC, in which one residual encoding / decoding scheme is designed for encoding / decoding both transform coefficients and transform skip coefficients, in VVC, two separate residual encoding / decoding schemes are used for transform coefficients and transform skip coefficients (i.e., residuals), respectively.
[0062] In transform skip mode, the statistical properties of the residual signal differ from those of the transform coefficients, and no energy compaction around low frequency components was observed. The residual coding / decoding was modified to take into account the different signal properties of the (spatial) transform skip residual, including:
[0063] Do not signal the final x / y position.
[0064] If all previous flags are equal to 0, then coded_sub_block_flag is coded for each subblock except for the DC subblock.
[0065] sig_coeff_flag context modeling based on two adjacent coefficients.
[0066] The par_level_flag uses only one context model.
[0067] Added 5, 7, 9 more flags.
[0068] Modified Rice parameter derivation for residual binarization.
[0069] The context modeling for the sign flag is determined based on the left and top neighboring coefficient values, and parses the sign flag after sig_coeff_flag to keep all the context coded binary digits together.
[0070] As shown in Figure 8, the syntax elements sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, and par_level_flag are coded alternately for each residual sample in the first pass, then abs_level_gtx_flag is coded according to the bit plane in the second pass, and abs_remainder is coded in the third pass.
[0071] ·Path 1: sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, par_level_flag
[0072] ·Path 2: abs_level_gt3_flag, abs_level_gt5_flag, abs_level_gt7_flag, abs_level_gt9_flag
[0073] Pass 3: abs_remainder
[0074] FIG. 8 is a diagram illustrating a residual coding / decoding structure for a transform skip block.
[0075] The syntax and associated semantics of residual encoding / decoding for transform skip mode in the current VVC draft specification are shown in Table 5 and Table 2, respectively. . table How to read 5 V VC specifications See It can be attached. [Table 5] JPEG0007670851000013.jpg246168JPEG0007670851000014.jpg252170JPEG0007670851000015.jpg224169
[0076] quantization
[0077] In the current VVC, the maximum QP value is extended from 51 to 63, and the signaling of the initial QP is changed accordingly. When coding a non-zero value of slice_qp_delta, the initial value of SliceQpY can be changed at the slice segment layer. For transform skip blocks, the minimum allowed quantization parameter (QP) is defined as 4 because for QP=4, the quantization step becomes 1.
[0078] The same HEVC scalar quantization is also used with a new concept called dependent scalar quantization. Dependent scalar quantization refers to a method in which the set of allowed reconstruction values for a transform coefficient depends on the value of the transform coefficient level preceding the current transform coefficient level in the reconstruction order. The main effect of this method is that the allowed reconstruction vectors are packed more densely in an N (N represents the number of transform coefficients in a transform block) dimensional vector space compared to the traditional independent scalar quantization used in HEVC. This means that the average distortion between an input vector and the nearest reconstructed vector is reduced for a given average number of allowed reconstruction vectors per N-dimensional unit volume. The dependent scalar quantization method is realized by (a) defining two scalar quantizers with different reconstruction levels and (b) defining a process for switching between the two scalar quantizers.
[0079] The two scalar quantizers used (denoted Q0 and Q1) are shown in Figure 9. The position of the available reconstruction levels is uniquely specified by the quantization step Δ. The scalar quantizer used (Q0 or Q1) is implicitly signaled in the bitstream. In contrast, the quantizer for the current transform coefficient is determined by the parity of the transform coefficient level preceding the current transform coefficient in the coding / reconstruction order.
[0080] FIG. 9 illustrates two scalar quantizers used in the proposed dependent quantization method.
[0081] As shown in Figure 10A and Figure 10B, the switching between the two scalar quantizers (Q0 and Q1) is realized by a state machine with four quantizer states (QState). QState can use four different values: 0, 1, 2, and 3. It is uniquely determined by the parity of the transform coefficient level previous to the current transform coefficient in the coding / reconstruction order. At the start of the inverse quantization for a transform block, the state is set equal to 0. The transform coefficients are reconstructed in the scan order (i.e., the same order in which they were entropy decoded). After reconstructing the current transform coefficient, the state is updated as shown in Figure 10. Here, k represents the value of the transform coefficient level.
[0082] FIG. 10A is a transition diagram illustrating state transitions of the proposed dependent quantization.
[0083] FIG. 10B is a table illustrating quantizer selection for the proposed dependent quantization.
[0084] Signaling default and user-defined scaling matrices is also supported. The default mode scaling matrices are all flat and have elements equal to 16 for all TB sizes. IBC and intra coding modes currently share the same scaling matrix. Therefore, for user-defined matrices, the number of updates to MatrixType and MatrixType_DC are as follows:
[0085] MatrixType: 30 = 2 (2 is for intra and IBC / inter) x 3 (Y / CB / Cr components) x 5 (square TB size: 4x4 to 64x64 for luma, 2x2 to 32x32 for chroma)
[0086] MatrixType_DC: 14 = 2 (2 for intra and IBC / inter × 1 for Y component) × 3 (TB size: 16 × 16, 32 × 32, 64 × 64) + 4 (2 for intra and IBC / inter × 2 for CB / Cr component) × 2 (TB size: 16 × 16, 32 × 32)
[0087] The DC values are coded for the following scaling matrices 16x16, 32x32, 64x64 respectively. For TBs with size less than 8x8, all elements in the scaling matrix are signaled. For TBs with size 8x8 or more, only 64 elements in the 8x8 scaling matrix are signaled to become the base scaling matrix. To obtain a square matrix with size greater than 8x8, the 8x8 base scaling matrix is upsampled (by element copying) to the corresponding square dimensions (i.e. 16x16, 32x32, 64x64). When applying return to zero of high frequency coefficients for 64-point transform, the corresponding high frequencies in the scaling matrix are also zeroed. That is, if the width or height of the TB is 32 or more, only the left or top half of the coefficients are kept and the remaining coefficients are assigned zeros. The number of elements signaled for the 64x64 scaling matrix is also reduced from 8x8 to three 4x4 sub-matrices. This is because the bottom right 4x4 element is not used.
[0088] Context modeling for transform coefficient encoding / decoding
[0089] The choice of the probability model for the syntax elements related to the absolute values of the transform coefficient levels depends on the values of the absolute levels in the local neighborhood or the absolute levels of the partial reconstruction. The template used is shown in FIG.
[0090] Figure 11 shows a diagram of the template for selecting a probabilistic model. The black square designates the current scanning position, and the square with an "x" represents the local neighborhood to be used.
[0091] The probability model chosen depends on the sum of the absolute levels (or absolute levels of partial reconstructions) in the local neighborhood and the number of absolute levels in the local neighborhood greater than 0 (given by the number of sig_coeff_flags equal to 1). Context modeling and binarization depend on the following metrics for the local neighborhood:
[0092] numSig: The number of non-zero levels in the local neighborhood
[0093] sumAbs1: The sum of the absolute levels (absLevel1) of the partial reconstructions after the first pass in the local neighborhood
[0094] sumAbs: the sum of the absolute levels of reconstruction in a local neighborhood
[0095] Diagonal position (d): The sum of the horizontal and vertical coordinates of the current scan position within the transform block.
[0096] Based on the values of numSig, sumAbs1 and d, select a probability model for encoding sig_coeff_flag, abs_level_gt1_flag, par_level_flag and abs_level_gt3_flag. Based on the values of sumAbs and numSig, select Rice parameters for binarization of abs_remainder and dec_abs_level.
[0097] In the current VVC, the reduced 32-point MTS (also called RMTS32) is based on high-frequency coefficient skipping and is used to reduce the computational complexity of the 32-point DST-7 / DCT-8. And it involves coefficient coding changes including all types of zero return (i.e., the existing zeroing out of high-frequency components in RMTS32 and DCT2). Specifically, the binarization of the last non-zero coefficient position coding is coded based on the reduced TU size, and the context model selection for the last non-zero coefficient position coding is determined by the original TU size. Also, 60 context models are used to code the sig_coeff_flag of the transform coefficient. The selection of the context model index is based on the sum of absolute levels of up to five previous partial reconstructions and a dependent quantization state QState, called locSumAbsPass1, as follows:
[0098] If cIdx=0, ctxInc is derived as follows: ctxInc=12×Max(0,QState-1)+ Min((locSumAbsPass1+1)>>1,3)+(d<2?8:(d<5?4:0))
[0099] Otherwise (cIdx is greater than 0), derive ctxInc as follows: ctxInc=36+8×Max(0,QState-1)+ Min((locSumAbsPass1+1)>>1,3)+(d<2?4:0)
[0100] Palette Mode
[0101] The basic idea behind paletted mode is that samples in a CU are represented by a set of representative color values. This set is called the palette. Color values excluded from the palette can also be indicated by signaling them as escape colors, signaling the values of the three color components directly in the bitstream. This is shown in Figure 12.
[0102] 12 is a diagram showing an example of a block coded in palette mode, including a block 1210 coded in palette mode and a palette 1220.
[0103] In Figure 12, the palette size is 4. The first three samples are reconstructed using palette entries 2, 0, and 3, respectively. The blue sample represents the escape symbol. The CU level flag palette_escape_val_present_flag indicates whether the escape symbol is present in the CU. If the escape symbol is present, the palette size is increased by 1 and the last index is used to indicate the escape symbol. Thus, in Figure 12, index 4 is assigned to the escape symbol.
[0104] To decode a palette-coded block, the decoder needs to have the following information:
[0105] Pallet table
[0106] Palette Index
[0107] If the palette index corresponds to an escape symbol, additional overhead is signaled to indicate the corresponding color value of the sample.
[0108] Also, on the encoder side, it is necessary to derive the appropriate palette to be used with the CU.
[0109] A modified k-means cluster algorithm is used to derive a palette for lossy coding. The first sample of a block is added to the palette. Then, for each next sample from that block, the sum of absolute differences (SAD) between the sample and each current palette color is calculated. If the distortion of each component in the component is less than the threshold of the palette entry corresponding to the minimum SAD, then add the sample to the cluster belonging to that palette entry. Otherwise, add the sample as a new palette entry. If the number of samples mapped to a cluster exceeds the threshold, then the center of the cluster is updated to become the palette entry of that cluster.
[0110] The next step is to sort the clusters in descending order of use. Then, update the palette entry corresponding to each entry. Usually, the cluster centers are used as palette entries. However, considering the cost of encoding palette entries, a rate-distortion analysis is performed to analyze whether an entry from the palette predictor may be suitable to be used as an updated palette entry instead of a center. The process continues until all clusters are processed or the maximum palette size is reached. Finally, if a cluster has only a single sample and the corresponding palette entry is not included in the palette predictor, convert that sample to an escape symbol. Also, remove repeated palette entries and merge those clusters.
[0111] After deriving the palette, each sample in the block is assigned the index of the closest palette entry (in the SAD). Then we assign the sample to either "INDEX" or "COPY_ABOVE" mode. For each sample, we have either "INDEX" or "COPY_ABOVE" mode. Then we calculate the cost of encoding the modes. We choose the mode with the lowest cost.
[0112] To encode the palette entries, a palette predictor is maintained. 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 row, each slice, and each tile.
[0113] For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette or not. This is shown in Figure 13.
[0114] 13 is a diagram illustrating the use of a palette predictor to signal palette entries, which includes a previous palette 1310 and a current palette 1320.
[0115] We signal the reuse flag by run-length encoding of zeros. Then we signal the number of the new palette entry using a zeroth order exponential-Golomb code. Finally, we signal the component values for the new palette entry.
[0116] We code the palette index using horizontal and vertical traverse scans as shown in Figures 14A and 14B. We explicitly signal the scan order in the bitstream using palette_transpose_flag.
[0117] FIG. 14A is a diagram showing a horizontal traverse scan.
[0118] FIG. 14B is a diagram showing a vertical traverse scan.
[0119] To encode the palette index, a palette mode based on linear coefficient groups (CGs) is used, which divides the CU into multiple segments with 16 samples based on the traverse scanning mode. For each CG, the index run, palette index value and quantized color for the escape mode are sequentially encoded / analyzed, as shown in Figures 15A and 15B.
[0120] FIG. 15A illustrates a sub-block based index map traversal for a palette.
[0121] FIG. 15B illustrates a sub-block based index map traversal for a palette.
[0122] The two main palette sample modes "INDEX" or "COPY_ABOVE" are used to encode the palette index. As explained earlier, the escape symbol is assigned an index equal to the maximum palette size. In "COPY_ABOVE" mode, we copy the palette index of the sample in the row above. In "INDEX" mode, we signal the palette index explicitly. The encoding order for palette run encoding in each segment is as follows:
[0123] For each pixel, signal a context-encoded binary digit run_copy_flag=0, which indicates whether the pixel has the same mode as the previous pixel (i.e., the previously scanned pixel and the current pixel both have run type COPY_ABOVE, or the previously scanned pixel and the current pixel both have run type INDEX) and the same index value. Otherwise, signal run_copy_flag=1.
[0124] If a pixel has a different mode than the previous pixel, it signals a context-encoded binary digit copy_above_palette_indices_flag indicating the run type of the pixel (i.e., INDEX or COPY_ABOVE). If the sample is in the first row (horizontal traverse scan) or the first column (vertical traverse scan), the decoder does not need to parse the run type because INDEX mode is used by default. Also, the decoder does not need to parse the run type if the previously parsed run type was COPY_ABOVE. After palette run coding is performed on the pixels in one segment, bypass coding is performed on the index value (palette_idx_idc) for INDEX mode and the quantized escape color (palette_escape_val).
[0125] Improved residual and coefficient coding / decoding
[0126] In VVC, when encoding transform coefficients, a unified (identical) Rice parameter (RicePara) derivation is used to signal the syntax of abs_remainder and dec_abs_level. The only difference is that the base level baseLevel is set to 4 and 0 to encode abs_remainder and dec_abs_level, respectively. The Rice parameter is determined based on the sum of the absolute levels of the five adjacent transform coefficients in the local template as well as the corresponding base level, as follows:
[0127] RicePara=RiceParTable[max(min(31,sumAbs-5×baseLevel),0)]
[0128] In other words, we adaptively determine the binary codewords for the syntax elements abs_remainder and dec_abs_level based on the level information of the neighboring coefficients. Because this codeword determination is performed on a sample-by-sample basis, additional logic is required to handle the codeword adaptation for coefficient coding.
[0129] Similarly, when encoding a residual block in transform skip mode, we adaptively determine the binary codeword of the syntax element abs_remainder based on the level information of the neighboring residual samples.
[0130] Furthermore, when coding syntax elements related to residual coding / decoding or transform coefficient coding, the selection of the probability model depends on the level information of adjacent levels, which requires additional logic and additional context models.
[0131] In the current design, the binarization of escape samples is derived by invoking a third-order exponential-Golomb binarization process. There is also space to further improve the performance.
[0132] In the current VVC, two different level mapping schemes are available, which are applied to normal transform and transform skip, respectively. Each level mapping scheme is associated with different conditions, mapping functions and mapping positions. For blocks to which normal transform is applied, a level mapping scheme is used after the number of context coded binary digits (CCB) exceeds the limit. The mapping position, represented as ZeroPos[n], and the mapping result, represented as AbsLevel[xC][yC], are derived as specified in Table 2. For blocks to which transform skip is applied, another level mapping scheme is used before the number of context coded binary digits (CCB) exceeds the limit. The mapping position, represented as PredCoeff, and the mapping result, represented as AbsLevel[xC][yC], are derived as specified in Table 5. From a standardization point of view, such a non-uniform design may not be optimal.
[0133] For profiles with more than 10 bits in HEVC, extended_precision_processing_flag=1 specifies that extended dynamic range is used for coefficient analysis and inverse transform processing. In the current VVC, residual coding / decoding or transform skip coding for transform coefficients with more than 10 bits has been reported as the reason for significant performance degradation. There is also space to further improve the performance.
[0134] Proposed method
[0135] In this disclosure, several methods are proposed to solve the problems mentioned in the improvement of residual and coefficient coding section. It should be noted that the following methods can be applied independently or jointly.
[0136] According to a first aspect of the present disclosure, it is proposed to encode certain syntax elements (e.g., abs_remainder) in residual coding and decoding using a fixed binary codeword set. The binary codewords can be formed using different methods. Some exemplary methods are as follows:
[0137] First, the same process for determining the codeword for abs_remainder is used as is currently used in VVC, but a fixed Rice parameter (eg, 1, 2 or 3) is always chosen.
[0138] Second, fixed-length binarization.
[0139] Third, truncated rice binarization.
[0140] Fourth, a truncated binary (TB) binarization process.
[0141] Fifth, the kth-th order Exponential Golomb Binarization Process (EGK).
[0142] Sixth, finite k-th order exponential Golomb binarization.
[0143] According to a second aspect of the present disclosure, it is proposed to encode certain syntax elements (e.g., abs_remainder and dec_abs_level) in transform coefficient coding using a fixed codeword set. The binary codewords can be formed using different methods. Some exemplary methods are as follows:
[0144] First, the same process for determining the codewords for abs_remainder and dec_abs_level is used as that used in the current VVC, but a fixed Rice parameter is selected, e.g., 1, 2, or 3. The abs_remainder and dec_abs_level used in the current VVC can still differ in the value of baseLevel (e.g., baseLevel is set to 4 and 0 to code abs_remainder and dec_abs_level, respectively).
[0145] Second, the same process for determining the codewords for abs_remainder and dec_abs_level is used as is currently used in VVC, but a fixed Rice parameter is chosen, e.g., 1, 2, or 3. The value of baseLevel for abs_remainder and dec_abs_level is chosen to be the same, e.g., both use 0 or both use 4.
[0146] Third, fixed-length binarization.
[0147] Fourth, truncated rice binarization.
[0148] Fifth, a truncated binary (TB) binarization process.
[0149] Sixth, the kth-th order Exponential Golomb Binarization Process (EGK).
[0150] Seventh, finite k-th order exponential Golomb binarization.
[0151] According to a third aspect of the present invention, it is proposed that syntax elements related to residual coding / decoding or coefficient coding (e.g., abs_level_gtx_flag) can be coded with a single context, eliminating the context selection based on adjacent decoding level information.
[0152] According to a fourth aspect of the present disclosure, it is proposed to code a specific syntax element (e.g., abs_remainder) in residual coding / decoding with a variable binary codeword set, and determine the selection of the binary codeword set based on specific coding information of the current block (e.g., TB / CB and / or slice-related quantization parameter (QP), prediction mode of the CU (e.g., IBC mode or intra or inter) and / or slice type (e.g., I slice, P slice or B slice)). Different methods can be used to derive the variable set of binary codewords, some exemplary methods of which are as follows:
[0153] First, the same process for determining the codeword for abs_remainder is used as is currently used in VVC, but with different Rice parameters.
[0154] Second, the kth-th order Exponential Golomb Binarization Process (EGK).
[0155] Third, finite k-th order exponential Golomb binarization. [Table 6]
[0156] The same method described in the fourth aspect is also applicable to transform coefficient coding. According to the fifth aspect of the present disclosure, a variable set of binary codewords is used to code specific syntax elements (e.g., abs_remainder and dec_abs_level) in transform coefficient coding, and the selection of the binary codeword set is determined based on specific coding information of the current block (e.g., quantization parameter (QP) related to TB / CB and / or slice, prediction mode of the CU (e.g., IBC mode or intra or inter) and / or slice type (e.g., I slice, P slice or B slice)). Similarly, different methods can be used to derive a variable set of binary codewords, and some exemplary methods are as follows.
[0157] First, the same as the process currently used in VVC, which is used to determine the codeword for abs_remainder, but different Rice parameters are used.
[0158] Second, the k-th order exponential Golomb binarization process (EGK).
[0159] Third, finite k-th order exponential Golomb binarization.
[0160] In the method as described above, different binary codeword sets can be derived with different Rice parameters. For a given block of residual samples, the Rice parameter used is determined based on the CU QP (represented as QP CU instead of adjacent level information). As shown in Table 6, TH1 to TH4 are predetermined thresholds satisfying (TH1 < TH2 < TH3 < TH4), and K0 to K4 are specific examples of predetermined Rice parameters. It should be noted that actually the same logic can be implemented differently. For example, some equations or look-up tables can be used to derive the same Rice parameter based on the QP value of the current CU as shown in Table 6.
[0161] According to a fifth aspect of the present disclosure, a set of parameters and / or thresholds related to codeword determination for a syntax element of transform coefficient coding and / or transform skip residual coding / decoding is signaled to a bitstream. When encoding (e.g., arithmetic coding) the syntax element by an entropy encoder, the determined codeword is used as a binarization codeword.
[0162] It should be noted that the set of parameters and / or thresholds may be a complete set or a subset of all parameters and thresholds relevant for codeword determination of a syntax element. The set of parameters and / or thresholds may be signaled at different levels in the video bitstream, for example at a sequence level (e.g., a sequence parameter set), a picture level (e.g., a picture parameter set and / or a picture header), a slice level (e.g., a slice header), a coding tree unit (CTU) level, or a coding unit (CU) level.
[0163] In one example, Rice parameters are signaled in slice headers, picture headers, PPS and / or SPS, where the Rice parameters are used to determine codewords for encoding the abs_remainder syntax in transform skip residual coding and decoding. When a CU is coded in transform skip mode and the CU is associated with the slice headers, picture headers, PPS and / or SPS, etc., the signaled Rice parameters are used to determine codewords for encoding the abs_remainder syntax.
[0164] According to a sixth aspect of the present disclosure, a set of parameters and / or thresholds related to codeword determination described in the first and second aspects is used for syntax elements of transform coefficient coding and / or transform skip residual coding / decoding. Also, different sets can be used depending on whether the current block contains luma residual / coefficients or chroma residual / coefficients. When encoding (e.g., arithmetic coding) the syntax elements by an entropy encoder, the determined codeword is used as a binary codeword.
[0165] In one example, the codeword used for abs_remainder associated with the transform residual coding and decoding currently used in VVC is used for both luma and chroma blocks, but different fixed Rice parameters are used for luma and chroma blocks (e.g., K1 for luma blocks and K2 for chroma blocks, where K1 and K2 are integers).
[0166] According to a seventh aspect of the present disclosure, a set of parameters and / or thresholds related to codeword determination for a syntax element of transform coefficient coding and / or transform skip residual coding / decoding is signaled to the bitstream. Also, different sets can be signaled for luma blocks and chroma blocks. When encoding (e.g., arithmetic coding) the syntax element by an entropy encoder, the determined codeword is used as a binarization codeword.
[0167] A similar method as described above can also be applied to encoding escape values in palette mode, e.g. palette_escape_val.
[0168] According to an eighth aspect of the present disclosure, a set of different binary code words for encoding escape values in palette mode can be derived with different k-th order Exponential-Golomb binarizations. In one example, for a given block of escape samples, the QP value for that block (QP CUBased on the QP value of the block, the exponential-Golomb parameter to be used (i.e., the value of k) is determined. Using the same example as shown in Table 6, the value of parameter k can be derived based on the given QP value of the block. Four different thresholds (TH1-TH4) are listed in this example, but the relationship between these thresholds and the QP CU Based on this, five different k values (K0 to K4) can be derived. In particular, the number of thresholds is used only for the purpose of explanation. In practice, a different number of thresholds can be used to divide the entire QP value range into a different number of QP value segments, and for each QP value segment, a corresponding binary codeword for encoding the escape value of a block encoded in palette mode can be derived using a different k value. It should also be noted that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using several equations or look-up tables.
[0169] According to a ninth aspect of the present disclosure, a set of parameters and / or thresholds related to a codeword decision for a syntax element of an escape sample is signaled to the bitstream. When encoding (e.g., arithmetically encoding) the syntax element of the escape sample by an entropy encoder, the determined codeword is used as a binary codeword.
[0170] It should be noted that the set of parameters and / or thresholds may be a complete set or a subset of all parameters and thresholds relevant for codeword decisions for a syntax element. The set of parameters and / or thresholds may be signaled at different levels in the video bitstream, for example at a sequence level (e.g., a sequence parameter set), a picture level (e.g., a picture parameter set and / or a picture header), a slice level (e.g., a slice header), a coding tree unit (CTU) level, or a coding unit (CU) level.
[0171] In one example according to the embodiment, the codeword for encoding the construct palette_escape_val in palette mode is determined by K-th order exponential-Golomb binarization, and the value of k is signaled in the bitstream to the decoder. The value of k may be signaled at different levels, e.g., at slice header, picture header, PPS and / or SPS, etc. When a CU is encoded in palette mode and the CU is associated with the slice header, picture header, PPS and / or SPS, etc. mentioned above, the codeword for encoding the construct palette_escape_val is determined by the signaled exponential-Golomb parameter.
[0172] Coordination of level mapping for transform skip mode and normal transform mode
[0173] According to a tenth aspect of the present disclosure, the same condition for applying level mapping is used for both transform skip mode and normal transform mode. In one example, it is proposed to apply level mapping after the number of context coded binary digits (CCB) exceeds the limit for both transform skip mode and normal transform mode. In another example, it is proposed to apply level mapping before the number of context coded binary digits (CCB) exceeds the limit for both transform skip mode and normal transform mode.
[0174] According to an eleventh aspect of the present disclosure, the same method for deriving mapping positions in level mapping is used for both transform skip mode and normal transform mode. In one example, it is proposed to apply the derivation method of mapping positions in level mapping used in transform skip mode to normal transform mode as well. In another example, it is proposed to apply the derivation method of mapping positions in level mapping used in normal transform mode to transform skip mode as well.
[0175] According to a twelfth aspect of the present disclosure, the same level mapping method is applied to both the transform skip mode and the normal transform mode. In one example, it is proposed to apply the level mapping function used in the transform skip mode to the normal transform mode as well. In another example, it is proposed to apply the level mapping function used in the normal transform mode to the transform skip mode as well.
[0176] Simplifying the derivation of Rice parameters in residual coding / decoding
[0177] According to the thirteenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in the Golomb-Rice code, it is proposed to derive the Rice parameters with simple logic (such as shifts and division) instead of a lookup table. According to the present disclosure, the lookup table specified in Table 4 can be eliminated. In one example, the Rice parameter cRiceParam is derived as cRiceParam=(locSumAbs>>n), where n is a positive number, e.g., 3. It is noteworthy that in practice, the same result can be achieved using other different logic, such as a division operation of a value equal to the nth power of 2. An example of the corresponding decoding process based on the VVC draft is shown below, with the modified content indicated in bold and italic font and the deleted content indicated in italic font with deletion line. [Table 7]
[0178] According to a fourteenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in Golomb-Rice code, it is proposed to derive the Rice parameters using fewer adjacent positions. In one example, when encoding the syntax elements of abs_remainder / dec_abs_level, it is proposed to derive the Rice parameters using only two adjacent positions. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font, and the deleted content shown in italic font. [Table 8]
[0179] In another example, when encoding the syntax elements abs_remainder / dec_abs_level, it is proposed to use only one adjacent position to derive the Rice parameters. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font, and the deleted content shown in italic font. [Table 9]
[0180] According to a fifteenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in Golomb-Rice code, it is proposed to adjust the value of locSumAbs and derive the Rice parameters using different logic based on the value of baseLevel. In one example, an additional scaling and offset operation is applied in the form of "(locSumAbs-baseLevel×5)×alpha+Beta". When alpha takes a value of 1.5 and Beta takes a value of 1, the corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font and the deleted content shown in italic font. [Table 10]
[0181] According to the 16th aspect of the present invention, when encoding the syntax elements of abs_remainder / dec_abs_level in Golomb-Rice code, it is proposed to remove the trimming operation to derive the Rice parameters. According to the present disclosure, the corresponding decoding process based on the VVC draft is shown below, where the modified content is shown in bold and italic font, and the deleted content is shown in italic font. [Table 11]
[0182] According to the present disclosure, the corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font, and the deleted content shown in italic font: [Table 12]
[0183] According to a seventeenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in Golomb-Rice code, it is proposed to change the initial value of locSumAbs from 0 to a non-zero integer to derive the Rice parameters. In one example, an initial value of 1 is assigned to locSumAbs. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font and the deleted content shown in italic font: [Table 13]
[0184] According to the eighteenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in the Columbus-Rice code, it is proposed to derive the Rice parameters using the maximum of the adjacent position level values, instead of the sum of the adjacent position level values. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font, and the deleted content shown in italic font: [Table 14]
[0185] According to a nineteenth aspect of the present disclosure, when encoding the syntax elements of abs_remainder / dec_abs_level in Golomb-Rice code, it is proposed to derive the Rice parameter based on the relative width 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. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font and the deleted content shown in italic font. [Table 15]
[0186] In another example, the Rice parameter is derived based on the sum of the (AbsLevel-BasLevel) values of adjacent positions whose AbsLevel value is greater than the base level. The corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font and the deleted content shown in italic font. [Table 16]
[0187] An example of the VVC draft decoding process is shown below, with the changes shown in bold and italic font and the deletions shown in italic font. [Table 17]
[0188] Simplification of Level Mapping Position Derivation in Residual Coding and Decoding
[0189] According to the twentieth aspect of the present disclosure, it is proposed to remove QState from the derivation of ZeroPos[n], so that ZeroPos[n] is derived based only on cRiceParam. An example of the corresponding decoding process based on the VVC draft is shown below, where the modified content is shown in bold and italic font, and the deleted content is shown in italic font. [Table 18]
[0190] According to the twenty-first aspect of the present 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 the changed content is shown in bold and italic font, and the deleted content is shown in italic font: [Table 19]
[0191] According to the twenty-second aspect of the present disclosure, it is proposed to derive ZeroPos[n] based on the values of AbsLevel at adjacent positions. In one example, ZeroPos[n] is derived based on the maximum value of AbsLevel[xC+1][yC] and AbsLevel[xC][yC+1]. An example of the corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font, and the deleted content shown in italic font. [Table 20]
[0192] According to the twenty-third aspect of the present disclosure, it is proposed to derive both cRiceParam and ZeroPos[n] based on the maximum of all AbsLevel values of the neighboring positions. An example of the corresponding decoding process based on the VVC draft is shown below, where the changed content is shown in bold and italic font, and the deleted content is shown in italic font: [Table 21]
[0193] A similar method described above can also be applied to derive PredCoeff in residual coding and decoding for transform skip mode. In one example, the variable PredCoeff is derived as follows:
[0194] PredCoeff=Max(absLeftCoeff,absAboveCoeff)+1
[0195] Residual coding and decoding for transform coefficients
[0196] In this disclosure, in order to solve the problems pointed out in the "Improvement of Residual and Coefficient Coding" section, a method is provided to simplify and / or further improve the existing design of residual coding and decoding. Generally, the main features of the technology proposed in this disclosure can be summarized as follows:
[0197] First, we adjust the Rice parameter derivation, which is normally used in residual coding / decoding, based on the current design.
[0198] Second, it modifies the binary method normally used in residual coding and decoding.
[0199] Third, we modify the Rice parameter derivation that is normally used in residual coding and decoding.
[0200] Derivation of Rice Parameter in Residual Encoding and Decoding Based on the Current Design
[0201] According to the 24th aspect of the present disclosure, a specific syntax element (e.g., abs_remainder / dec_abs_level) in residual encoding and decoding is encoded by a modified method of Rice parameter derivation, and a selection is determined based on specific encoding information of the current block (e.g., quantization parameter or encoding bit depth related to TB / CB and / or slice / profile) and / or a new flag (e.g., extended_precision_processing_flag) related to the TB / CB / slice / image / sequence level. Different methods can be used to derive the Rice parameter, and some exemplary methods are as follows.
[0202] First, cRiceParam = (cRiceParam << a) + (cRiceParam >> b) + c. Here, a, b, and c are positive numbers, for example, {a, b, c} = {1, 1, 0}. It should be noted that in practice, the same result can be achieved using other different logics, such as multiplication by a value equal to a power of 2.
[0203] Second, cRiceParam = (cRiceParam << a) + b. Here, a and b are positive numbers, for example, {a, b} = {1, 1}. It should be noted that in practice, the same result can be achieved using other different logics, such as multiplication by a value equal to a power of 2.
[0204] Third, cRiceParam = (cRiceParam × a) + b. Here, a and b are positive numbers, for example, {a, B} = {1.5, 0}. It should be noted that in practice, the same result can be achieved using other different logics, such as multiplication by a value equal to a power of 2.
[0205] An example of the corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font and the deleted content shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 22. It is noteworthy that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters based on the bit depth value of the current CU / sequence. [Table 22]
[0206] In another example, if BitDepth is equal to or greater than a predetermined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16), the rice parameter cRiceParam is set to cRiceParam=(cRiceParam<<a)+(cRiceParam> >b)+c, where a, b, and c are positive numbers, e.g., 1. An example of the corresponding decoding process based on the VVC draft is shown below, with the modified content shown in bold and italic font and the deleted content shown in italic font. The modifications to the VVC draft are shown in bold and italic font in Table 23. It is noteworthy that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters based on the bit depth value of the current CU / sequence. [Table 23]
[0207] Binary methods in residual coding and decoding for profiles above 10 bits.
[0208] According to the 25th aspect of the present disclosure, a specific syntax element (e.g., abs_remainder / dec_abs_level) in residual encoding / decoding is encoded with a binary codeword variable set, and a selection is determined based on specific encoding information of the current block (e.g., quantization parameters or encoding bit depth related to TB / CB and / or slice / profile) and / or a new flag (e.g., extended_precision_processing_flag) related to TB / CB / slice / image / sequence level. Different methods can be used to derive the binary codeword variable set, and some exemplary methods are as follows.
[0209] First, the same process as that used in the current VVC for determining the codeword for abs_remainder is used, but a fixed Rice parameter (e.g., 2, 3, 4, 5, 6, 7, or 8) is always selected. The fixed value can be different under different conditions according to specific encoding information of the current block (e.g., quantization parameters or encoding bit depth related to TB / CB and / or slice / profile) and / or syntax elements (e.g., rice_Parameter_value) related to TB / CB / slice / image / sequence level. As shown in Table 24, TH1 to TH4 are predetermined threshold values satisfying (TH1 < TH2 < TH3 < TH4), and K0 to K4 are specific examples of predetermined Rice parameters. It should be noted that the same logic can actually be implemented differently. For example, some equations or look-up tables can be used to derive the same Rice parameter based on the bit depth value of the current CU / sequence as shown in Table 24.
[0210] Second, fixed-length binarization.
[0211] Third, truncated Rice binarization.
[0212] Fourth, a truncated binary (TB) binarization process.
[0213] Fifth, the kth order exponential-Golomb binarization process (EGK).
[0214] Sixth, finite k-th order exponential Golomb binarization. [Table 24]
[0215] In one example, if a new flag (e.g., extended_precision_processing_flag) is equal to 1, the Rice parameter cRiceParam is fixed to n, where n is a positive number (e.g., 2, 3, 4, 5, 6, 7, or 8). The fixed value can be different in different conditions. An example of a corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font and the deleted content shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 25. [Table 25]
[0216] In another example, it is proposed to use only one fixed value for the Rice parameter when encoding the abs_remainder / dec_abs_level syntax elements if the new flag (e.g., extended_precision_processing_flag) is equal to 1. An example of the corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font and the deleted content shown in italic font. The changes in the VVC draft are shown in bold and italic in Table 26. [Table 26]
[0217] In another example, if BitDepth is equal to or greater than 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 such as 4, 5, 6, 7, or 8. The fixed value can be different for 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 italic font in Table 27, and deletions are shown in italic font. [Table 27]
[0218] In another example, it is proposed to use only one fixed value for the Rice parameter when encoding the syntax elements of abs_remainder / dec_abs_level if BitDepth is greater than a predefined threshold (e.g., 10, 11, 12, 13, 14, 15, or 16). 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), the modified content is shown in bold and italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 28. [Table 28]
[0219] Rice parameter derivation in residual coding / decoding
[0220] According to the 26th aspect of the present disclosure, it is proposed to code a specific syntax element (e.g., abs_remainder / dec_abs_level) in residual coding / decoding with a modified method of Rice parameter derivation, and determine the selection based on the specific coding information of the current block (e.g., quantization parameters or coding bit depth related to TB / CB and / or slice / profile) and / or a new flag (e.g., extended_precision_processing_flag) related to TB / CB / slice / image / sequence level. Different methods can be used to derive Rice parameters, and some exemplary methods are as follows:
[0221] First, it is proposed to use a counter to derive the Rice parameter. The counter is determined based on the values of the coding coefficients of the current block and certain coding information (e.g., component ID). As a concrete example, riceParameter=counter / a, where a is a positive number, e.g., 4, and two counters (divided by luma / chroma) are maintained. These counters are reset to 0 at the start of each slice. When coding is done, if it is the first coefficient coded in a sub-TU, the counters are updated as follows: if (coeffValue >= (3 << rice)) counter++ if (((coeffValue << 1) < (1 << riceParameter)) && (counter > 0)) counter--.
[0222] Second, it is proposed to add a shift operation to the Rice parameter derivation in VVC. The shift is determined based on the value of the coding coefficient. An example of the corresponding decoding process based on the VVC draft is shown below, where the shift is determined according to the counters of Method 1, the changed content is shown in bold and italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 29. [Table 29]
[0223] No. 3 In , it is proposed to add a shift operation to the Rice parameter derivation in VVC. The shift is determined based on the specific coding information of the current block (e.g., TB / CB and / or coding bit depth associated with slice / profile (e.g., 14-bit profile 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 counters of Method 1, the changed content is shown in bold and italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 30. [Table 30]
[0224] Residual coding and decoding for transform skipping
[0225] According to the twenty-seventh aspect of the present disclosure, it is proposed to code a specific syntax element (e.g., abs_remainder) in transform skip residual coding and decoding with a binary codeword variable set, and determine the selection based on the specific coding information of the current block (e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile) and / or a new flag (e.g., extended_precision_processing_flag) associated with TB / CB / slice / image / sequence level. Different methods can be used to derive the variable binary codeword variable set, and some exemplary methods are as follows:
[0226] First, the same process as that currently used in VVC for determining the codeword for abs_remainder is used, but a fixed Rice parameter (e.g., 2, 3, 4, 5, 6, 7, or 8) is always selected. The fixed value can be different under different conditions according to the specific coding information of the current block (e.g., quantization parameter related to TB / CB and / or slice / profile, frame type (e.g., I, P, or B), component ID (e.g., luminance or chrominance), color format (e.g., 420, 422, 444), or coding bit depth) and / or syntax elements related to TB / CB / slice / image / sequence level (e.g., rice_Parameter_value). As shown in Table 7, TH1~TH4 are predetermined threshold values satisfying (TH1 < TH2 < TH3 < TH4), and K0~K4 are specific examples of predetermined Rice parameters. It should be noted that the same logic can actually be implemented differently. For example, some equations or look-up tables can be used to derive the same Rice parameter based on the bit depth value of the current CU / sequence as shown in Table 7.
[0227] Second, fixed-length binarization.
[0228] Third, truncated Rice binarization.
[0229] Fourth, truncated binary (TB) binarization process.
[0230] Fifth, k-th order exponential Golomb binarization process (EGK).
[0231] Sixth, finite k-th order exponential Golomb binarization.
[0232] 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 italic font in Table 31, and the deleted content is shown in italic font. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using some equations or lookup tables. [Table 31]
[0233] In another example, it is proposed to use only one fixed value for the Rice parameter when encoding the abs_remainder syntax element if the new flag (e.g., extended_precision_processing_flag) is equal to 1. An example of the corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font and the deleted content shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 32. [Table 32]
[0234] In another example, if a new flag (e.g., extended_precision_processing_flag) is equal to 1, the Rice parameter cRiceParam is fixed to n, where n is a positive number (e.g., 2, 3, 4, 5, 6, 7, or 8). The fixed value can be different in different conditions. An example of a corresponding decoding process based on the VVC draft is shown below, with the changed content shown in bold and italic font and the deleted content shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 33. [Table 33]
[0235] In another example, if BitDepth is equal to or greater than 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 such as 4, 5, 6, 7, or 8. The fixed value can be different in 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), the modified content is shown in bold and italic font, and the deleted content is shown in italic font. The changes to the VVC draft are shown in bold and italic font in Table 34. [Table 34]
[0236] In another example, a control flag is signaled in the slice header to indicate whether to enable or disable signaling of the Rice parameter for the transform skip block. When the control flag is signaled as enabled, a syntax element is further signaled for each transform skip slice to indicate the Rice parameter for that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no syntax element is further signaled to indicate the Rice parameter for the transform skip slice, and a default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2), the changed content is indicated in bold and italic font, and the deleted content is indicated in italic font. The changes to the VVC draft are indicated in bold and italic font in Table 35. Of note, sh_ts_residual_coding_rice_index can be coded in different ways and / or have a maximum value. For example, u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string using n bits written left to right) may be used to encode / decode the same syntax element.
[0237] Slice Header Syntax [Table 35]
[0238] sh_ts_residual_coding_rice_flag=1 specifies that sh_ts_residual_coding_rice_index may be present in the current slice. sh_ts_residual_coding_rice_flag=0 specifies that sh_ts_residual_coding_rice_index is not present in the current slice. If sh_ts_residual_coding_rice_flag is not present, the value of sh_ts_residual_coding_rice_flag is inferred to be equal to 0. sh_ts_residual_coding_rice_index specifies the Rice parameter used in the residual_ts_coding() syntax construct. [Table 36]
[0239] In another example, a control flag is signaled in the sequence parameter set (or sequence parameter set range extension syntax) indicating whether to enable or disable signaling of the Rice parameter for the transform skip block. When the control flag is signaled as enabled, a syntax element is further signaled for each transform skip slice to indicate the Rice parameter for that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no syntax element is further signaled to indicate the Rice parameter for the transform skip slice, and a default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold and italic font in Table 37, and the deleted content is indicated by a deletion line. Of note, sh_ts_residual_coding_rice_idx can be coded differently and / or have a maximum value. For example, u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string using n bits written left to right) may be used to encode / decode the same syntax element.
[0240] Sequence Parameter Set RBSP Syntax [Table 37]
[0241] sps_ts_residual_coding_rice_present_in_sh_flag=1 specifies that sh_ts_residual_coding_rice_idx may be present in the SH syntax structure of the referenced SPS. sps_ts_residual_coding_rice_present_in_sh_flag=0 specifies that sh_ts_residual_coding_rice_idx is not present in the SH syntax structure of the referenced SPS. If sps_ts_residual_coding_rice_present_in_sh_flag is not present, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be equal to 0.
[0242] Slice Header Syntax [Table 38]
[0243] sh_ts_residual_coding_rice_idx specifies the Rice parameter used in the residual_ts_coding() syntax structure. [Table 39]
[0244] In another example, for each transform skip slice, a syntax element is signaled indicating the Rice parameter for that slice. An example of the corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold and italic font in Table 40. Of note, sh_ts_residual_coding_rice_idx can be coded in different ways and / or have a maximum value. For example, u(n) (unsigned integer using n bits) or f(n) (fixed pattern bit string using n bits written from the left (left to right)) may be used to code / decode the same syntax element.
[0245] Slice Header Syntax [Table 40]
[0246] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx is not present, the value of sh_ts_residual_coding_rice_idx is inferred to be equal to 0. [Table 41]
[0247] In another example, a control flag is signaled in the picture parameter set range extension syntax to indicate whether to enable or disable the signaling of Rice parameters for transform skip blocks. When the control flag is signaled as enabled, a syntax element is further signaled to indicate the Rice parameters for the picture. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no syntax element is further signaled to indicate the Rice parameters for transform skip slices, and a default Rice parameter (e.g., 1) is used for all transform skip slices. An example of a corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold and italic font in Table 42. Of note, pps_ts_residual_coding_rice_idx can be coded differently and / or have a maximum value. For example, u(n) (an unsigned integer using n bits) or f(n) (a fixed-pattern bit string using n bits written left to right) may be used to encode / decode the same syntax element.
[0248] Image Parameter Set Range Extension Syntax [Table 42]
[0249] pps_ts_residual_coding_rice_flag=1 specifies that pps_ts_residual_coding_rice_index may be present in the current picture. pps_ts_residual_coding_rice_flag=0 specifies that pps_ts_residual_coding_rice_idx is not present in the current picture. If pps_ts_residual_coding_rice_flag is not present, the value of pps_ts_residual_coding_rice_flag is inferred to be equal to 0.
[0250] pps_ts_residual_coding_rice_idx specifies the Rice parameter used in the residual_ts_coding() syntax structure. [Table 43]
[0251] In another example, it is proposed to code the syntax element abs_remainder with only variable Rice parameters. The value of the Rice parameter applied is determined based on the specific coding information of the current block (e.g., block size, quantization parameter, bit depth, transform type, etc.). In a specific embodiment, it is proposed to adjust the Rice parameter based on the coding bit depth and the quantization parameter applied to the CU. The corresponding decoding process based on the VVC draft is shown below, and the changes to the VVC draft are shown in bold and italic font in Table 44, and the deleted contents are shown in italic font. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameter can also be derived using some equations or lookup tables. [Table 44] JPEG0007670851000055.jpg254165JPEG0007670851000056.jpg74167
[0252] In yet another example, the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 33 or 34). The changes to the VVC draft are shown in bold and italic font in Table 45, and the deleted content is shown in italic font. It is noteworthy that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters. [Table 45]
[0253] In another example, the corresponding decoding process based on the VVC draft is shown below: A and T.H. B is a predetermined threshold (e.g., TH A =8,TH B = 33 or 34). Changes to the VVC draft are shown in bold and italic font in Table 46, and deleted content is shown in italic font. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using several equations or lookup tables. [Table 46]
[0254] In another example, it is proposed to encode the syntax element of abs_remainder with a variable Rice parameter only when a new flag (e.g., extended_precision_processing_flag) is equal to 1. The variable value is determined based on the specific coding information of the current block (e.g., block size, quantization parameter, bit depth, transform type, etc.). In a specific embodiment, it is proposed to adjust the Rice parameter based on the coding bit depth and the quantization parameter applied to the 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 in practice the same logic can be implemented differently. For example, the same Rice parameter can also be derived using some equations or lookup tables. [Table 47] JPEG0007670851000060.jpg239167
[0255] 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). The changes to the VVC draft are shown in bold and italics in Table 48. It is worth noting that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters. [Table 48]
[0256] In another example, the corresponding decoding process based on the VVC draft is shown below, where THA and THB are predefined thresholds (e.g., THA=8, THB=18 or 19). The changes to the VVC draft are shown in bold and italics in Table 49. It is worth noting that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters. [Table 49]
[0257] FIG. 16 illustrates a method for video encoding. The method may be applied to an encoder, for example. In step 1610, the encoder may receive a video input. For example, the video input may be a live stream. In step 1612, the encoder may obtain a quantization parameter based on the video input. For example, the quantization parameter may be calculated by a quantization unit in the encoder. In step 1614, the encoder may derive a Rice parameter based on at least one predetermined threshold, a coding bit depth, and the quantization parameter. For example, the Rice parameter is used to signal the syntax of abs_remainder and dec_abs_level. In step 1616, the encoder may entropy code a video bitstream based on the Rice parameter. For example, the video bitstream may be entropy coded to generate a compressed video bitstream.
[0258] In another example, it is proposed that when BitDepth is greater than 10, only fixed values (e.g., 2, 3, 4, 5, 6, 7, or 8) for the Rice parameter are used when encoding the syntax element of abs_remainder. The fixed values can be different in different conditions based on the specific encoding information (e.g., quantization parameters) of the current block. The corresponding decoding process based on the VVC draft is shown below, where TH is a predefined threshold (e.g., 18, 19). The changes to the VVC draft are shown in bold and italics in Table 50. It is worth noting that in practice the same logic can be implemented differently. For example, the same Rice parameter can be derived using some equations or lookup tables. [Table 50]
[0259] In another example, the corresponding decoding process based on the VVC draft is shown below, where THA and THB are predefined thresholds (e.g., THA=8, THB=18 or 19). The changes to the VVC draft are shown in bold and italics in Table 51. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using some equations or lookup tables. [Table 51]
[0260] In another example, the corresponding decoding process based on the VVC draft is shown below, showing that TH is a predefined threshold (e.g., 33 or 34). The changes to the VVC draft are shown in bold and italics in Table 52. It is noteworthy that in practice the same logic can be implemented differently. For example, some equations or lookup tables can be used to derive the same Rice parameters. [Table 52]
[0261] In another example, the corresponding decoding process based on the VVC draft is shown below, where THA and THB are predefined thresholds (e.g., THA=8, THB=33 or 34). The changes to the VVC draft are shown in bold and italics in Table 53. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using some equations or lookup tables. [Table 53]
[0262] It should be noted that in the above description, the equation for calculating a specific Rice parameter is used only as an example to explain the proposed idea. For those skilled in the art of video coding technology today, other mapping functions (or equivalent mapping equations) have been applied to the proposed idea (i.e., determining the Rice parameter of the transform skip mode based on the coding bits and the applied quantization parameter). It should also be mentioned that in the current VVC design, the value of the applied quantization parameter can be changed at the group level of the coding block. Therefore, the proposed Rice parameter adjustment scheme can provide flexible adaptation of the Rice parameter of the transform skip mode at the group level of the coding block.
[0263] Signaling information for normal residual coding / decoding and transform skip residual coding / decoding
[0264] According to a 28th aspect of the present disclosure, it is proposed to signal the Rice parameter of a binary codeword for coding a specific syntax element (e.g., abs_remainder) in transform skip residual coding / decoding, the shift and offset parameters for deriving the Rice parameter for abs_remainder / dec_abs_level in normal residual coding / decoding, and to decide whether to signal based on specific coding information of the current block (e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile) and / or a new flag associated with TB / CB / slice / image / sequence level (e.g., sps_residual_coding_info_present_in_sh_flag).
[0265] In one example, a control flag is signaled in the slice header indicating whether to enable or disable the signaling of Rice parameters for the transform skip block and the signaling of shift and / or offset parameters for deriving the Rice parameters in the transform block. When the control flag is signaled as enabled, for each transform skip slice, a syntax element is further signaled for indicating the Rice parameters for that slice, and for each transform slice, two syntax elements are further signaled for indicating the shift and / or offset parameters for deriving the Rice parameters for that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no syntax element is further signaled for indicating the Rice parameters for the transform skip slice, and default Rice parameters (e.g., 1) are used for all transform skip slices, and further, at the lower level, no syntax element is signaled for indicating the shift and offset parameters for deriving the Rice parameters for the transform slice, and default shift and / or offset parameters (e.g., 0) are used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold and italic font in Table 54. Of note, sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_ts_residual_coding_rice_index can be coded in different ways and / or have maximum values. For example, u(n) (unsigned integer using n bits) or f(n) (fixed pattern bit string using n bits written from the left bit (left to right)) may be used to code / decode the same syntax element.
[0266] Figure 17 shows the video signThe present invention shows a method for entropy coding of a video bitstream based on the Rice parameter and the video input. The method can be applied to an encoder, for example. In step 1710, the encoder can receive a video input. In step 1712, the encoder can signal a Rice parameter of a binary codeword for syntax element encoding. The syntax element encoding can include abs_remainder in transform skip residual encoding decoding. In step 1714, the encoder can entropy code a video bitstream based on the Rice parameter and the video input.
[0267] Slice Header Syntax [Table 54]
[0268] sh_residual_coding_rice_flag=1 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_residual_coding_rice_index can be present in the current slice. sh_residual_coding_rice_flag=0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_residual_coding_rice_index are not present in the current slice.
[0269] sh_residual_coding_rice_shift specifies the shift parameter used in the Rice parameter derivation process for abs_remainder[] and dec_abs_level[]. If sh_residual_coding_rice_shift is not present, the value of sh_residual_coding_rice_shift is inferred to be equal to 0.
[0270] sh_residual_coding_rice_offset specifies the offset parameter used in the Rice parameter derivation process for abs_remainder[] and dec_abs_level[]. If sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be equal to 0.
[0271] sh_ts_residual_coding_rice_index specifies the rice parameter used in the residual_ts_coding() syntax construct. If sh_ts_residual_coding_rice_index is not present, the value of sh_ts_residual_coding_rice_index is inferred to be equal to 0. [Table 55] [Table 56]
[0272] In another example, a control flag is signaled in a sequence parameter set (or sequence parameter set range extension syntax) indicating whether to enable or disable the signaling of Rice parameters for transform skip blocks and the signaling of shift and / or offset parameters for deriving the Rice parameters in the transform blocks. When the control flag is signaled as enabled, for each transform skip slice, a syntax element is further signaled for indicating the Rice parameters for that slice, and for each transform slice, two syntax elements are further signaled for indicating the shift and / or offset parameters for deriving the Rice parameters for that slice. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no syntax element is further signaled for indicating the Rice parameters for the transform skip slice, and default Rice parameters (e.g., 1) are used for all transform skip slices, and further, at the lower level, no syntax element is signaled for indicating the shift and offset parameters for deriving the Rice parameters for the transform slices, and default shift and / or offset parameters (e.g., 0) are used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold and italic font in Table 57. Of note, sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_ts_residual_coding_rice_idx can be coded in different ways and / or have maximum values. For example, u(n) (unsigned integer using n bits) or f(n) (fixed pattern bit string using n bits written from left to right) may be used to code / decode the same syntax element.
[0273] Sequence Parameter Set RBSP Syntax [Table 57]
[0274] sps_residual_coding_info_present_in_sh_flag=1 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_ts_residual_coding_rice_idx may be present in the SH syntax structure of the referenced SPS. sps_residual_coding_info_present_in_sh_flag=0 specifies that sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_ts_residual_coding_rice_idx are not present in the SH syntax structure of the referenced SPS. If sps_residual_coding_info_present_in_sh_flag is not present, the value of sps_residual_coding_info_present_in_sh_flag is inferred to be equal to 0.
[0275] Slice Header Syntax [Table 58]
[0276] sh_residual_coding_rice_shift specifies the shift parameter used in the Rice parameter derivation process for abs_remainer[] and dec_abs_level[]. If sh_residual_coding_rice_shift is not present, the value of sh_residual_coding_rice_shift is inferred to be equal to 0.
[0277] sh_residual_coding_rice_offset specifies the offset parameter used in the Rice parameter derivation process for abs_remainer[] and dec_abs_level[]. If sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be equal to 0.
[0278] 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_rice_index is inferred to be equal to 0. [Table 59] [Table 60]
[0279] In another example, for each transform skip slice, a syntax element is signaled to indicate the Rice parameter for that slice, and for each transform slice, two syntax elements are further signaled to indicate the shift and / or offset parameters for deriving the Rice parameter for that slice. An example of the corresponding decoding process based on the VVC draft is shown below. The changes to the VVC draft are shown in bold and italics in Table 61. Of note, sh_residual_coding_rice_shift, sh_residual_coding_rice_offset and sh_ts_residual_coding_rice_idx can be coded in different ways and / or have maximum values. For example, u(n) (unsigned integer using n bits) or f(n) (fixed pattern bit string using n bits written from the left bit (left to right)) may be used to code / decode the same syntax element.
[0280] Slice Header Syntax [Table 61]
[0281] sh_ts_residual_coding_rice_idx specifies the rice parameter used in the residual_ts_coding() syntax structure. If sh_ts_residual_coding_rice_idx is not present, the value of sh_ts_residual_coding_rice_idx is inferred to be equal to 0.
[0282] sh_residual_coding_rice_offset specifies the offset parameter used in the Rice parameter derivation process for abs_remainer[] and dec_abs_level[]. If sh_residual_coding_rice_offset is not present, the value of sh_residual_coding_rice_offset is inferred to be equal to 0.
[0283] 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_rice_index is inferred to be equal to 0. [Table 62] [Table 63]
[0284] In another example, a control flag is signaled in the picture parameter set range extension syntax to indicate whether to enable or disable the signaling of Rice parameters for transform skip blocks and the signaling of shift and / or offset parameters for deriving the Rice parameters in the transform blocks. When the control flag is signaled as enabled, a syntax element is further signaled to indicate the Rice parameters for the transform skip residual coding / decoding of the picture, and two syntax elements are further signaled to indicate the shift and / or offset parameters for deriving the Rice parameters for the normal residual coding / decoding of the picture. When the control flag is signaled as disabled (e.g., set equal to "0"), at the lower level, no further syntax element is signaled to indicate the Rice parameters for the transform skip residual coding / decoding, and default Rice parameters (e.g., 1) are used for all transform skip residual coding / decoding, and further, at the lower level, no syntax element is signaled to indicate the shift and offset parameters for deriving the Rice parameters for the normal residual coding / decoding, and default shift and / or offset parameters (e.g., 0) are used for all normal residual coding / decoding. An example of the corresponding decoding process based on the VVC draft is shown below, where TH is a predefined value (e.g., 0, 1, 2). The changes to the VVC draft are shown in bold and italic font in Table 64. Of note, pps_residual_coding_rice_shift, pps_residual_coding_rice_offset and pps_ts_residual_coding_rice_idx can be coded in different ways and / or have maximum values. For example, u(n) (unsigned integer using n bits) or f(n) (fixed pattern bit string using n bits written from the left bit (left to right)) may be used to code / decode the same syntax element.
[0285] Image Parameter Set Range Extension Syntax [Table 64]
[0286] pps_residual_coding_info_flag=1 specifies that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset and pps_ts_residual_coding_rice_index may be present in the current picture. pps_residual_coding_info_flag=0 specifies that pps_residual_coding_rice_shift, pps_residual_coding_rice_offset and pps_ts_residual_coding_rice_idx are not present in the current picture. If pps_residual_coding_info_flag is not present, the value of pps_residual_coding_info_flag is inferred to be equal to 0.
[0287] pps_residual_coding_rice_shift specifies the shift parameter used in the Rice parameter derivation process for abs_remainer[] and dec_abs_level[]. If pps_residual_coding_rice_shift is not present, the value of pps_residual_coding_rice_shift is inferred to be equal to 0.
[0288] pps_residual_coding_rice_offset specifies the offset parameter used in the Rice parameter derivation process for abs_remainer[] and dec_abs_level[]. If pps_residual_coding_rice_offset is not present, the value of pps_residual_coding_rice_offset is inferred to be equal to 0.
[0289] 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, the value of pps_ts_residual_coding_rice_index is inferred to be equal to 0. [Table 65] [Table 66]
[0290] According to a twenty-ninth aspect of the present disclosure, it is proposed to code a specific syntax element (e.g., abs_remainder) in transform skip residual coding / decoding, and shift and offset parameters for deriving the Rice parameters used for abs_remainder / dec_abs_level in normal residual coding / decoding with different Rice parameters, and to determine which syntax element to use based on specific coding information of the current block (e.g., quantization parameters or coding bit depth associated with TB / CB and / or slice / profile) and / or a new flag (e.g., sps_residual_coding_info_present_in_shflag) associated with the TB / CB / slice / image / sequence level.
[0291] In one example, a control flag is signaled in a slice header to indicate whether to enable or disable the derivation process of the Rice parameter for the transform skip block and the derivation process of the shift and / or offset parameters for the Rice parameter in the transform block. When the control flag is signaled as enabled, the Rice parameter can be different in different conditions depending on the specific coding information (e.g., quantization parameter and bit depth) of the current block. Also, the shift and / or offset parameters for deriving the Rice parameter in normal residual coding decoding can be different in different conditions depending on the specific coding information (e.g., quantization parameter and bit depth) of the current block. When the control flag is signaled as disabled (e.g., set equal to "0"), the default Rice parameter (e.g., 1) is used for all transform skip slices, and the default shift and / or offset parameters (e.g., 0) are used for all transform slices. An example of the corresponding decoding process based on the VVC draft is shown below. Here, TH A and T.H. B is a predetermined 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 noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using several equations or lookup tables.
[0292] Slice Header Syntax [Table 67]
[0293] sh_residual_coding_rice_flag=1 specifies that the bit-depth dependent Rice parameter derivation process is used for the current slice. sh_residual_coding_rice_flag=0 specifies that the bit-depth related Rice parameter derivation process is not used for the current slice. [Table 68] [Table 69]
[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). The changes to the VVC draft are shown in bold and italics in Table 70. It is noteworthy that in practice the same logic can be implemented differently. For example, the same Rice parameters can be derived using some equations or lookup tables. [Table 70]
[0295] According to another aspect of the present disclosure, it is proposed to provide a general constraint control that is the same as other general constraint controls in the general constraint information by adding constraints on the values of these encoding tool flags mentioned above.
[0296] For example, sps_ts_residual_coding_rice_present_in_sh_flag=1 specifies that sh_ts_residual_coding_rice_idx can be present in the SH syntax structure of the reference SPS. sps_ts_residual_coding_rice_present_in_sh_flag=0 specifies that sh_ts_residual_coding_rice_idx is not present in the SH syntax structure of the reference SPS. According to the present disclosure, it is proposed to provide the same general constraint control as other flags by adding the syntax element gci_no_ts_residual_coding_rice_constraint_flag to the general constraint information syntax. Below is an example of the decoding process of the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000084.jpg62167
[0297] In another example, pps_ts_residual_coding_rice_flag=1 specifies that pps_ts_residual_coding_rice_index can be present in the current image. pps_ts_residual_coding_rice_flag=0 specifies that pps_ts_residual_coding_rice_idx is not present in the current image. According to the present disclosure, it is proposed to provide the same general constraint control as other flags by adding the syntax element gci_no_ts_residual_coding_rice_constraint_flag to the general constraint information syntax. Below is an example of the decoding process of the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000085.jpg63167
[0298] In another example, sps_rice_adaptation_enabled_flag = 1 specifies that the Rice parameters for the binarization of abs_remainder[] and dec_abs_level can be derived by an equation.
[0299] This equation includes RiceParam = RiceParam + ShiftVal, where ShiftVal = (localSumAbs < Tx[0])? Rx[0] : ((localSumAbs < Tx[1])? Rx[1] : ((localSumAbs < Tx[2])? Rx[2] : ((localSumAbs < Tx[3])? Rx[3] : Rx[4]))). Here, the lists Tx[] and Rx[] are specified as follows. Tx[] = {321285122048}>>(1523), Rx[] = {0, 2, 4, 6, 8}.
[0300] According to the present disclosure, it is proposed to provide the same general constraint control as other flags by adding a syntax element gci_no_rice_adaptation_constraint_flag to the general constraint information syntax. An example of the decoding process of the VVC draft is shown below. Changes to the VVC draft are highlighted. The added parts are highlighted in italic font. JPEG0007670851000086.jpg55167
[0301] Since the proposed Rice parameter adaptation scheme is only used for transform skip residual coding and decoding (TSRC), the proposed method is only effective when TSRC is enabled. Therefore, in one or more embodiments of the present disclosure, when the transform skip mode is disabled based on the general constraint information level (for example, when the value of gci_no_transform_skip_constraint_flag is set to 1), a bitstream constraint is added that requires the value of gci_no_rice_adaptation_constraint_flag to be 1.
[0302] In another example, sps_range_extension_flag=1 specifies that the sps_range_extension() syntax structure is present in the SPS RBSP syntax structure. sps_range_extension_flag=0 specifies that this syntax structure is not present. According to the present disclosure, it is proposed to provide the same general constraint control as the other flags by adding the syntax element gci_no_range_extension_constraint_flag to the general constraint information syntax. Below is an example of the decoding process of the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000087.jpg58167
[0303] FIG. 19 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to (for example) a decoder. In step 1902, the decoder may receive a sequence parameter set (SPS) range extension flag. The SPS range extension flag indicates whether a syntax structure sps_range_extension is present in a syntax structure of a slice header (SH) raw byte sequence payload (RBSP) based on a value of the SPS range extension flag.
[0304] In step 1904, the decoder may determine that sps_range_extension is present in the SH RBSP syntax structure in response to determining that the value of the SPS range extension flag is equal to one.
[0305] In step 1906, in response to determining that the value of the SPS range extension flag is equal to 0, the decoder may determine that sps_range_extension is not present in the SH RBSP syntax structure.
[0306] In another example, sps_cabac_bypass_alignment_enabled_flag=1 specifies that the value of ivlCurrRange is aligned before bypass decoding for syntax elements sb_coded_flag[][], abs_remaind[], dec_abs_level[n], and coeff_sign_flag[]. sps_cabac_bypass_alignment_enabled_flag=0 specifies that the value of ivlCurrRange is not aligned before bypass encoding. According to the present disclosure, it is proposed to provide the same general constraint control as other flags by adding syntax element gci_no_cabac_bypass_alignment_constraint_flag to the general constraint information syntax. Below is an example of the decoding process in the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000088.jpg61165
[0307] FIG. 20 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to a decoder (for example). In step 2002, the decoder may receive a sequence parameter set (SPS) alignment enable flag. The SPS alignment enable flag indicates whether the index ivlCurrRange is aligned before bypass decoding of syntax elements sb_coded_flag, abs_remainder, dec_abs_level, and coeff_sign_flagn based on the value of the SPS alignment enable flag.
[0308] In step 2004, in response to determining that the value of the SPS alignment enable flag is equal to one, the decoder may determine to align the ivlCurrRange before bypass decoding.
[0309] In step 2006, in response to determining that the value of the SPS alignment enable flag is equal to 0, the decoder may determine not to align the ivlCurrRange before bypass decoding.
[0310] In another example, extended_precision_processing_flag=1 specifies that extended dynamic range can be used for transform coefficients and transform processing. extended_precision_processing_flag=0 specifies that extended dynamic range is not used. According to the present disclosure, it is proposed to provide the same general constraint control as other flags by adding syntax element gci_no_extended_precision_processing_constraint_flag to the general constraint information syntax. Below is an example of the decoding process in the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000089.jpg66165
[0311] 21 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to (for example) a decoder. In step 2102, the decoder may receive an extended precision processing flag. The extended precision processing flag indicates whether an extended dynamic range is used during a transform process for transform coefficients based on a value of the extended precision processing flag.
[0312] In step 2104, in response to determining that the value of the extended precision processing flag is equal to one, the decoder may determine that an extended dynamic range is to be used during transform processing for the transform coefficients.
[0313] In response to determining in step 2106 that the value of the extended precision processing flag is 0, the decoder may determine that extended dynamic range is not used for the transform coefficients or during the transform process.
[0314] In another example, persistent_rice_adaptation_enabled_flag=1 specifies that the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level is initialized at the beginning of each sub-block with mode-related statistics accumulated from the previous sub-block. persistent_rice_adaptation_enabled_flag=0 specifies that the previous sub-block state is not used for the Rice parameter derivation. According to this disclosure, the addition of syntax element gci_no_persistent_rice_adaptation_constraint_flag to the general constraint information syntax is used to provide the same general constraint control as the other flags. Below is an example of the decoding process in the VVC draft. The changes to the VVC draft are highlighted. The additions are highlighted in italic font. JPEG0007670851000090.jpg74165
[0315] FIG. 22 illustrates a method for video encoding according to an example of the present disclosure. The method may be applied to (for example) a decoder. In step 2202, the decoder may receive a persistent Rice adaptation enable flag. The persistent Rice adaptation enable flag indicates whether the Rice parameter derivation for binarization of abs_remainder and dec_abs_level is initialized at the beginning of each sub-block using mode-related statistics accumulated from previous sub-blocks, based on the value of the persistent Rice adaptation enable flag.
[0316] In step 2204, in response to determining that the value of the persistent Rice adaptation enable flag is equal to 1, the decoder may determine to initialize the Rice parameter derivation for binarization at the start of each sub-block with mode-related statistics accumulated from the previous sub-block.
[0317] In step 2206, in response to determining that the value of the persistent Rice adaptation enable flag is 0, the decoder may determine that the previous sub-block state is not employed in the Rice parameter derivation.
[0318] The above-described methods may be realized using an apparatus including one or more circuits, including an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processor (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a controller, a microcontroller, a microprocessor, or other electronic components. The apparatus may perform the above-described methods using circuits in combination with other hardware or software components. Each module, sub-module, unit, or sub-unit disclosed above may be implemented, at least in part, using one or more circuits.
[0319] Rice parameter determination
[0320] On the encoder side, TSRC encoding may require multiple encoding passes to derive optimal Rice parameters. Such multi-pass encoding may not be suitable for practical hardware encoder design. To solve this problem, a low-delay TSRC encoding method is also proposed. According to the 30th aspect of the present disclosure, it is proposed to derive the Rice parameters based on the specific encoding information of the current slice (e.g., the quantization parameters and / or the coding bit depth associated with the slice / image / sequence) and / or the hash rate associated with the slice / image / sequence level. Different methods can be used to derive the Rice parameters, and some exemplary methods are as follows. It should be noted that the following methods can be applied independently or in conjunction.
[0321] 1. The Rice parameters mentioned in the above examples may further depend on the video resolution, including both the temporal resolution (eg, frame rate) and spatial resolution (eg, image width and height) of the video.
[0322] 2. The Rice parameter can vary at the sequence level, picture level, slice level and / or any predefined region. In one particular example, different Rice values are used for images with different temporal layer IDs (related to nuh_temporal_id_plus1 specified in the VVC specification). Optionally, the Rice parameter can include a value determined based on the QP value used at the sequence level, picture level, slice level and / or any predefined region. For example, Rice parameter=Clip3(1,8,(TH-QP) / 6), where TH is a predefined threshold (e.g., 18,19).
[0323] 3. Based on the change in the coding information between the current slice and the previous slice, the Rice parameter can be set to a default value, e.g., 1. In one particular example, if the temporal layer ID of an image has changed compared to the previous image, the default Rice value is used for that image. Optionally, if ΔQ is greater than TH, the default Rice value is used for this image, where ΔQ is calculated as abs(QPcurrent-QPprevious), and TH is a predefined threshold Rice parameter (e.g., 0.5). For example, From intra-block copy mode hash Rate If it is greater than TH, then the Rice parameter = 1, where TH is a predefined threshold, for example Max(41 x (number of CTUs), 4200).
[0324] 4. For each slice, the abs_remainder value is calculated based on the value of the abs_remainder coded in the previous slice in the coding order. I Rice parameters for each slice DetermineIn one particular example, after encoding one slice, the number of binary digits for binarizing abs_remainder using different Rice parameters is calculated. The number of binary digits is used to determine the Rice parameters of the subsequent slices. For example, for the current slice, the Rice parameter that achieves the minimum number of binary digits in the previous slice is selected. In another example, if the same QP is used in the current slice and the previous slice, the Rice parameter that achieves the minimum number of binary digits in the previous slice is selected for the current slice. Otherwise, before comparing with other Rice parameters, the number of binary digits generated using the default Rice parameter (i.e., 1) in the previous slice is scaled by TH, and the Rice parameter that results in the minimum number of binary digits is selected for the current slice, where TH is a predetermined threshold, e.g., 0.9.
[0325] 5 .sign The abs_remainder of each slice is coded in the previous slice according to the coding order. And, Rice parameters for each slice and based on the change in coding information between the current slice and the previous slice, The Rice parameter can be adjusted. In one particular example, for the current slice, the Rice parameter that achieves the minimum number of binary digits in the previous slice is selected. Then, if ΔQ is greater than TH, the Rice value can be adjusted, where ΔQ is calculated as abs(QPcurrent-QPprevious), where TH is a predefined threshold. The Rice parameter (e.g., 0.5). The adjustment can be done by adding a predefined offset (e.g., +1, -1) or scaling by a predefined value.
[0326] FIG. 26 illustrates a flowchart of a low-delay transform skip residual coding and decoding (TSRC) method according to an example of the present disclosure. The method can be applied to an encoder, for example. In step 2602, the encoder can derive a Rice parameter based on coding information of a current slice of a video. The coding information can include: In step 2604the quantization parameter or coding bit depth associated with a slice, image or sequence of video, or In step 2606 It includes one or more parameters of a hash rate associated with a slice, image or sequence of video.
[0327] It is noted that the encoder method described above can be applied to the decoder side. In one particular example, there is no need to signal the Rice parameters to the decoder, and the Rice parameters are derived in the same way in the encoder / decoder.
[0328] 18 illustrates a computing environment 1810 coupled to a user interface 1860. The computing environment 1810 may be part of a data processing server. The computing environment 1810 includes a processor 1820, a memory 1840, and an I / O interface 1850.
[0329] The processor 1820 generally controls the overall operation of the computing environment 1810, such as operations related to display, data collection, data communication, and image processing. The processor 1820 may include one or more processors that execute instructions to perform all or some steps of the methods described above. Additionally, the processor 1820 may include one or more modules that facilitate interaction between the processor 1820 and other components. The processor may be a central processing unit (CPU), a microprocessor, a single chip, a GPU, etc.
[0330] The memory 1840 is configured to store various types of data to support the operation of the computing environment 1810. The memory 1840 may include predefined software 1842. Examples of such data include instructions for any application or method for operating on the computing environment 1810, video data sets, image data, etc. The memory 1840 may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.
[0331] The I / O interface 1850 provides an interface between the processor 1820 and a peripheral interface module (such as a keyboard, a click wheel, buttons, etc.). The buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. The I / O interface 1850 may be coupled to an encoder and a decoder.
[0332] In some embodiments, a non-transitory computer readable storage medium is also provided that includes a number of programs stored in memory 1840 and executable by processor 1820 in computer environment 1810 to perform the methods described above. For example, the non-transitory computer readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.
[0333] A non-transitory computer-readable storage medium has stored thereon a number of programs that, when executed by a computing device having one or more processors, cause the computing device to perform the method for motion prediction described above.
[0334] In some embodiments, the computing environment 1810 may be implemented by 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 to perform the methods described above.
[0335] FIG. 23 is a block diagram illustrating an example system 10 for encoding and decoding video blocks in parallel in accordance with some embodiments of the present disclosure. As shown in FIG. 23, the system 10 includes a source device 12. The source device 12 generates and encodes video data that is subsequently decoded by a target device 14. The source device 12 and the target device 14 may include 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 stream transmission devices, and the like. In some embodiments, the source device 12 and the target device 14 are equipped with wireless communication capabilities.
[0336] In some embodiments, the target device 14 may receive the encoded video data to be decoded via a link 16. The link 16 may include any type of communication medium or device capable of moving the encoded video data from the source device 12 to the target device 14. In one example, the link 16 may include a communication medium that allows the source device 12 to transmit the encoded video data directly to the target device 14 in real time. The encoded video data is modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the target device 14. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission paths. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include a router, a switch, a base station, or any other device capable of facilitating communication from the source device 12 to the target device 14.
[0337] In some other embodiments, the encoded video data is transmitted from output interface 22 to storage device 32. The encoded video data in storage device 32 can then be accessed by target device 14 via input interface 28. Storage device 32 can include any of a variety of distributed or locally accessed data storage media, such as a hard disk drive, a Blu-ray disk, a digital versatile optical disk (DVD), a read-only optical disk memory (CD-ROM), a flash memory, a volatile or non-volatile memory, or other suitable digital storage media for storing encoded video data. In a further example, storage device 32 may correspond to a file server or another intermediate storage device that may hold the encoded video data generated by source device 12. Target device 14 can access the stored video data via streaming or download from storage device 32. The file server may be any type of computer capable of storing encoded video data and transmitting the encoded video data to target device 14. Exemplary file servers include a web server (e.g., for a website), a file transfer protocol (FTP) server, a network attached storage (NAS) device, or a local disk drive. The target device 14 can access the encoded video data via any standard data connection suitable for accessing encoded video data stored on a file server. Standard data connections include wireless paths (e.g., wireless fidelity (WI-FI) connections), wired connections (e.g., digital user line (DSL), cable modems, etc.), or a combination of both. The transmission of the encoded video data from the storage device 32 can be a stream transmission, a download transmission, or a combination of both.
[0338] As shown in FIG. 23, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources or combinations of such sources, such as a video capture device (e.g., a video camera), a video archive containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as the source video. As an example, if video source 18 is a camera of a security surveillance system, source device 12 and target device 14 may form a camera phone or a video phone. However, the embodiments described herein may be generally applicable to video encoding and may be applied to wireless and / or wired applications.
[0339] The captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video data may be transmitted directly to target device 14 via output interface 22 of source device 12. The encoded video data may (or is optional) be stored in storage device 32 for later access by target device 14 or other devices for decoding and / or playback. Output interface 22 may further include a modem and / or a transmitter.
[0340] Target device 14 includes an input interface 28, a video decoder 30, and a display device 34. Input interface 28 may include a receiver and / or modem and may receive encoded video data over link 16. The encoded video data communicated over link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use in decoding the video data by video decoder 30. Such syntax elements may be included within the encoded video data transmitted over a communication medium, stored on a storage medium, or stored on a file server.
[0341] In some embodiments, target device 14 may include a display device 34. Display device 34 may be an integrated display device as well as an external display device configured to communicate with target device 14. Display device 34 displays decoded video data to a user and may include any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.
[0342] Video encoder 20 and video decoder 30 may operate according to proprietary or industry standards, such as VVC, HEVC, MPEG-4, Part 10, AVC, and extensions of such standards. It should be understood that the present application is not limited to a particular video encoding / decoding standard, but may apply to other video encoding / decoding standards. It is generally believed that video encoder 20 of source device 12 may be configured to encode video data based on any of these current or future standards. Similarly, it is generally believed that video decoder 30 of target device 14 may be configured to decode video data based on any of these current or future standards.
[0343] The video encoder 20 and the video decoder 30 may each be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. If implemented partially in software, the electronic device may store instructions for the software on a suitable non-transitory computer-readable medium and execute the instructions in the hardware using one or more processors to perform the video encoding / decoding operations disclosed in this disclosure. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, and either the encoder or decoder may be integrated as part of a combined encoder / decoder (CODEC) in the respective device.
[0344] FIG. 24 is a block diagram illustrating an example video encoder 20 according to some embodiments described herein. The video encoder 20 may perform intra-predictive and inter-predictive coding of video blocks within a video frame. Intra-predictive coding relies on spatial prediction to reduce or remove spatial redundancy in video data within a given video frame or image. Inter-predictive coding relies on temporal prediction to reduce or remove temporal redundancy in video data within adjacent video frames or images of a video sequence. It is noted that the term "frame" may be used as a synonym for the terms "image" or "picture" in the video coding arts.
[0345] As shown in FIG. 24, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a partition unit 45, an intra prediction processing unit 46, and an intra block copy (BC) unit 48. In some embodiments, the video encoder 20 further includes an inverse quantization unit 58 for video block reconstruction, an inverse transform processing unit 60, and an adder 62. An in-loop filter 63, such as a deblocking filter, can be disposed between the adder 62 and the DPB 64 to filter block boundaries to remove block effects from the reconstructed video. In addition to the deblocking filter, the output of the adder 62 can be filtered with another in-loop filter (e.g., a sample adaptive offset (SAO) filter and / or an adaptive in-loop filter (ALF)). In some examples, the in-loop filter may be omitted and the decoded video blocks may be provided directly to DPB 64 by summer 62. Video encoder 20 may take the form of a fixed or programmable hardware unit, or may be distributed across one or more of the described fixed or programmable hardware units.
[0346] The video data memory 40 may store video data to be encoded by the components of the video encoder 20. The video data in the video data memory 40 may be obtained from a video source 18, for example, as shown in FIG. 23. The DPB 64 is a buffer that stores reference video data (e.g., reference frames or reference images) for use by the video encoder 20 in encoding the video data (e.g., in an intra-predictive coding mode or an inter-predictive coding mode). The video data memory 40 and the DPB 64 may be formed by any of a variety of memory 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.
[0347] As shown in FIG. 24, upon receiving the video data, the partition unit 45 in the prediction processing unit 41 divides the video data into video blocks. This division may also include dividing the video frame into slices, tiles (e.g., video block sets), or other larger coding units (CUs) based on a predetermined division structure associated with the video data, such as a quadtree (QT) structure. A video frame is or may be considered as a two-dimensional array or matrix of samples having sample values. The samples in the array are also called pixels or Pels. The number of samples in the horizontal and vertical directions (or axes) of the array or image defines the size and / or resolution of the video frame. A video frame may be divided into multiple video blocks, for example, using QT division. Although the size of a video block is smaller than that of a video frame, a video block is similarly or may be considered as a two-dimensional array or matrix of samples having sample values. The number of samples in the horizontal and vertical directions (or axes) of a video block defines the size of the video block. A video block may be further divided into one or more block partitions or sub-blocks, which may reshape the block using, for example, a QT partition, a binary tree (BT) partition, or a ternary tree (TT) partition, or any combination thereof, iteratively. Note that, as used herein, the term "block" or "video block" refers to a portion of a frame or image, particularly a rectangular (square or non-square) portion. For example, with reference to HEVC and VVC, a block or video block may be or correspond to a coding tree unit (CTU), a CU, a prediction unit (PU), or a transform unit (TU), and / or a corresponding block, such as a coding tree block (CTB), a coding block (CB), a prediction block (PB), or a transform block (TB), and / or a sub-block.
[0348] Prediction processing unit 41 may select one of a plurality of possible predictive coding modes for the current video block, such as one of a plurality of intra-predictive coding modes or one of a plurality of inter-predictive coding modes, based on the error result (e.g., coding rate and distortion level). Prediction processing unit 41 provides the resulting intra-predictive or inter-predictive coded block to summer 50 to generate a residual block, which is provided to summer 62 to reconstruct a coded block that may be used as part of a subsequent reference frame. Prediction processing unit 41 also provides syntax elements (e.g., motion vectors, intra-mode indicators, partition information, and other such syntax information) to entropy coding unit 56.
[0349] To select an appropriate intra-prediction coding mode for a current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-prediction coding of the current video block relative to one or more neighboring blocks that are in the same frame as the current block to be encoded to provide spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 perform inter-prediction coding of the current video block relative to one or more predictive blocks of one or more reference frames to provide temporal prediction. Video encoder 20 may perform multiple encoding passes to select an appropriate coding mode for each block of video data, for example.
[0350] In some embodiments, motion estimation unit 42 determines an inter prediction mode for a current video frame by generating a motion vector indicating the displacement of a video block in a current video frame relative to a predictive block in a reference video frame based on a predefined mode in a video frame sequence. Motion estimation by motion estimation unit 42 is a process of generating a motion vector that estimates motion relative to a video block. The motion vector may indicate, for example, the displacement of a video block in a current video frame or image relative to a predictive block in a reference frame, the predictive block being relative to a current block being coded in a current frame. The predefined mode may specify a video frame in the sequence as a P frame or a B frame. Intra BC unit 48 may determine or use motion estimation unit 42 to determine a vector (e.g., a block vector) for intra BC coding in a similar manner as motion estimation unit 42 determines a motion vector for inter prediction.
[0351] In terms of pixel difference, a predictive block for a video block is or corresponds to a block or reference block of a reference frame that is believed to closely match the video block to be coded. The pixel difference may be determined by sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some embodiments, video encoder 20 may calculate values of sub-integer pixel locations for the reference frames stored in DPB 64. For example, video encoder 20 may interpolate values of quarter pixel locations, eighth pixel locations, or other fractional pixel locations of the reference frames. Thus, motion estimation unit 42 may perform motion search for whole pixel locations and fractional pixel locations and output motion vectors with fractional pixel accuracy.
[0352] Motion estimation unit 42 calculates a motion vector for a video block in an inter-predictively coded frame by comparing a position of the video block to a position of a predictive block of a reference frame selected from a first reference frame list (List 0) or a second reference frame list (List 1). Each reference frame list in the first reference frame list and the second reference frame list identifies one or more reference frames stored in DPB 64. Motion estimation unit 42 sends the calculated motion vector to motion compensation unit 44 and then to entropy coding unit 56.
[0353] Motion compensation by motion compensation unit 44 may include extracting or generating a predictive block based on the motion vector determined by motion estimation unit 42. Upon receiving the motion vector for the current video block, motion compensation unit 44 may identify in one of the reference frame lists the predictive block to which the motion vector points, retrieve the predictive block from DPB 64, and forward the predictive block to summer 50. Summer 50 then forms a residual video block of pixel difference values by subtracting pixel values of the predictive block provided by motion compensation unit 44 from pixel values of the current video block being coded. The pixel difference values forming the residual video block may include luma or chroma difference components or both. Motion compensation unit 44 may also generate syntax elements associated with the video blocks of the video frames for use by video decoder 30 in decoding the video blocks of the video frames. The syntax elements may include, for example, syntax elements defining a motion vector for identifying the predictive block, any markers indicating a prediction mode, or 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 described separately for conceptual purposes.
[0354] In some embodiments, the intra BC unit 48 may generate vectors and extract predictive blocks in a manner similar to that described above in connection with the motion estimation unit 42 and the motion compensation unit 44, but these predictive blocks are in the same frame as the current block being coded, and these vectors are referred to as block vectors rather than motion vectors. Specifically, the intra BC unit 48 may determine the intra prediction mode to be used to code the current block. In some examples, the intra BC unit 48 may code the current block using various intra prediction modes, e.g., during multiple separate coding passes, and test their performance by rate-distortion analysis. The intra BC unit 48 may then select and use an appropriate intra prediction mode from the various tested intra prediction modes and generate an intra mode indicator accordingly. For example, the intra BC unit 48 may use the rate-distortion analysis to calculate rate-distortion values for the various tested intra prediction modes, and select and use an intra prediction mode from the tested modes that has the best rate-distortion characteristics as the appropriate intra prediction mode. The rate-distortion analysis typically determines the amount of distortion (or error) between a coded block and the original uncoded block that is coded to produce the coded block, and the bitrate (i.e., number of bits) to produce the coded block. Intra BC unit 48 can calculate ratios from the distortion and rate for the various coded blocks to determine which intra prediction mode exhibits the optimal rate-distortion value for the block.
[0355] In other examples, intra BC unit 48 may use all or part of motion estimation unit 42 and motion compensation unit 44 to perform such functions for intra BC prediction according to embodiments described herein. In either case, for intra block copies, in terms of pixel difference, the predictive block may be a block that is considered to closely match the block to be coded, and the pixel difference may be determined by SAD, SSD, or other difference metric, and identification of the predictive block may include calculating values for the sub-integer pixel bits.
[0356] Video encoder 20 may form pixel difference values by subtracting pixel values of the predictive block, whether the predictive block is from the same frame via intra prediction or a different frame via inter prediction, from pixel values of the current video block being coded to form a residual video block. The pixel difference values that form the residual video block may include both luma and chroma component differences.
[0357] As described above, as an alternative to inter prediction by motion estimation unit 42 and motion compensation unit 44 or intra block copy prediction by intra BC unit 48, intra prediction processing unit 46 may intra predict the current video block. Specifically, intra prediction processing unit 46 may determine an intra prediction mode for encoding the current block. To do so, intra prediction processing unit 46 may encode the current block using various intra prediction modes, e.g., during multiple separate encoding passes, and intra prediction processing unit 46 (or in some examples, a mode selection unit) may select and use an appropriate intra prediction mode from among the tested intra prediction modes. Intra prediction processing unit 46 may provide information indicative of the selected intra prediction mode for the block to entropy encoding unit 56. Entropy encoding unit 56 may encode the information indicative of the selected intra prediction mode into a bitstream.
[0358] After prediction processing unit 41 determines a predictive block for a current video block via inter- or intra-prediction, summer 50 forms a residual video block by subtracting the predictive 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 52 converts the residual video data into residual transform coefficients using a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform.
[0359] Transform processing unit 52 may send the resulting transform coefficients to quantization unit 54. Quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may also reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be changed by adjusting a quantization parameter. In some examples, quantization unit 54 may then perform a scan of a matrix including the quantized transform coefficients. Alternatively, entropy coding unit 56 may perform the scan.
[0360] After quantization, entropy coding unit 56 entropy codes the quantized transform coefficients into a video bitstream, for example using context-adaptive variable length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding method or technique. The coded bitstream may then be transmitted to video decoder 30 shown in FIG. 23 or may be stored in storage device 32 shown in FIG. 23 for later transmission to or retrieval by video decoder 30. Entropy coding unit 56 may also entropy code motion vectors and other syntax elements for the current video frame being coded.
[0361] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block into the pixel domain and generate reference blocks for predicting other video blocks. As mentioned above, motion compensation unit 44 may generate motion compensated prediction blocks from one or more reference blocks of a frame stored in DPB 64. Motion compensation unit 44 may also apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values for use during motion estimation.
[0362] Summer 62 adds the reconstructed residual block to the motion compensated predictive block produced by motion compensation unit 44 to generate a reference block for storage in DPB 64. The reference block may then be used as a predictive block by intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 to inter predict another video block in a subsequent video frame.
[0363] FIG. 25 is a block diagram illustrating an example video decoder 30 according to some embodiments of the present disclosure. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra prediction unit 84, and an intra BC unit 85. The video decoder 30 may perform a decoding process that is substantially the inverse of the encoding process described above in connection with FIG. 24 for the video encoder 20. For example, the motion compensation unit 82 may generate prediction data based on a motion vector received from the entropy decoding unit 80, and the intra prediction unit 84 may generate prediction data based on an intra prediction mode indicator received from the entropy decoding unit 80.
[0364] In some examples, units of the video decoder 30 may be assigned tasks to perform embodiments of the present application. Furthermore, in some examples, embodiments of the present disclosure may be distributed to one or more units of multiple units of the video decoder 30. For example, the intra BC unit 85 may perform embodiments of the present application alone or in combination with other units of the video decoder 30, such as the motion compensation unit 82, the intra prediction unit 84, the entropy decoding unit 80, etc. In some examples, the video decoder 30 may not include the intra BC unit 85, and the functions of the intra BC unit 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82.
[0365] The video data memory 79 may store video data to be decoded by other components of the video decoder 30, such as an encoded video bitstream. The video data stored in the video data memory 79 may be obtained, for example, from the storage device 32, from a local video source such as a camera, through wired or wireless network communication of the video data, or by accessing a physical data storage medium such as a flash memory drive or a hard disk. The video data memory 79 may include a coded picture buffer (CPB) that stores coded video data from the coded video bitstream. The DPB 92 of the video decoder 30 stores reference video data for use by the video decoder 30 in decoding the video data (e.g., in intra or inter predictive coding modes). The video data memory 79 and the DPB 92 may be formed by any of a variety of memory devices, such as dynamic random access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and the DPB 92 are illustrated in FIG. 25 as two distinct components of the video decoder 30. However, it will be apparent to one skilled in the art that video data memory 79 and DPB 92 may be provided by the same memory device or by separate memory devices. In some examples, video data memory 79 may be on-chip with other components of video decoder 30 or off-chip relative to those components.
[0366] During the decoding process, video decoder 30 receives an encoded video bitstream representing video blocks of encoded video frames and associated syntax elements. Video decoder 30 may receive the syntax elements at the video frame level and / or the video block level. Entropy decoding unit 80 of video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Entropy decoding unit 80 then forwards the motion vectors or intra-prediction mode indicators and other syntax elements to prediction processing unit 81.
[0367] If a video frame is coded as an intra-coded predictive block in an intra-predictive (I) frame or other type of frame, intra prediction unit 84 of prediction processing unit 81 may generate predictive data for a video block of the current video frame based on the intra-prediction mode signaled and reference data from previously decoded blocks of the current frame.
[0368] If a video frame is coded as an inter-predictive (i.e., B or P) frame, motion compensation unit 82 of prediction processing unit 81 generates one or more predictive blocks for a video block of the current video frame based on the motion vector and other syntax elements received from entropy decoding unit 80. Each predictive block in the predictive blocks may be generated from a reference frame in one of the reference frame lists in the reference frame list. Video decoder 30 may construct the reference frame lists (List 0 and List 1) using a default construction technique based on the reference frames stored in DPB 92.
[0369] In some examples, when a video block is encoded according to an intra BC mode described herein, intra BC unit 85 of prediction processing unit 81 generates a predictive block for the current video block based on the block vector and other syntax elements received from entropy decoding unit 80. The predictive block may be within the same image reconstruction region of the current video block defined by video encoder 20.
[0370] Motion compensation unit 82 and / or intra BC unit 85 determine prediction information for video blocks of a current video frame by analyzing the motion vectors and other syntax elements, and then use the prediction information to generate predictive blocks for the current video block being decoded. For example, motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra prediction or inter prediction) for decoding video blocks of the video frame, an inter prediction frame type (e.g., B or P), configuration information for one or more of the reference frame lists for the frame, a motion vector for each inter predictively decoded video block of the frame, an inter prediction state for each inter predictively decoded video block of the frame, and other information for decoding video blocks in the current video frame.
[0371] Similarly, intra BC unit 85 uses some of the received syntax elements, such as a flag, to determine that the current video block is predicted in intra BC mode, configuration information about which video blocks of the frame are in the reconstruction domain and should be stored in DPB 92, block vectors for each intra BC predicted video block of the frame, intra BC prediction states for each intra BC predicted video block of the frame, and other information for decoding video blocks in the current video frame.
[0372] Motion compensation unit 82 may also perform interpolation using interpolation filters used by video encoder 20 during encoding of the video block to calculate interpolated values for sub-integer pixels of the reference block. In this case, motion compensation unit 82 may determine from the received syntax elements the interpolation filters used by video encoder 20 and use these interpolation filters to generate the predictive block.
[0373] Inverse quantization unit 86 inverse quantizes the quantized transform coefficients provided in the bitstream and entropy decoded by entropy decoding unit 80, using the same quantization parameters for determining the degree of quantization calculated for each video block in a video frame by video encoder 20. Inverse transform processing unit 88 applies an inverse transform (e.g., an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process) to the transform coefficients in order to reconstruct residual blocks in the pixel domain.
[0374] After motion compensation unit 82 or intra BC unit 85 generates a predictive block for the current video block based on the vectors and other syntax elements, summer 90 reconstructs a decoded video block for the current video block by adding a residual block from inverse transform processing unit 88 to the corresponding predictive block generated by motion compensation unit 82 and intra BC unit 85. An in-loop filter 91, such as a deblocking filter, an SAO filter and / or an ALF, may be disposed between summer 90 and DPB 92 to further process the decoded video block. In some examples, in-loop filter 91 may be omitted and the decoded video block may be provided by summer 90 directly to DPB 92. The decoded video blocks in a given frame are then stored in DPB 92, which stores reference frames for motion compensation after the next video block. DPB 92 or a memory device separate from DPB 92 may also store the decoded video for later display on a display device (such as display device 34 of FIG. 23).
[0375] The description of the present disclosure has been presented for purposes of illustration and is not intended to be limiting of the present disclosure. Many modifications, changes and alternative embodiments will become apparent to those skilled in the art in light of the teachings presented in the foregoing description and the associated drawings.
[0376] The examples are selected and explained in order to understand the principles of the disclosure and to enable those skilled in the art to understand various embodiments of the disclosure, and to suitably utilize the various embodiments having various modifications suited to the specific applications anticipated. Therefore, it is to be understood that the scope of the disclosure is not limited to the specific examples of the disclosed embodiments, and that modifications and other embodiments are intended to be included within the scope of the disclosure.
Claims
1. deriving, by the encoder, a Rice parameter based on encoding information of a current slice of the video; A low-delay transform skip residual coding / decoding (TSRC) method, wherein the coding information includes a hash rate associated with a slice, image or sequence of the video.
2. The low-delay TSRC method of claim 1 , further comprising deriving the Rice parameters based on a video resolution, including a temporal resolution and a spatial resolution, of the video.
3. The low-delay TSRC method of claim 1 , further comprising deriving the Rice parameters at a sequence level, a picture level, a slice level, or a predetermined region of the video.
4. The low-delay TSRC method of claim 3 , further comprising deriving different Rice parameter values for images with different temporal layer IDs.
5. 4. The low-delay TSRC method of claim 3, further comprising deriving the Rice parameters based on a quantization parameter (QP) value used at the sequence level, the picture level, the slice level, or the predetermined region of the video.
6. The low-delay TSRC method of claim 1 , further comprising: setting the Rice parameter to a default value based on a change in coding information between a current slice and a previous slice of the video.
7. The low-delay TSRC method of claim 6 , wherein in response to determining that a temporal layer ID of a current image has changed from a temporal layer ID of a previous image, the Rice parameter is set to the default value.
8. in response to determining that ΔQ is greater than TH, the Rice parameter is set to the default value; Here, ΔQ is abs(QP current ?QP previous ) and QP current is the quantization parameter of the current image, QP previous The low-delay TSRC method according to claim 6 , wherein θ is a quantization parameter of a previous image, and TH is a predetermined threshold value.
9. 9. The low-latency TSRC method of claim 8, wherein in response to determining that a hash rate from an intra block copy mode in a current slice is greater than a predetermined threshold, TH, the Rice parameter is set to a default value of 1.
10. 2. The low-delay TSRC method of claim 1, further comprising: deriving a Rice parameter for each slice of the video based on a value of a parameter abs_remainder coded in a slice preceding the slice according to a coding / decoding order.
11. determining a number of binary digits for binarization of abs_remainder using different Rice parameters in response to determining that a slice has been coded; determining Rice parameters for a subsequent slice based on a number of binary digits for binarization of the abs_remainder; The low-latency TSRC method of claim 10, further comprising:
12. The low-delay TSRC method of claim 10, further comprising: selecting as the Rice parameter for the current slice the Rice parameter that achieves a minimum number of binary digits in the previous slice.
13. responsive to determining that the same QP is employed for the current slice and the previous slice, selecting as the Rice parameter for the current slice a Rice parameter that achieves a minimum number of binary digits in the previous slice; In response to determining that different QPs are employed for the current slice and the previous slice, scaling a number of binary digits generated by the default Rice parameters in the previous slice by a predetermined threshold; comparing said default rice parameters to other rice parameters; selecting a Rice parameter that results in a minimum number of binary digits for the current slice; The low-latency TSRC method of claim 10, further comprising:
14. deriving a Rice parameter for each slice of the video based on a value of a parameter abs_remainder coded in a slice preceding the slice according to a coding / decoding order; adjusting the Rice parameter based on a change in coding information between a current slice and a previous slice of the video; The low-latency TSRC method of claim 1 , further comprising:
15. The low-latency TSRC method of claim 1, wherein the encoding information further includes a quantization parameter or encoding bit depth associated with the slice, the image or the sequence of the video.
16. one or more processors; a memory configured to store instructions executable by the one or more processors; An apparatus for video encoding and decoding, wherein the one or more processors are configured to perform the method of any one of claims 1 to 15 upon execution of the instructions.
17. A non-transitory computer-readable storage medium for video encoding and decoding, storing a computer-executable program, comprising: A non-transitory computer readable storage medium for video encoding and decoding, the computer executable program, when executed by one or more computer processors, causing the one or more computer processors to perform the method of any one of claims 1 to 15 and storing a video bitstream generated by the method of any one of claims 1 to 15.
18. Generating a bitstream according to a method according to any one of claims 1 to 15, A method for storing the generated bitstream, comprising storing the generated bitstream on a computer readable storage medium.
19. 1. A computer program having instructions for storing a bitstream, comprising: A computer program product, the instructions comprising a video bitstream generated by the method of any of claims 1 to 15.
Citation Information
Patent Citations
Rice Parameter Initialization for Coefficient Level Coding in the Video Coding Process
JP2016528796A