Lossless coding mode for video coding

Abstract

An electronic device performs a method of encoding and decoding video data. The method includes receiving, from a video bitstream, a first syntax element of a current picture, determining, in accordance with a determination that the first syntax element indicates that dependent quantization is disabled for the current picture, receiving, from the video bitstream, a second syntax element of the current picture, wherein the second syntax element indicates whether transform skip residual coding in transform skip mode is disabled for the current picture, determining, in accordance with a determination that the first syntax element indicates that dependent quantization is enabled for the current picture, setting the second syntax element to a default value that enables transform skip residual coding in transform skip mode for the current picture, and performing, in accordance with the first syntax element and the second syntax element, transform skip residual decoding and dependent dequantization for the current picture.

Description

[0001] Related applications

[0002] This application claims priority to: (i) U.S. Provisional Patent Application No. 63 / 003,859, filed April 1, 2020, entitled “LOSSLESS CODING MODES FOR VIDEO CODING”, and (ii) U.S. Provisional Patent Application No. 63 / 004,731, filed April 3, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates generally to video data encoding and decoding and compression, and more specifically to improved and simplified methods and systems for lossless encoding and decoding of video. Background Technology

[0004] Various electronic devices, such as digital televisions, laptops or desktop computers, tablets, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video conferencing equipment, and video streaming devices, support digital video. Electronic devices transmit, receive, encode, decode, and / or store digital video data by implementing video compression / decompression standards defined by standards such as MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Codec (AVC), High Efficiency Video Codec (HEVC), and Universal Video Codec (VVC). Video compression typically involves performing spatial (intra-frame) prediction and / or temporal (inter-frame) prediction to reduce or remove redundancy inherent in the video data. For block-based video codecs, video frames are divided into one or more stripes, each strip containing multiple video blocks, also known as coding tree units (CTUs). Each CTU may contain a coding unit (CU) or be recursively subdivided into smaller CUs until a predefined minimum CU size is reached. Each CU (also called a leaf CU) contains one or more transform units (TUs) and each CU also contains one or more prediction units (PUs). Each CU can be encoded and decoded in intra-frame, inter-frame, or IBC modes. Video blocks in an intra-frame (I) codec of a video frame are encoded using spatial predictions about reference samples in adjacent blocks within the same video frame. Video blocks in an inter-frame (P or B) codec of a video frame can be encoded using spatial predictions about reference samples in adjacent blocks within the same video frame or temporal predictions about reference samples in other previous and / or future reference video frames.

[0005] A prediction block for the current video block to be encoded or decoded is derived based on spatial or temporal prediction of previously encoded reference blocks (e.g., neighboring blocks). The process of finding the reference block can be accomplished using a block-matching algorithm. The residual data representing the pixel difference between the current block to be encoded and the prediction block is called the residual block or prediction error. Inter-frame coded blocks are encoded based on the residual block and the motion vector pointing to the reference block forming the prediction block in the reference frame. The process of determining the motion vector is typically called motion estimation. Intra-frame coded blocks are encoded based on the intra-frame prediction mode and the residual block. For further compression, the residual block is transformed from the pixel domain to the transform domain (e.g., the frequency domain) to obtain residual transform coefficients, which can then be quantized. The quantized transform coefficients, initially arranged in a two-dimensional array, can be scanned to generate a one-dimensional vector of transform coefficients, which is then entropy-encoded into a video bitstream for even greater compression.

[0006] The encoded video bitstream is then stored in a computer-readable storage medium (e.g., flash memory) for access by another electronic device with digital video capabilities or transmitted directly to the electronic device via wired or wireless means. The electronic device then performs video decompression (a process opposite to the video compression described above), for example, by parsing the encoded video bitstream to obtain syntax elements from the bitstream, and reconstructs the digital video data from the encoded video bitstream to its original format based at least in part on the syntax elements obtained from the bitstream, and the electronic device displays the reconstructed digital video data on its display.

[0007] As digital video quality evolves from high definition to 4K×2K or even 8K×4K, the amount of video data to be encoded / decoded grows exponentially. Maintaining image quality while efficiently encoding / decoding video data remains a long-standing challenge. Summary of the Invention

[0008] This application describes implementations related to video data encoding and decoding, and more specifically, describes implementations related to improved and simplified methods and systems for lossless encoding and decoding of video.

[0009] According to a first aspect of this application, a method for decoding video data includes: a method for decoding video data comprising: receiving a first syntax element of a current image from a video bitstream; determining that the first syntax element indicates that dependency quantization is disabled for the current image; receiving a second syntax element of the current image from the video bitstream, wherein the second syntax element indicates whether transform skip residual encoding / decoding in transform skip mode is disabled for the current image; determining that the first syntax element indicates that dependency quantization is enabled for the current image; setting the second syntax element to a default value for enabling transform skip residual encoding / decoding in transform skip mode for the current image; and performing transform skip residual decoding and dependency dequantization on the current image according to the first syntax element and the second syntax element.

[0010] According to a second aspect of this application, an electronic device includes one or more processing units, a memory, and a plurality of programs stored in the memory. When executed by one or more processing units, the programs cause the electronic device to perform the method for decoding video data as described above.

[0011] According to a third aspect of this application, a non-volatile computer-readable storage medium stores a plurality of programs for execution by an electronic device having one or more processing units. When executed by one or more processing units, the programs cause the electronic device to perform a method for decoding video data as described above. Attached Figure Description

[0012] The accompanying drawings, included to provide a further understanding of the embodiments and incorporated herein as a part of the specification, illustrate the described embodiments and, together with this specification, serve to explain the underlying principles. Similar reference numerals denote corresponding parts.

[0013] Figure 1 This is a block diagram illustrating an exemplary video encoding and decoding system according to some embodiments of the present disclosure.

[0014] Figure 2 This is a block diagram illustrating an exemplary video encoder according to some embodiments of the present disclosure.

[0015] Figure 3 This is a block diagram illustrating an exemplary video decoder according to some embodiments of the present disclosure.

[0016] Figures 4A to 4E This is a block diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes according to some embodiments of the present disclosure.

[0017] Figures 5A to 5BThis is a block diagram illustrating an example of transform coefficient encoding / decoding using context encoding / decoding and bypass encoding / decoding according to some embodiments of the present disclosure.

[0018] Figure 6 This is a block diagram illustrating an exemplary process of dependency scalar quantization according to some embodiments of the present disclosure.

[0019] Figure 7 This is a block diagram illustrating an exemplary state machine for switching between two different scalar quantizers according to some embodiments of the present disclosure.

[0020] Figures 8A to 8D This is a flowchart illustrating an exemplary process by which a video decoder decodes a current image of a video bitstream according to some embodiments of the present disclosure.

[0021] Figure 9 This is a block diagram illustrating an example context-adaptive binary arithmetic codec (CABAC) engine according to some embodiments of this disclosure. Detailed Implementation

[0022] Referring now to the detailed description, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting details are set forth to aid in understanding the subject matter presented herein. However, it will be apparent to those skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details. For example, it will be apparent to those skilled in the art that the subject matter presented herein can be implemented on many types of electronic devices with digital video capabilities.

[0023] Figure 1 This is a block diagram illustrating an exemplary system 10 for encoding and decoding video blocks in parallel, according to some embodiments of the present disclosure. Figure 1 As shown, system 10 includes source device 12, which generates and encodes video data that will later be decoded by target device 14. Source device 12 and target device 14 can include any electronic device from a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc. In some embodiments, source device 12 and target device 14 are equipped with wireless communication capabilities.

[0024] In some implementations, target device 14 may receive encoded video data to be decoded via link 16. Link 16 may include any type of communication medium or device capable of moving encoded video data from source device 12 to target device 14. In one example, link 16 may include a communication medium enabling source device 12 to transmit encoded video data directly to target device 14 in real time. The encoded video data may be modulated according to communication standards, such as wireless communication protocols, and transmitted to target device 14. The communication medium may include any wireless or wired communication medium, such as radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, 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 means that may facilitate communication from source device 12 to target device 14.

[0025] In some other embodiments, encoded video data may be sent from output interface 22 to storage device 32. The encoded video data in storage device 32 may then be accessed by target device 14 via input interface 28. Storage device 32 may include any data storage medium of various distributed or locally accessed data storage media, such as hard disk drives, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In another example, storage device 32 may correspond to a file server or another intermediate storage device that can hold the encoded video data generated by source device 12. Target device 14 may access the stored video data from storage device 32 via streaming or downloading. The file server may be any type of computer capable of storing and sending encoded video data to target device 14. Exemplary file servers include web servers (e.g., for websites), FTP servers, network attached storage (NAS) devices, or local disk drives. The target device 14 can access the encoded video data via any standard data connection suitable for accessing encoded video data stored on the file server, including wireless channels (e.g., Wi-Fi connections), wired connections (e.g., DSL, cable modems, etc.), or a combination of both. The transmission of encoded video data from storage device 32 can be streaming, downloading, or a combination of both.

[0026] like Figure 1As shown, 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 camera), a video archive containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as source video. As an example, if video source 18 is a camera in a security monitoring system, source device 12 and target device 14 may form a camera phone or video phone. However, the embodiments described in this application are generally applicable to video encoding and decoding and can be applied to wireless and / or wired applications.

[0027] Video can be encoded by video encoder 20, whether captured, pre-captured, or computer-generated. Encoded video data can be directly transmitted to target device 14 via output interface 22 of source device 12. Encoded video data can also (or optionally) be stored on 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 transmitter.

[0028] 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 a modem, and receives encoded video data via link 16. The encoded video data transmitted via link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use by video decoder 30 when decoding the video data. Such syntax elements may be included within the encoded video data transmitted on a communication medium, stored on a storage medium, or stored on a file server.

[0029] In some embodiments, the target device 14 may include a display device 34, which may be an integrated display device or an external display device configured to communicate with the target device 14. The display device 34 displays decoded video data to the 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.

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

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

[0032] Figure 2 This is a block diagram illustrating an exemplary video encoder 20 according to some embodiments described in this application. The video encoder 20 can perform intra-frame predictive coding and decoding and inter-frame predictive coding and decoding of video blocks within a video frame. Intra-frame predictive coding relies on spatial prediction to reduce or remove spatial redundancy in the video data within a given video frame or picture. Inter-frame predictive coding relies on temporal prediction to reduce or remove temporal redundancy in the video data within adjacent video frames or pictures of a video sequence.

[0033] like Figure 2As shown, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a segmentation unit 45, an intra-frame prediction processing unit 46, and an intra-frame block copying (BC) unit 48. In some embodiments, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction. A deblocking filter (not shown) may be located between the adder 62 and the DPB 64 to filter block boundaries to remove block artifacts from the reconstructed video. In addition to the deblocking filter, an in-loop filter (not shown) may be used to filter the output of the adder 62. The video encoder 20 may take the form of a fixed or programmable hardware unit, or may be distributed among one or more of the described fixed or programmable hardware units.

[0034] Video data memory 40 stores video data to be encoded by components of video encoder 20. The video data in video data memory 40 may be obtained, for example, from video source 18. DPB 64 is a buffer that stores reference video data for use by video encoder 20 (e.g., in intra-frame or inter-frame prediction codec modes) when encoding the video data. Video data memory 40 and DPB 64 may be formed from any of a variety of memory devices. In various examples, video data memory 40 may be on-chip along with other components of video encoder 20, or off-chip relative to those components.

[0035] like Figure 2 As shown, after receiving video data, the segmentation unit 45 within the prediction processing unit 41 segments the video data into video blocks. This segmentation may also include segmenting the video frame into stripes, tiles, or other larger coding units (CUs) according to a predefined splitting structure (such as a quadtree structure) associated with the video data. The video frame may be divided into multiple video blocks (or a set of video blocks referred to as tiles). The prediction processing unit 41 may select one of several feasible predictive coding modes for the current video block based on error results (e.g., codec rate and distortion level), such as one or more inter-frame predictive coding modes among multiple intra-frame predictive coding modes. The prediction processing unit 41 may provide the resulting intra-frame predictive coding block or inter-frame predictive coding block to adder 50 to generate a residual block, and to adder 62 to reconstruct the coding block for subsequent use as part of a reference frame. The prediction processing unit 41 also provides syntax elements (such as motion vectors, intra-frame mode indicators, segmentation information, and other such syntax information) to entropy coding unit 56.

[0036] To select a suitable intra-predictive coding / decoding mode for the current video block, the intra-predictive processing unit 46 within the prediction processing unit 41 can perform intra-predictive coding / decoding of the current video block in relation to one or more adjacent blocks in the same frame as the current block to be encoded to provide spatial prediction. The motion estimation unit 42 and motion compensation unit 44 within the prediction processing unit 41 perform inter-predictive coding / decoding of the current video block in relation to one or more prediction blocks in one or more reference frames to provide temporal prediction. The video encoder 20 can execute multiple encoding channels, for example, to select a suitable coding / decoding mode for each block of video data.

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

[0038] Regarding pixel differences, the predicted block is a block of a reference frame that is considered to closely match the PU of the video block to be encoded. Pixel differences can be determined by the sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some implementations, the video encoder 20 can compute values ​​for sub-integer pixel positions of the reference frame stored in the DPB 64. For example, the video encoder 20 can interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Therefore, the motion estimation unit 42 can perform motion search relative to full-pixel positions and fractional pixel positions and output a motion vector with fractional-pixel accuracy.

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

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

[0041] In some implementations, the intra-BC unit 48 may generate vectors and extract prediction blocks in a manner similar to that described above in conjunction with the motion estimation unit 42 and the motion compensation unit 44; however, these prediction blocks are in the same frame as the current block being encoded, 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 for encoding the current block. In some examples, the intra-BC unit 48 may, for example, use various intra-prediction modes to encode the current block during a separate encoding pass and test their performance through rate-distortion analysis. Next, the intra-BC unit 48 may select a suitable intra-prediction mode from the various tested intra-prediction modes for use and generate an intra-mode indicator accordingly. For example, the intra-BC unit 48 may use rate-distortion analysis to calculate rate-distortion values ​​for the various tested intra-prediction modes and select the intra-prediction mode with the best rate-distortion characteristics from the tested modes as the suitable intra-prediction mode to use. Rate-distortion analysis generally determines the amount of distortion (or error) between the coded block and the original uncoded block that was encoded to generate the coded block, as well as the bit rate (i.e., the number of bits) used to generate the coded block. Intra-frame BC unit 48 can calculate the ratio from the distortion and rate for various coded blocks to determine which intra-frame prediction mode exhibits the optimal rate-distortion value for the block.

[0042] In other examples, the intra-frame BC unit 48 may use, in whole or in part, the motion estimation unit 42 and the motion compensation unit 44 to perform such functions for intra-frame BC prediction according to the embodiments described herein. In any case, for intra-frame block copying, in terms of pixel differences, the predicted block may be a block considered to closely match the block to be encoded or decoded, the pixel differences may be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics, and the identification of the predicted block may include calculating values ​​for sub-integer pixel positions.

[0043] Regardless of whether the predicted block comes from the same frame predicted intra-frame or from different frames predicted inter-frame, the video encoder 20 can form a residual video block by subtracting the pixel value of the predicted block from the pixel value of the current video block being encoded. The pixel difference forming the residual video block can include both luma component difference and chroma component difference.

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

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

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

[0047] After quantization, entropy coding unit 56 entropy-encodes the quantized transform coefficients into a video bitstream using, for example, context-adaptive variable-length codec (CAVLC), context-adaptive binary arithmetic codec (CABAC), syntax-based context-adaptive binary arithmetic codec (SBAC), probabilistic interval segmented entropy (PIPE) codec, or another entropy coding method or technique. The encoded bitstream can then be sent to video decoder 30 or archived in storage device 32 for later transmission to or retrieval by video decoder 30. Entropy coding unit 56 can also entropy-encode motion vectors and other syntax elements used for the current video frame being encoded.

[0048] The inverse quantization unit 58 and the inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct residual video blocks in the pixel domain for generating reference blocks to predict other video blocks. As noted above, the motion compensation unit 44 can generate motion-compensated prediction blocks from one or more reference blocks of the frame stored in the DPB 64. The motion compensation unit 44 can also apply one or more interpolation filters to the prediction blocks to compute sub-integer pixel values ​​for use in motion estimation.

[0049] Adder 62 adds the reconstructed residual block to the motion-compensated prediction block generated by motion compensation unit 44 to generate a reference block to be stored in DPB 64. The reference block can then be used as a prediction block by intra-frame BC unit 48, motion estimation unit 42 and motion compensation unit 44 to perform inter-frame prediction of another video block in subsequent video frames.

[0050] Figure 3 This is a block diagram illustrating an exemplary video decoder 30 according to some embodiments of this application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra-frame prediction unit 84, and an intra-frame BC unit 85. The video decoder 30 can perform the functions described above. Figure 2 The decoding process described for the video encoder 20 is essentially the inverse of the encoding process. For example, the motion compensation unit 82 can generate prediction data based on motion vectors received from the entropy decoding unit 80, while the intra-frame prediction unit 84 can generate prediction data based on intra-frame prediction mode indicators received from the entropy decoding unit 80.

[0051] In some examples, units of the video decoder 30 may be assigned tasks to perform embodiments of this application. Furthermore, in some examples, embodiments of this disclosure may be distributed across one or more units of the video decoder 30. For example, the intra-frame BC unit 85 may perform embodiments of this application individually or in combination with other units of the video decoder 30 (such as the motion compensation unit 82, the intra-frame prediction unit 84, and the entropy decoding unit 80). In some examples, the video decoder 30 may not include the intra-frame BC unit 85, and the functionality of the intra-frame BC unit 85 may be performed by other components of the prediction processing unit 81 (such as the motion compensation unit 82).

[0052] Video data memory 79 may store video data, such as encoded video bitstreams, to be decoded by other components of video decoder 30. The video data stored in video data memory 79 may be obtained, for example, from storage device 32, from a local video source (such as a camera), via wired or wireless network communication of video data, or by accessing a physical data storage medium (e.g., a flash drive or hard disk). Video data memory 79 may include a codec picture buffer (CPB) that stores encoded video data from the encoded video bitstream. Decode picture buffer (DPB) 92 of video decoder 30 stores reference video data for use by video decoder 30 (e.g., in intra-frame or inter-frame prediction codec modes) when decoding video data. Video data memory 79 and DPB 92 may be formed of any memory device from 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, video data memory 79 and DPB 92 are shown in... Figure 3 The two components are depicted as video decoder 30. However, it will be apparent to those skilled in the art that video data memory 79 and DPB 92 may be provided by the same memory device or separate memory devices. In some examples, video data memory 79 may be on-chip along with other components of video decoder 30, or off-chip relative to those components.

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

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

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

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

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

[0058] Similarly, the intra-BC unit 85 may use some of the syntax elements in the received syntax elements, such as tags, to determine which video blocks in the current video frame are predicted using the intra-BC mode, which video blocks in the frame are in the reconstruction region and should be stored in the DPB 92, the block vector for each intra-BC predicted video block in the frame, the intra-BC prediction state for each intra-BC predicted video block in the frame, and other information for decoding the video blocks in the current video frame.

[0059] The motion compensation unit 82 may also perform interpolation using interpolation filters, such as those used by the video encoder 20 during the encoding of video blocks, to calculate interpolated values ​​for sub-integer pixels of the reference block. In this case, the motion compensation unit 82 may determine the interpolation filters used by the video encoder 20 from the received syntax elements and use these interpolation filters to generate the prediction block.

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

[0061] After the motion compensation unit 82 or the intra-frame BC unit 85 generates a prediction block for the current video block based on vectors and other syntax elements, the adder 90 reconstructs the decoded video block for the current video block by adding the residual block from the inverse transform processing unit 88 to the corresponding prediction block generated by the motion compensation unit 82 and the intra-frame BC unit 85. An in-loop filter (not shown) may be located between the adder 90 and the DPB 92 for further processing of the decoded video block. The decoded video block in a given frame is then stored in the DPB 92, which stores reference frames for subsequent motion compensation of the next video block. The DPB 92 or a separate memory device may also store the decoded video for later presentation on a display device (e.g., Figure 1 On the display device 34).

[0062] In a typical video encoding and decoding process, a video sequence usually consists of an ordered set of frames or images. Each frame may include three sample arrays, denoted as SL, SCb, and SCr. SL is a two-dimensional array of luma samples. SCb is a two-dimensional array of chrominance samples (Cb). SCr is a two-dimensional array of chrominance samples (Cr). In other cases, a frame may be monochrome and therefore consist of only a two-dimensional array of luma samples.

[0063] like Figure 4AAs shown, the video encoder 20 (or more specifically, the segmentation unit 45) generates a coded representation of a frame by first segmenting the frame into a set of coding tree units (CTUs). A video frame may include an integer number of CTUs ordered sequentially from left to right and top to bottom in raster scan order. Each CTU is the largest logical coding unit, and the width and height of the CTU are signaled by the video encoder 20 using a sequence parameter set, such that all CTUs in the video sequence have the same size, one of 128×128, 64×64, 32×32, and 16×16. However, it should be noted that this application is not necessarily limited to a specific size. Figure 4B As shown, each CTU may include a coding tree block (CTB) for luma samples, two corresponding coding tree blocks for chroma samples, and syntax elements for encoding and decoding the samples of the coding tree blocks. The syntax elements describe the properties of different types of units within the coded pixel block and how the video sequence can be reconstructed at the video decoder 30, including inter-frame prediction or intra-frame prediction, intra-frame prediction mode, motion vectors, and other parameters. In a monochrome image or an image with three separate color planes, the CTU may include a single coding tree block and syntax elements for encoding and decoding the samples of that coding tree block. The coding tree block may be an N×N sample block.

[0064] To achieve better performance, the video encoder 20 can recursively perform tree partitioning on the coding tree blocks of the CTU, such as binary tree partitioning, ternary tree partitioning, quadtree partitioning, or a combination of both, and divide the CTU into smaller coding units (CUs). Figure 4C As described, the 64×64 CTU 400 is first divided into four smaller CUs, each with a block size of 32×32. Of these four smaller CUs, CU 410 and CU 420 are each divided into four CUs with a block size of 16×16. The two 16×16 CUs, 430 and CU 440, are further divided into four CUs with a block size of 8×8. Figure 4D Depicting as shown Figure 4C The final result of the CTU 400 partitioning process described in the paper is a quadtree data structure, where each leaf node of the quadtree corresponds to a CU of various sizes ranging from 32×32 to 8×8. Similar to... Figure 4B The CTU depicted in the image may include, for each CU, a coded block (CB) of luminance samples and two corresponding coded blocks of chrominance samples of the same size frame, and syntax elements for encoding and decoding the samples of the coded blocks. In monochrome images or images with three separate color planes, a CU may include a single coded block and syntax structures for encoding and decoding the samples of the coded block. It should be noted that... Figure 4C and Figure 4DThe quadtree partitioning depicted is for illustrative purposes only, and a CTU can be split into CUs based on quadtree / ternary / binary tree partitioning to adapt to varying local characteristics. In multi-type tree structures, a CTU is partitioned by a quadtree structure, and each quadtree leaf CU can be further partitioned by binary and ternary tree structures. Figure 4E As shown, there are five types of segmentation: quadrilateral segmentation, horizontal binary segmentation, vertical binary segmentation, horizontal ternary segmentation, and vertical ternary segmentation.

[0065] In some implementations, the video encoder 20 may further segment the coded blocks of the CU into one or more M×N prediction blocks (PBs). A prediction block is a rectangular (square or non-square) block of samples to which the same prediction (inter-frame or intra-frame) is applied. A prediction unit (PU) of the CU may include a prediction block for luma samples, two corresponding prediction blocks for chroma samples, and syntax elements for predicting the prediction blocks. In monochrome images or images with three separate color planes, a PU may include a single prediction block and syntax structures for predicting the prediction blocks. The video encoder 20 may generate a predicted luma block, a predicted Cb block, and a predicted Cr block for each PU of the CU.

[0066] Video encoder 20 can use intra-frame prediction or inter-frame prediction to generate prediction blocks for the PU. If video encoder 20 uses intra-frame prediction to generate prediction blocks for the PU, then video encoder 20 can generate prediction blocks for the PU based on decoded samples of the frame associated with the PU. If video encoder 20 uses inter-frame prediction to generate prediction blocks for the PU, then video encoder 20 can generate prediction blocks for the PU based on decoded samples of one or more frames other than the frame associated with the PU.

[0067] After the video encoder 20 generates a predicted luminance block, a predicted Cb block, and a predicted Cr block for one or more PUs of the CU, the video encoder 20 can generate a luminance residual block for the CU by subtracting the predicted luminance block of the CU from the original luminance coding block of the CU, such that each sample in the luminance residual block of the CU indicates the difference between a luminance sample in one of the predicted luminance blocks of the CU and a corresponding sample in the original luminance coding block of the CU. Similarly, the video encoder 20 can generate Cb residual blocks and Cr residual blocks for the CU, respectively, such that each sample in the Cb residual block of the CU indicates the difference between a Cb sample in one of the predicted Cb blocks of the CU and a corresponding sample in the original Cb coding block of the CU, and each sample in the Cr residual block of the CU indicates the difference between a Cr sample in one of the predicted Cr blocks of the CU and a corresponding sample in the original Cr coding block of the CU.

[0068] In addition, such as Figure 4CAs shown, the video encoder 20 can use quadtree partitioning to decompose the luminance residual block, Cb residual block, and Cr residual block of the CU into one or more luminance transform blocks, Cb transform blocks, and Cr transform blocks. A transform block is a rectangular (square or non-square) sample block to which the same transform is applied. A transform unit (TU) of the CU may include a transform block for luminance samples, two corresponding transform blocks for chrominance samples, and syntax elements for transforming the samples in the transform block. Therefore, each TU of the CU may be associated with a luminance transform block, a Cb transform block, and a Cr transform block. In some examples, the luminance transform block associated with a TU may be a sub-block of the CU's luminance residual block. A Cb transform block may be a sub-block of the CU's Cb residual block. A Cr transform block may be a sub-block of the CU's Cr residual block. In a monochrome image or an image with three separate color planes, a TU may include a single transform block and syntax structures for transforming the samples in that transform block.

[0069] The video encoder 20 can apply one or more transforms to the luminance transform block of the TU to generate a luminance coefficient block for the TU. The coefficient block can be a two-dimensional array of transform coefficients. The transform coefficients can be scalars. The video encoder 20 can apply one or more transforms to the Cb transform block of the TU to generate a Cb coefficient block for the TU. The video encoder 20 can apply one or more transforms to the Cr transform block of the TU to generate a Cr coefficient block for the TU.

[0070] After generating coefficient blocks (e.g., luminance coefficient blocks, Cb coefficient blocks, or Cr coefficient blocks), video encoder 20 may quantize the coefficient blocks. Quantization typically refers to the process of quantizing transform coefficients to potentially reduce the amount of data used to represent the transform coefficients, thereby providing further compression. After quantizing the coefficient blocks, video encoder 20 may entropy encode the syntax elements indicating the quantized transform coefficients. For example, video encoder 20 may perform context-adaptive binary arithmetic encoding / decoding (CABAC) on the syntax elements indicating the quantized transform coefficients. Finally, video encoder 20 may output a bitstream comprising a bit sequence that forms a representation of coded frames and associated data; the bitstream may be stored in storage device 32 or transmitted to target device 14.

[0071] After receiving the bitstream generated by the video encoder 20, the video decoder 30 can parse the bitstream to obtain syntax elements. The video decoder 30 can reconstruct frames of video data based at least in part on the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally the inverse of the encoding process performed by the video encoder 20. For example, the video decoder 30 can perform an inverse transform on the coefficient block associated with the TU of the current CU to reconstruct the residual block associated with the TU of the current CU. The video decoder 30 also reconstructs the coded blocks of the current CU by adding samples of the prediction block of the PU for the current CU to the corresponding samples of the transform block of the TU of the current CU. After reconstructing the coded blocks for each CU of the frame, the video decoder 30 can reconstruct the frame.

[0072] As mentioned above, video encoding and decoding primarily use two modes (i.e., intra-frame prediction and inter-frame prediction) to achieve video compression. Palette-based encoding and decoding is another encoding and decoding scheme adopted by many video encoding and decoding standards. In palette-based encoding and decoding (which may be particularly suitable for screen-generated content encoding and decoding), the video codec (e.g., video encoder 20 or video decoder 30) forms a palette table representing the colors of a given block of video data. The palette table includes the most important (e.g., frequently used) pixel values ​​in a given block. Pixel values ​​that are not frequently represented in the video data of a given block are either not included in the palette table or are included in the palette table as escape colors.

[0073] Each entry in the palette table includes an index to the corresponding pixel value in the palette table. The palette index for a sample in a block can be encoded to indicate which entry from the palette table will be used to predict or reconstruct which sample. This palette pattern begins with the process of generating palette predictors for the first block of another such grouping of pictures, strips, tiles, or video blocks. As will be explained below, palette predictors for subsequent video blocks are typically generated by updating previously used palette predictors. For illustrative purposes, it is assumed that palette predictors are defined at the picture level. In other words, a picture may include multiple coded blocks, each with its own palette table, but there is one palette predictor for the entire picture.

[0074] To reduce the number of bits required to signal palette entries in the video bitstream, the video decoder can utilize a palette predictor to determine new palette entries in the palette table used to reconstruct the video block. For example, the palette predictor may include palette entries from previously used palette tables, or may even be initialized using the most recently used palette table by including all entries from the most recently used palette table. In some implementations, the palette predictor may include fewer entries than all entries from the most recently used palette table, and then incorporate some entries from other previously used palette tables. The palette predictor may have the same size as the palette table used to encode and decode a different block, or it may be larger or smaller than the palette table used to encode and decode a different block. In one example, the palette predictor is implemented as a first-in, first-out (FIFO) table comprising 64 palette entries.

[0075] To generate a palette table for blocks of video data from palette predictors, the video decoder may receive a one-bit flag for each entry of a palette predictor from the encoded video bitstream. The one-bit flag may have a first value (e.g., binary 1) indicating that the associated entry for the palette predictor will be included in the palette table, or a second value (e.g., binary 0) indicating that the associated entry for the palette predictor will not be included in the palette table. If the size of the palette predictors is larger than the palette table for blocks of video data, the video decoder may stop receiving more flags once the maximum size for the palette table is reached.

[0076] In some implementations, some entries in the palette table can be directly signaled in the encoded video bitstream without using a palette predictor. For such entries, the video decoder can receive from the encoded video bitstream three separate m-bit values ​​indicating the pixel values ​​for the luma component and two chroma components associated with the entry, where m represents the bit depth of the video data. Those palette entries derived from the palette predictor require only one bit of flag, compared to the multiple m-bit values ​​required for directly signaled palette entries. Therefore, signaling some or all palette entries using a palette predictor can significantly reduce the number of bits required to signal new palette table entries, thereby improving the overall encoding / decoding efficiency of palette pattern encoding / decoding.

[0077] In many cases, the palette predictor for a block is determined based on the palette table used to encode one or more previously encoded blocks. However, when encoding or decoding the first coding tree unit in a picture, strip, or tile, the palette table for previously encoded blocks may be unavailable. Therefore, entries from previously used palette tables cannot be used to generate the palette predictor. In this case, a sequence of palette predictor initialization values ​​can be signaled in the Sequence Parameter Set (SPS) and / or Picture Parameter Set (PPS), which are values ​​used to generate the palette predictor when the previously used palette table is unavailable. The SPS typically refers to the syntax structure applied to a series of consecutive encoded video pictures called a Coded Video Sequence (CVS), where the CVS is determined by the contents of the syntax elements found in the PPS mentioned by the syntax elements found in the header of each strip. The PPS typically refers to the syntax structure applied to the syntax elements of one or more individual pictures within a CVS, where the CVS is determined by the syntax elements found in the header of each strip. Therefore, SPS is generally considered to be a higher-level syntax structure than PPS, which means that syntax elements included in SPS are typically changed less frequently and applied to a larger portion of the video data compared to syntax elements included in PPS.

[0078] Figures 5A to 5B This is a block diagram illustrating an example of transform coefficient encoding / decoding using context encoding / decoding and bypass encoding / decoding according to some embodiments of the present disclosure.

[0079] Transform coefficient encoding and decoding in VVC is similar to that in HEVC because they both use non-overlapping coefficient groups (also known as CGs or sub-blocks). However, there are some differences between the two schemes. 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. Therefore, various CG sizes (1×16, 2×8, 8×2, 2×4, 4×2, and 16×1) can be used in VVC. Encoding and decoding of CGs within a coded block and transform coefficients within a CG are performed according to a predefined scan order.

[0080] To limit the maximum number of context-coded bits (CCB) per pixel, the area of ​​the block size (TB) and the types of video components (i.e., luma and chroma components) are used to derive the maximum number of CCBs per TB. In some embodiments, the maximum number of CCBs is equal to TB_zosize × 1.75. Here, TB_zosize represents the number of samples within the TB after the coefficients are zeroed. Note that the coded_sub_block_flag, which indicates whether the CG contains non-zero coefficients, is not considered for CCB counting.

[0081] Coefficient zeroing is an operation performed on a transform block to set coefficients within a specific region of the transform block to zero. For example, in the current VVC, 64×64TB has an associated zeroing operation. Therefore, all transform coefficients outside the top-left 32×32 region of 64×64TB are forced to zero. In fact, in the current VVC, for any transform block with a size exceeding 32 along a specific dimension, a coefficient zeroing operation is performed along that dimension to set coefficients outside the top-left 32×32 region to zero.

[0082] In VVC transform coefficient encoding and decoding, the variable `remBinsPass1` is first set to the maximum number of context-coded bits allowed (MCCB). During encoding and decoding, this variable is decremented by one each time context-coded bits are signaled. When `remBinsPass1` is greater than or equal to 4, coefficients are signaled using syntax elements including `sig_coeff_flag`, `abs_level_gt1_flag`, `par_level_flag`, and `abs_level_gt3_flag`, all of which use context-coded bits in the first channel. The remaining part of the coefficient's level information is encoded and decoded in the second channel using Columbus and bypass-coded bits, using the syntax element `abs_remainer`. When `remBinsPass1` becomes less than 4 during encoding and decoding in the first channel, the current coefficient is not encoded and decoded in the first channel, but is directly encoded and decoded in the second channel using Columbus and bypass-coded bits, using the syntax element `dec_abs_level`. After all the above levels of encoding and decoding, the sign (sign_flag) for all scan positions where sig_coeff_flag equals 1 is finally encoded and decoded into bypass binary bits. Figure 5A The process is described in the document. For each TB, remBinsPass1 is reset. At most once per TB, a transition occurs from using context-encoded bits for sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag to using bypass-encoded bits for the remaining coefficients. For a coefficient subblock, if remBinsPass1 is less than 4 before encoding / decoding its first coefficient, the entire coefficient subblock is encoded / decoded using bypass-encoded bits.

[0083] Unlike HEVC, where a single residual encoding / decoding scheme is designed to encode and decode both transform coefficients and transform skip coefficients, in VVC, two separate residual encoding / decoding schemes are used for the transform coefficients and transform skip coefficients (i.e., the residuals).

[0084] For example, it was observed that the statistical properties of the residuals in the transform skip mode differed from those of the transform coefficients, and there was no energy compression around the low-frequency components. The residual encoding / decoding was modified to account for the different signal characteristics of the (spatial) transform skip residuals, including:

[0085] (1) Do not send the last x / y position using a signal;

[0086] (2) Encode and decode coded_sub_block_flag for each sub-block except DC sub-block when all previous flags are equal to 0;

[0087] (3) Context modeling of sig_coeff_flag with two adjacent coefficients;

[0088] (4) Use only one context model's par_level_flag;

[0089] (5) Additional flags greater than 5, 7, or 9;

[0090] (6) Derivation of Rice parameters for modifications used in binarization of the remaining part;

[0091] (7) Context modeling for the symbol flag is determined based on the adjacent coefficient values ​​on the left and above, and the symbol flag is parsed after sig_coeff_flag to keep all context-encoded bits together;

[0092] like Figure 5B As shown, the syntax elements sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, and par_level_flag are encoded and decoded in an interleaved manner, point by point, in the first channel. Then, the abs_level_gtX_flag bit plane is encoded and decoded in the second channel, and abs_remainder is encoded and decoded in the third channel.

[0093] Channel 1: sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, par_level_flag

[0094] Channel 2: abs_level_gt3_flag, abs_level_gt5_flag, abs_level_gt7_flag, abs_level_gt9_flag

[0095] Channel 3: abs_remainder

[0096] Figure 6 This is a block diagram illustrating an exemplary process of dependency scalar quantization according to some embodiments of the present disclosure.

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

[0098] Furthermore, the scalar quantization used in HEVC is adapted to a new concept called "dependent scalar quantization." Dependent scalar quantization is a method where the set of permissible reconstructable values ​​for transform coefficients depends on the values ​​of transform coefficient levels preceding the current transform coefficient level in reconstruction order. Compared to the regular independent scalar quantization used in HEVC, the permissible reconstructable vectors are more densely packed in an N-dimensional vector space (where N represents the number of transform coefficients in the transform block). That is, for a given average of permissible reconstructable vectors per N-dimensional unit volume, the average distortion between the input vector and the nearest reconstructed vector is reduced. The dependent scalar quantization method is implemented through the following steps: (a) defining two scalar quantizers with different reconstruction levels, and (b) defining a procedure for switching between the two scalar quantizers.

[0099] exist Figure 6 The diagram shows the two scalar quantizers used, represented by Q0 and Q1. The position of the available reconstruction level is uniquely specified by the quantization step size Δ. The scalar quantizer used (Q0 or Q1) is not explicitly signaled in the bitstream. Instead, the quantizer used for the current transform coefficient is determined by the parity of the transform coefficient levels preceding the current transform coefficient in either the encoding / decoding order or the reconstruction order.

[0100] Figure 7 This is a block diagram illustrating an exemplary state machine for switching between two different scalar quantizers according to some embodiments of the present disclosure.

[0101] like Figure 7As shown, the switching between the two scalar quantizers (Q0 and Q1) is implemented via a state machine with four quantizer states (QState). QState can take four distinct values: 0, 1, 2, and 3. It is uniquely determined by the parity of the transform coefficient levels preceding the current transform coefficient in the encoding / decoding order / reconstruction order. At the start of dequantization for the transform block, the state is set to 0. The transform coefficients are reconstructed in scan order (i.e., in the same order they were entropy-decoded). After reconstructing the current transform coefficient, as... Figure 7 The update state is shown, where k represents the value of the transformation coefficient level.

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

[0103] MatrixType: 30 = 2 (2 for intra-frame and IBC / inter-frame) × 3 (Y / Cb / Cr components) × 5 (square TB size: from 4×4 to 64×64 for luma, from 2×2 to 32×32 for chroma)

[0104] MatrixType_DC: 14 = 2 (2 for intra-frame and IBC / inter-frame, 1 for Y component) × 3 (TB size: 16×16, 32×32, 64×64) + 4 (2 for intra-frame and IBC / inter-frame, 2 for Cb / Cr component) × 2 (TB size: 16×16, 32×32)

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

[0106] The choice of the probabilistic model for the grammatical element associated with the absolute value of the transform coefficient level depends on the value of the absolute level in the local neighborhood or the absolute level of the partially reconstructed level.

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

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

[0109] .sumAbs1: The sum of the absolute levels (absLevel1) reconstructed in the local neighborhood after the first channel;

[0110] .sumAbs: The sum of the absolute levels of the reconstructions in the local neighborhood.

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

[0112] Based on the values ​​of numSig, sumAbs1, and d, a probabilistic model is selected for encoding and decoding sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag. The Rice parameters for binarizing abs_remainder and dec_abs_level are selected based on the values ​​of sumAbs and numSig.

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

[0114] If cIdx equals 0, then ctxInc is derived as follows:

[0115] ctxInc=12×Max(0, QState-1)+Min((locSumAbspass1+1)>>1,3)+(d<2?8: (d<5?4:0))

[0116] Otherwise (cIdx is greater than 0), export ctxInc as follows:

[0117] ctxInc=36+8×Max(0,QState-1)+Min((locSumAbspass1+1)>>1,3)+(d<2?4:0)

[0118] In the current VVC, the slice-level syntax element "slice_ts_residual_coding_disabled_flag" is used to indicate whether residual encoding / decoding for transform skipping is disabled at the slice level, even if the current TU is in transform skipping mode. For example, if slice_ts_residual_coding_disabled_flag equals 1, residual encoding / decoding for transform skipping is disabled for the current TU, and residual encoding / decoding for non-transform skipping mode is invoked. Furthermore, the transform coefficients in the residual encoding / decoding for non-transform skipping mode depend on the quantizer state (QState). However, since dependent scalar quantization is specifically applied to transform skipping mode, dependent scalar quantization should be disabled if residual encoding / decoding for non-transform skipping mode is applied to a current TU with transform skipping mode.

[0119] In some embodiments, the syntax element "ph_dep_quant_enabled_flag" is used to restrict the presence of another syntax element "slice_ts_residual_coding_disabled_flag". Specifically, when the flag "ph_dep_quant_enabled_flag" is equal to 1 (i.e., dependent quantization is enabled at the current image), the flag "slice_ts_residual_coding_disabled_flag" is not signaled but is inferred to be 0. When the flag "ph_dep_quant_enabled_flag" is equal to zero, the flag "slice_ts_residual_coding_disabled_flag" is signaled in the bitstream as follows:

[0120] if(!ph_dep_quant_enabled_flag) slice_ts_residual_coding_disabled_flag u(1)

[0121] In some embodiments, the image header syntax element "ph_ts_residual_coding_disabled_flag" is used to indicate at the image level whether residual codecs for transform skip mode are disabled. If ph_ts_residual_coding_disabled_flag equals 1, residual codecs for transform skip are disabled for the current image and all slices associated with the image header for the current image. Therefore, since ph_ts_residual_coding_disabled_flag equals 1, it is not necessary to signal the corresponding slice_ts_residual_coding_disabled_flag (which is inferred to be 1) in the header of the corresponding slice associated with the image header; if ph_ts_residual_coding_disabled_flag equals 0, the slice_ts_residual_coding_disabled_flag syntax element can still be signaled to indicate whether residual codecs for transform skip are enabled in the current slice.

[0122] In some embodiments, if residual encoding / decoding for transform skip mode is disabled, then dependent scalar quantization (including using dependent quantization states to derive context modeling and Rice parameters for resolving residual samples, as described in the introduction) is disabled. In other words, if `ph_ts_residual_coding_disabled_flag` equals 1, then `ph_dep_quant_enabled_flag` is set to 0. If `ph_dep_quant_enabled_flag` equals 1, then `ph_ts_residual_coding_disabled_flag` is set to 0. In another example, if `ph_dep_quant_enabled_flag` equals 1, then `slice_ts_residual_coding_disabled_flag` is set to 0. In yet another example, both `ph_dep_quant_enabled_flag` and `slice_ts_residual_coding_disabled_flag` can be equal to 1; however, for transform skip, the application of context modeling and Rice parameter derivation for dependent quantization, dependent states, and is ignored; for example, checking if the current TU is in transform skip mode, i.e., ... transform_skip_flag[x0][y0][cIdx].

[0123] In some embodiments, the syntax element `ph_ts_residual_coding_disabled_flag` equal to 1 indicates that residual encoding / decoding for transform skipping is disabled for the current image and only residual encoding / decoding for non-transform skipping is invoked, and the syntax element `ph_ts_residual_coding_disabled_flag` equal to 0 indicates that residual encoding / decoding for transform skipping is applied for the current image. If the syntax element `ph_ts_residual_coding_disabled_flag` does not exist, it is inferred to be 0. The syntax element `ph_dep_quant_enabled_flag` equal to 0 indicates that dependency quantization is disabled for the current image, and the syntax element `ph_dep_quant_enabled_flag` equal to 1 indicates that dependency quantization is enabled for the current image. When the syntax element `ph_dep_quant_enabled_flag` does not exist, it is inferred to be 0. The following table shows an example syntax design where the syntax element `ph_ts_residual_coding_disabled_flag` is used to determine the presence of the syntax element `ph_dep_quant_enabled_flag`.

[0124]

[0125] In some embodiments, dequantization methods (including both dependent quantization and context modeling and state-dependent Rice parameter derivation) are enabled for transform skipping modes. With this design, the following combinations are supported by changing the values ​​of ph_dep_quant_enabled_flag and slice_ts_residual_coding_disabled_flag:

[0126] Case 1: When both flags are equal to 1, dependency quantization is applied to the transform skip mode. Furthermore, the residual encoding / decoding of the non-transform skip mode, along with context modeling of the dependency state and the Ricean parameter derivation of the dependency state, is applied to the transform skip TU.

[0127] Scenario 2: When slice_ts_residual_coding_disabled_flag equals 1 and ph_dep_quant_enabled_flag equals 0. In this case, the regular quantization method is applied to the transform-skip TU. Simultaneously, the residual encoding / decoding in non-transform-skip mode is applied to the transform-skip TU, without applying context modeling of dependent states and Rice parameter derivation of dependent states to the transform-skip TU.

[0128] Case 3: When slice_ts_residual_coding_disabled_flag equals 0 and ph_dep_quant_enabled_flag equals 1. In this case, dependency quantization is applied to the transform skip mode, and the residual encoding and decoding of the transform skip mode are also applied to the transform skip TU. That is, context modeling of dependency states and Rice parameter derivation are not applied to the transform skip TU.

[0129] In the current VVC, if residual encoding / decoding for transform skip mode is disabled, only transform coefficient encoding / decoding is invoked even if the current TU is in transform skip mode. The variable ZeroPos[n] is determined by the dependent scalar quantizer state (QState) and the selected Rice parameter (cRiceParam) associated with the current coefficient at scan position n, as follows:

[0130] ZeroPos[n]=(QState<2?1:2)< <cRiceParam

[0131] like Figure 7 As described, if the current TU is in transform skip mode, but both the scalar quantizer and transform coefficient encoding / decoding are invoked, then QState switches between four states (state 0, state 1, state 2, and state 3) after each transform coefficient is encoded / decoded according to the parity bit of the scalar quantizer selection (Q0 and Q1) and k (which is the previous quantization level in the reconstruction order).

[0132] In some embodiments, if transform coefficient encoding / decoding is invoked for a transform skip TU, the dependent quantization state (QState) is set to a constant value so that the ZeroPos[n] is controlled as follows:

[0133] ZeroPos[n] = 1 <cRiceParam

[0134] In one example, the constant value of dependency quantization (QState) is set to 0.

[0135] In some other embodiments, the variable ZeroPos[n] depends on transform_skip_flag, QState, and cRiceParam, as follows:

[0136] ZeroPos[n]=(QState<2||transform_skip_flag?1:2)< <cRiceParam。

[0137] In some other embodiments, the variable ZeroPos[n] depends on QState, cRiceParam, and the transform skip residual coding disabling flag ts_residual_coding_disabled_flag, which can be signaled at the sequence parameter set (SPS), picture level (e.g., parameter set (PPS), picture header), strip header, tile group header, tile, or at the CTU, CU, or TU level. In one example, the variable ZeroPos[n] is determined as follows:

[0138] ZeroPos[n]=(QState<2||ts_residual_coding_disabled_flag?1:2)< <cRiceParam。

[0139] In the current VVC, if ph_dep_quant_enabled_flag equals 1, then slice_ts_residual_coding_disabled_flag can be set to 1. Therefore, in transform coefficient encoding and decoding, if both ph_dep_quant_enabled_flag and slice_ts_redisual_coding_disabled_flag are equal to 1, then the transform coefficient level variable TransCoeffLevel is modified using the dependent quantization QState as follows.

[0140]

[0141]

[0142] Since the above method reduces the efficiency of lossless encoding and decoding, the derivation of TransCoeffLevel[x0][y0][cIdx][xC][yC] can depend on the transform skip flag. In one example, the derivation of TransCoeffLevel[x0][y0][cIdx][xc][yc] is modified as follows:

[0143]

[0144]

[0145] In some embodiments, the derivation of TransCoeffLevel[x0][y0][cIdx][xC][yC] depends on the transform skip residual coding / decoding disable flag ts_residual_coding_disabled_flag, which can be signaled at the sequence parameter set (SPS), picture level (e.g., parameter set (PPS), picture header), strip header, tile group header, tile, or at the CTU, CU, or TU level. In one example, the derivation of TransCoeffLevel[x0][y0][cIdx][xc][yc] is modified as follows:

[0146]

[0147]

[0148]

[0149] Figures 8A to 8D These are flowcharts illustrating exemplary processes 800 and 900 of a video decoder decoding a current image of a video bitstream according to some embodiments of this disclosure. As mentioned above, since dependent scalar quantization is specifically applied to transform skip mode, dependent scalar quantization should be disabled if residual encoding / decoding for a non-transform skip mode is applied to a current image having a transform skip mode.

[0150] like Figure 8A As described, a video decoder (e.g., video decoder 30) receives a first syntax element (e.g., ph_dep_quant_enabled_flag) of the current image from the video bitstream (810). The video decoder then checks whether dependency quantization is disabled for the current image based on the first syntax element (820). If dependency quantization is disabled for the current image (820 - Yes), the video decoder then receives a second syntax element (e.g., slice_ts_residual_coding_disabled_flag) of the current image from the video bitstream (830). However, if the first syntax element indicates that dependency quantization is enabled for the current image (820 - No), the video decoder sets the second syntax element to the default value for transform-skip residual encoding / decoding in transform-skip mode for the current image (840). The video decoder then performs residual decoding and dependency dequantization on the current image based on the first and second syntax elements (850). In some embodiments, the second syntax element is 1 when the first syntax element is 0; and the first syntax element is 0 when the second syntax element is 1.

[0151] In some embodiments, when the first syntax element indicates that dependency quantization is disabled for the current image, the video decoder disables dependency quantization for the current image (860); when the first syntax element indicates that dependency quantization is enabled for the current image, the video decoder enables dependency quantization for the current image (870).

[0152] In some embodiments, when the second syntax element indicates that transform skip residual coding is enabled for the current image in transform skip mode, the video decoder performs transform skip residual coding in transform skip mode on the current image (880); and when the second syntax element indicates that transform skip residual coding is disabled for the current image in transform skip mode, the video decoder performs regular residual coding in transform skip mode on the current image (890).

[0153] In some embodiments, such as Figure 8B As described, when transform skip residual coding in transform skip mode is not disabled for the current image, the video decoder receives a third syntax element (e.g., slice_ts_residual_coding_disabled_flag) from the video bitstream, where the third syntax element indicates whether transform skip residual coding in transform skip mode is enabled for the current slice associated with the current image (892); when transform skip residual coding in transform skip mode is disabled for the current image, the video decoder sets the third syntax element to the default value of disabling transform skip residual coding in transform skip mode for all slices associated with the current image (894).

[0154] In some embodiments, such as Figure 8C As described in the paper, when transform skip residual encoding and decoding is disabled in transform skip mode for the current image, the video decoder derives context modeling and Rice parameters (896) for parsing the residual samples of the current image, independent of the dependent quantization state of the residual samples of the current image.

[0155] In some embodiments, the video decoder derives the context modeling and Rice parameters used to parse the residual samples of the current image, independent of the dependent quantization state of the residual samples. In other words, there is no dependency between the derivation of the context modeling and Rice parameters and the use of the dependent quantization state.

[0156] In some embodiments, such as Figure 8DAs depicted, the video decoder receives a control flag (910) for the current image from the video bitstream. Based on the control flag, the video decoder invokes transform coefficient encoding / decoding (920) for the transform skip coding unit for the current image, setting a constant value to the dependent quantization state of the transform skip coding unit (930). For each coefficient (940) of the transform skip coding unit, the video decoder determines the corresponding zero position (950) based on the dependent quantization state and the Ricean parameter, and then decodes the coefficient based on the corresponding zero position and the Ricean parameter (960).

[0157] Figure 9 This is a block diagram illustrating an example context-adaptive binary arithmetic codec (CABAC) engine according to some embodiments of this disclosure.

[0158] Context-Adaptive Binary Arithmetic Coding (CABAC) is a form of entropy coding used in many video codec standards, such as H.264 / MPEG-4 AVC, High Efficiency Video Coding (HEVC), and VVC. CABAC is based on arithmetic coding but incorporates several innovations and modifications to adapt it to the needs of video codec standards. For example, CABAC encodes and decodes binary symbols, which maintains low complexity and allows for probabilistic modeling of bits used more frequently for any symbol. Because coding and decoding patterns are typically locally well-correlated, the adaptive selection of the probabilistic model based on local context allows for better modeling of probabilities. Finally, CABAC uses multiplication-free range division by employing quantized probability ranges and probability states.

[0159] CABAC employs multiple probabilistic models for different contexts. It first converts all non-binary symbols to binary. Then, for each binary bit, the codec selects which probability model to use and optimizes the probability estimate using information from nearby elements. Finally, arithmetic encoding and decoding are applied to compress the data.

[0160] Context modeling provides estimates of the conditional probabilities of encoded and decoded symbols. Using a suitable context model, encoding can take advantage of given inter-symbol redundancy by switching between different probability models based on the already encoded and decoded symbols near the current symbol. Encoding and decoding data symbols involves the following stages.

[0161] Binarization: CABAC uses binary arithmetic encoding and decoding, meaning only binary decisions (1 or 0) are encoded and decoded. Non-binary value symbols (such as transform coefficients or motion vectors) are "binarized" or converted into binary code before arithmetic encoding and decoding. This process is similar to converting data symbols into variable-length code, but the binary code is further encoded (by the arithmetic encoder) before transmission. These stages are repeated for each binary bit (or "bit") of the binarized symbol.

[0162] Context Model Selection: A "context model" is a probabilistic model for one or more bits of a binarized symbol. This model is selected from available models based on statistics of recently encoded / decoded data symbols. The context model stores the probability that each bit is "1" or "0".

[0163] Arithmetic encoding: The arithmetic encoder encodes each binary bit according to a selected probability model. Note that there are only two subranges for each binary bit (corresponding to "0" and "1").

[0164] Probability update: Update the selected context model based on the actual encoded / decoded value (e.g., increment the frequency count by "1" if the binary bit value is "1").

[0165] In CABAC, further processing of each bit value depends on an associated encoding / decoding mode decision, which can be chosen as either a regular mode or a bypass mode, by decomposing each non-binary syntax element value into a sequence of bits. The latter is for bit selection, assuming a uniform distribution; therefore, for these bits, the entire regular binary arithmetic encoding (and decoding) process is simply bypassed. In the regular encoding / decoding mode, each bit value is encoded using a regular binary arithmetic encoding / decoding engine, where the associated probabilistic model is determined by a fixed choice based on the syntax element type and the bit position or bit index (binIdx) in the binary representation of the syntax element, or the associated probabilistic model is adaptively selected from two or more probabilistic models based on relevant edge information (e.g., spatial neighbors, components, depth or size of CU / PU / TU, or location within a TU). The selection of the probabilistic model is called context modeling. As an important design decision, the latter case is typically applied only to the most frequently observed bits, while other, less frequently observed bits are processed using a joint, typical zero-order probabilistic model. In this way, CABAC enables selective adaptive probabilistic modeling at the sub-symbol level, thus providing an effective tool for utilizing inter-symbol redundancy and significantly reducing overall modeling or learning costs. Note that, in principle, for both the fixed and adaptive cases, the switch from one probabilistic model to another can occur between any two consecutive regular encoding / decoding bits. Generally, the design of the context model in CABAC reflects the aim of finding a good trade-off between avoiding unnecessary modeling costs and the conflicting goal of largely utilizing statistical correlations.

[0166] The parameters of the probabilistic models in CABAC are adaptive, meaning that the adaptation of the model probability to the statistical changes of the source of the binary bits is performed bit-by-bit in a backward adaptive and synchronous manner in the encoder and decoder; this process is called probability estimation. For this purpose, each probabilistic model in CABAC can choose a state from 126 distinct states using an associated model probability value p, which ranges from [0:01875; 0:98125]. The two parameters of each probabilistic model are stored in the context memory as 7-bit entries: 6 bits are used to represent each of the 63 probabilistic states of the model probability pLPS for the least likely symbol (LPS), and 1 bit is used for nMPS, the value of the most likely symbol (MPS).

[0167] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored on or transmitted via a computer-readable medium as one or more instructions or code, and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium such as a data storage medium, or a communication medium that includes any medium facilitating the transfer of a computer program from one place to another (e.g., according to a communication protocol). In this way, a computer-readable medium may generally correspond to (1) a non-volatile tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium accessible by one or more computers or one or more processors to retrieve instructions, code, and / or data structures used to implement the implementations described in this application. Computer program products may include computer-readable media.

[0168] The terminology used in the description of the embodiments herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the claims. As used in the description of the embodiments and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or,” as used herein, refers to and covers any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprising” and / or “including…”, when used in this specification, specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or groups thereof.

[0169] It will also be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the embodiments, a first electrode may be referred to as a second electrode, and similarly, a second electrode may be referred to as a first electrode. Both the first electrode and the second electrode are electrodes, but they are not the same electrode.

[0170] The description in this application has been presented for purposes of illustration and description and is not intended to be exhaustive or limited to the invention in the forms disclosed. Many modifications, variations, and alternative embodiments will be apparent to those skilled in the art from the teachings presented in the foregoing description and the associated drawings. The embodiments were chosen and described in order to best explain the principles of the invention, its practical application, and to enable others skilled in the art to understand the various embodiments of the invention, and best utilize the basic principles and various embodiments with modifications suitable for the intended particular use. Therefore, it will be understood that the scope of the claims 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 appended claims.

Claims

1. A method for decoding video data, comprising: Receive the first syntax element of the current image from the video bitstream; Based on the determined value of the first syntax element, dependency quantization is disabled for the current image: Receive a second syntax element of the current image from the video bitstream, wherein the second syntax element indicates whether transform skip residual decoding in transform skip mode is disabled for the current image; Based on the determined value of the first syntax element, dependency quantization is enabled for the current image: Set the second syntax element to the default value for enabling transform skip residual decoding in transform skip mode for the current image; and Perform a transformation on the current image based on the first and second syntax elements, skipping residual decoding and dependent inverse quantization. The method further includes: Receive the control flag of the current image from the video bitstream; Based on the control flag indicating that the transform skip encoding unit is invoked for the current image, transform coefficient decoding is called: Set the constant value to the dependent quantization state of the transformation skip coding unit; For each coefficient of the skip coding unit in the transform, The corresponding zero position is determined based on the dependent quantization state and Rice parameter; and The coefficients are decoded based on the corresponding zero position and the Rice parameter.

2. The method according to claim 1, wherein performing transform skip residual decoding on the current image based on the first syntax element and the second syntax element comprises: When the value of the second syntax element indicates that transform skip residual encoding / decoding is enabled for the current image in transform skip mode, transform skip residual encoding / decoding is performed on the current image in transform skip mode; and When the value of the second syntax element indicates that transform skip residual decoding is disabled for the current image in transform skip mode, regular residual decoding in transform skip mode is performed on the current image.

3. The method according to claim 1, wherein performing dependency dequantization on the current image based on the first syntax element and the second syntax element comprises: When the value of the first syntax element indicates that dependency quantization is disabled for the current image, dependency quantization is disabled for the current image; and Dependency quantization is enabled for the current image when the value of the first syntax element indicates that dependency quantization is enabled for the current image.

4. The method according to claim 1, further comprising: When transform skip residual decoding in transform skip mode is not disabled for the current image, a third syntax element is received from the video bitstream, wherein the third syntax element indicates whether transform skip residual decoding in transform skip mode is disabled for the current strip associated with the current image.

5. The method according to claim 4, further comprising: When transform skip residual decoding in transform skip mode is disabled for the current image, the third syntax element is set to the default value of disabling transform skip residual decoding in transform skip mode for all stripes associated with the current image.

6. The method according to claim 1, further comprising: When transform skip residual decoding is disabled in transform skip mode for the current image, context modeling and Rice parameters for parsing the residual samples of the current image are derived independently of the dependent quantization state of the residual samples of the current image.

7. The method of claim 1, wherein when the first syntax element is 0, the second syntax element is 1.

8. The method of claim 1, wherein when the second syntax element is 1, the first syntax element is 0.

9. A method for encoding video data, comprising: Send the first syntax element of the current image via the video bitstream; In the case where the value of the first syntax element indicates that dependency quantization is disabled for the current image: The second syntax element of the current image is sent through the video bitstream, wherein the second syntax element indicates whether transform skip residual coding in transform skip mode is disabled for the current image; When the value of the first syntax element indicates that dependency quantization is enabled for the current image: Set the second syntax element to the default value for enabling transform skip residual coding in transform skip mode for the current image; and Perform a transformation on the current image based on the first and second syntax elements, skipping residual coding and dependency quantization. The method further includes: The control flag of the current image is sent via the video bitstream; Based on the control flag indicating that the transform skip encoding unit is invoked for the current image, the transform coefficient encoding is called: Set the constant value to the dependent quantization state of the transformation skip coding unit; For each coefficient of the skip coding unit in the transform, The corresponding zero position is determined based on the dependent quantization state and Rice parameter; and The coefficients are encoded based on the corresponding zero position and the Rice parameter.

10. The method of claim 9, wherein performing a transform skip residual encoding on the current image according to the first syntax element and the second syntax element comprises: When the value of the second syntax element indicates that transform skip residual coding is enabled for the current image in transform skip mode, transform skip residual coding in transform skip mode is performed on the current image; and When the value of the second syntax element indicates that transform skip residual coding is disabled for the current image in transform skip mode, regular residual coding in transform skip mode is performed on the current image.

11. The method of claim 9, wherein performing dependency quantization on the current image based on the first syntax element and the second syntax element comprises: When the value of the first syntax element indicates that dependency quantization is disabled for the current image, dependency quantization is disabled for the current image; and Dependency quantization is enabled for the current image when the value of the first syntax element indicates that dependency quantization is enabled for the current image.

12. The method according to claim 9, further comprising: When transform skip residual coding in transform skip mode is not disabled for the current image, a third syntax element is sent through the video bitstream, wherein the third syntax element indicates whether transform skip residual coding in transform skip mode is disabled for the current stripe associated with the current image.

13. The method of claim 12, further comprising: When transform skip residual coding in transform skip mode is disabled for the current image, the third syntax element is set to the default value of disabling transform skip residual coding in transform skip mode for all stripes associated with the current image.

14. The method of claim 9, further comprising: When transform skip residual coding is disabled in transform skip mode for the current image, context modeling and Rice parameters for parsing the residual samples of the current image are derived independently of the dependent quantization state of the residual samples of the current image.

15. The method of claim 9, wherein when the first syntax element is 0, the second syntax element is 1.

16. The method of claim 9, wherein when the second syntax element is 1, the first syntax element is 0.

17. An electronic device comprising: One or more processing units; The memory is coupled to the one or more processing units; as well as Multiple programs are stored in the memory, and when executed by the one or more processing units, the multiple programs cause the electronic device to perform the method as described in any one of claims 1 to 16.

18. A non-volatile computer-readable storage medium storing a bit stream formed by instructions, wherein the instructions, when executed by a computing device having one or more processors, cause the one or more processors to perform a method for encoding video data according to any one of claims 9-16.

19. A computer program product having instructions for storing a bitstream, wherein, When executed by a computing device having one or more processors, the instructions cause the one or more processors to perform the method for encoding video data according to any one of claims 9-16.

20. A method for storing a bit stream, comprising: Perform the method according to any one of claims 9-16 to generate a bitstream; as well as Store the bit stream.

21. A method for transmitting a bit stream, comprising: Perform the method according to any one of claims 9-16 to generate a bitstream; as well as Send the bit stream.

Images