Method and apparatus for residual and coefficient coding

Abstract

Methods and apparatus for residual and coefficient encoding / decoding. An electronic device performs a method for decoding video data. The method includes: receiving from a bitstream one or more syntax elements and video data corresponding to a coding unit encoded in a palette mode; determining a first binarization parameter based on the one or more syntax elements; decoding a first codeword from the video data for an escape sample within the coding unit; and decoding the value of the escape sample within the coding unit from the video data using a predefined binarization scheme having the first binarization parameter.

Description

[0001] This application is a divisional application of patent application No. 202080082795.9, filed on October 30, 2020, entitled "Method and Apparatus for Residual and Coefficient Encoding and Decoding".

[0002] Related applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 929,755, filed November 1, 2019, entitled “Residual and Coefficients Coding for Video Coding,” which is incorporated herein by reference in its entirety. Technical Field

[0004] In summary, this application relates to video data encoding and decoding and compression, and more specifically, to an improved method and system for palette pattern encoding and decoding of video data. Background Technology

[0005] Digital video is supported by a wide variety of 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, video streaming devices, and so on. These electronic devices transmit, receive, encode, decode, and / or store digital video data by implementing video compression / decompression standards as defined by 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 eliminate redundancy inherent in the video data. For block-based video codecs, video frames can be divided into one or more stripes, each strip containing multiple video blocks, which may also be referred to as coding tree units (CTUs). Each CTU may contain a coding unit (CU) or be recursively split into smaller CUs until a predefined minimum CU size is reached. Each CU (also known as 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 coded in intra-frame, inter-frame, or IBC modes. Video blocks in the intra-frame coded (I) strips of a video frame are coded using spatial prediction relative to reference samples in adjacent blocks within the same video frame. Video blocks in the inter-frame coded (P or B) strips of a video frame can be coded using spatial prediction relative to reference samples in adjacent blocks within the same video frame, or using temporal prediction relative to reference samples in other previous and / or future reference video frames.

[0006] Spatial or temporal predictions based on previously encoded reference blocks (e.g., neighboring blocks) lead to the encoding of the predicted block for the current video block. 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 predicted block is called the residual block or prediction error. Inter-frame coded blocks are encoded based on the motion vector pointing to the reference block in the reference frame that forms the predicted block and the residual block. The process of determining the motion vector is often 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 produce a one-dimensional vector of transform coefficients, and then their entropy is encoded into the video bitstream for further compression.

[0007] 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 (the reverse of the video compression process described above) by, for example, parsing the encoded video bitstream to obtain syntax elements from the bitstream, and reconstructing the digital video data to its original format based at least in part on the syntax elements obtained from the bitstream, according to the encoded video bitstream, and presents the reconstructed digital video data on the display of the electronic device.

[0008] As digital video quality progresses from high definition to 4Kx2K or even 8Kx4K, the amount of video data to be encoded / decoded grows exponentially. Encoding / decoding video data more efficiently while maintaining the image quality of the decoded video data remains an ongoing challenge. Summary of the Invention

[0009] In summary, this application describes the implementation of methods and systems relating to video data encoding and decoding, and more specifically to improving palette-pattern encoding and decoding for video encoding and decoding.

[0010] According to a first aspect of this application, a method for decoding video data includes: receiving from a bitstream one or more syntax elements corresponding to a coding unit encoded in a palette mode and video data; determining a first binarization parameter based on the one or more syntax elements; decoding from the video data a first codeword for an escape sample within the coding unit; and decoding from the video data the value of the escape sample within the coding unit using a predefined binarization scheme having the first binarization parameter.

[0011] 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 the one or more processing units, the programs cause the electronic device to perform the method for decoding video data as described above.

[0012] According to a third aspect of this application, a non-transitory computer-readable storage medium stores a plurality of programs for execution by an electronic device having one or more processing units. When executed by the 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

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

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

[0015] Figure 2 This is a block diagram illustrating an exemplary video encoder according to some implementations of this disclosure.

[0016] Figure 3 This is a block diagram illustrating an exemplary video decoder according to some implementations of this disclosure.

[0017] Figures 4A to 4E This is a block diagram illustrating how, according to some implementations of this disclosure, a frame is recursively divided into multiple video blocks of different sizes and shapes.

[0018] Figures 5A to 5B This is a block diagram illustrating examples of transform-efficiency encoding and decoding using context encoding and decoding and bypass encoding and decoding in some implementations according to this disclosure.

[0019] Figure 6 This is a block diagram illustrating an exemplary process for relevant scalar quantization implemented according to some embodiments of this disclosure.

[0020] Figure 7 This is a block diagram illustrating an exemplary state machine for switching between two different scalar quantizers, according to some implementations of this disclosure.

[0021] Figures 8A to 8D This is a block diagram illustrating examples of using a palette table to encode and decode video data according to some implementations of this disclosure.

[0022] Figure 9This is a flowchart illustrating an exemplary process by which a video decoder, according to some implementations of this disclosure, performs escape sample decoding on a coded block.

[0023] Figure 10 This is a block diagram illustrating an example context-adaptive binary arithmetic coding (CABAC) engine based on some implementations of this disclosure. Detailed Implementation

[0024] Reference will now be made to specific implementations, examples of which are shown in the accompanying drawings. In the detailed description below, numerous non-limiting specific 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 can be used without departing from the scope of the claims, and that the subject matter can 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 a variety of types of electronic devices with digital video capabilities.

[0025] Figure 1 This is a block diagram illustrating an exemplary system 10 for encoding and decoding video blocks according to some implementations of this disclosure. Figure 1 As shown, system 10 includes source device 12, which generates and encodes video data to be later decoded by destination device 14. Source device 12 and destination device 14 can include any 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, and so on. In some embodiments, source device 12 and destination device 14 are equipped with wireless communication capabilities.

[0026] In some implementations, destination device 14 may receive encoded video data to be decoded via link 16. Link 16 may include any type of communication medium or device capable of moving encoded video data from source device 12 to destination device 14. In one example, link 16 may include a communication medium enabling source device 12 to transmit encoded video data directly to destination device 14 in real time. The encoded video data may be modulated according to a communication standard such as a wireless communication protocol and transmitted to destination device 14. The communication medium may include any wireless or wired communication medium, such as 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, wide area network, or global network such as the Internet. The communication medium may include a router, switch, base station, or any other device that may beneficially facilitate communication from source device 12 to destination device 14.

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

[0028] like Figure 1 As shown, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources such as video capture devices, for example, 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, or a combination of such sources. As an example, if video source 18 is a camera in a security surveillance system, source device 12 and destination device 14 may form a camera phone or video phone. However, the implementation described in this application is generally applicable to video encoding and decoding and can be adapted to wireless and / or wired applications.

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

[0030] Destination 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 in decoding the video data. Such syntax elements may be included in the encoded video data transmitted over a communication medium, stored on a storage medium, or stored on a file server.

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

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

[0033] The video encoder 20 and video decoder 30 can each be implemented as any 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 implemented in part in software, the electronic device may store instructions for software in a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors 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.

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

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

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

[0037] like Figure 2As 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 further include segmenting the video frame into stripes, tiles, or other larger coding units (CUs) according to a predefined segmentation structure (such as a quadtree structure associated with the video data). The video frame can 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 possible predictive coding modes for the current video block based on error results (e.g., coding rate and distortion level), such as one or more inter-frame predictive coding modes among various intra-frame predictive coding modes. The prediction processing unit 41 may provide the resulting intra-frame or inter-frame predictive coded block to adder 50 to produce a residual block, and to adder 62 to reconstruct the coded block for subsequent use as part of a reference frame. The prediction processing unit 41 also provides syntax elements such as motion vectors, intra-frame mode indicators, segmentation information, and other such syntax information to entropy coding unit 56.

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

[0039] In some implementations, motion estimation unit 42 determines the inter-frame prediction mode of the current video frame based on a predetermined pattern within the video frame sequence by generating motion vectors, where the motion vectors indicate the displacement of the 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 of video blocks. For example, the motion vectors may indicate the displacement of the PU of a video block within the current video frame or picture relative to a prediction block within a reference frame (or other coded unit) (relative to the currently encoded block within the current frame (or other coded unit)). The predetermined pattern may designate video frames in the sequence as P-frames or B-frames. Intra-frame BC unit 48 may determine the vectors (e.g., block vectors) for intra-frame BC coding in a manner similar 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.

[0040] A prediction block is a block of a reference frame that is considered to be a close match to the PU of the video block to be encoded in terms of pixel differences, which 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 the values ​​of sub-integer pixel positions of the reference frame stored in the DPB 64. For example, the video encoder 20 can interpolate the values ​​of quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Therefore, the motion estimation unit 42 can perform motion search relative to full-pixel positions and fractional pixel positions and output a motion vector with fractional pixel precision.

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

[0042] 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 motion vectors from the PU for the current video block, motion compensation unit 44 may locate the prediction block pointed to by the motion vector in one of the reference frame lists, retrieve the prediction block from DPB 64, and forward the prediction block to adder 50. Adder 50 then forms a residual video block of pixel difference 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 difference 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. For example, syntax elements may include syntax elements defining motion vectors used to identify prediction blocks, any flags indicating prediction modes, or any other syntax information described herein. It should be noted that the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are shown separately for conceptual purposes.

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

[0044] In other examples, the intra-frame BC unit 48 may use the motion estimation unit 42 and the motion compensation unit 44, either wholly or partially, to perform such functionality for intra-frame BC prediction according to the implementation described herein. In either case, for intra-frame block copying, the predicted block may be a block that is considered to closely match the block to be encoded in terms of pixel differences, which can 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.

[0045] Regardless of whether the predicted block comes from the same frame based on intra-frame prediction or from different frames based on inter-frame prediction, the video encoder 20 can form a residual video block by subtracting the pixel values ​​of the predicted block from the pixel values ​​of the current video block being encoded (forming a pixel difference). The pixel difference forming the residual video block can include a luma component difference and a chroma component difference.

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

[0047] After prediction processing unit 41 determines the prediction block of 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 can be included in one or more transform units (TUs) and provided to transform processing unit 52. Transform processing unit 52 transforms the residual video data into residual transform coefficients using a transform such as discrete cosine transform (DCT) or a conceptually similar transform.

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

[0049] After quantization, entropy coding unit 56 uses, for example, context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probabilistic interval partitioned entropy (PIPE) coding, or other entropy coding methods or techniques to encode the quantized transform coefficients into the video bitstream. 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 perform entropy coding on the motion vectors and other syntax elements of the current video frame being encoded.

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

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

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

[0053] In some examples, tasks for implementing the present application can be assigned to units of the video decoder 30. Furthermore, in some examples, the implementation of the present disclosure can be divided among one or more units of the video decoder 30. For example, the intra-frame BC unit 85 can perform the implementation of the present application either alone or in combination with other units of the video decoder 30 (such as the motion compensation unit 82, the intra-frame prediction processing 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 function of the intra-frame BC unit 85 can be performed by other components of the prediction processing unit 81 (such as the motion compensation unit 82).

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

[0055] During the decoding process, the video decoder 30 receives an encoded video bitstream, which represents video blocks of encoded video frames and associated syntax elements. The video decoder 30 can 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 quantized 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.

[0056] 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 processing 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 notified by a signal and reference data from the previously decoded block of the current frame.

[0057] When a video frame is encoded as an inter-frame predictive coded (i.e., B or P) frame, the motion compensation unit 82 of the prediction processing unit 81 generates one or more prediction blocks for the video block of the current video frame based on the motion vectors and other syntax elements received from the entropy decoding unit 80. Each prediction block can be generated based on reference frames in one of the reference frame lists. 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 the default construction technique.

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

[0059] 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 or inter-frame prediction) used to encode video blocks in the video frame, the inter-frame prediction frame type (e.g., B or P), the construction information of one or more reference frame lists in the frame's reference frame list, the motion vectors of each inter-frame prediction encoded video block in the frame, the inter-frame prediction state of each inter-frame prediction encoded video block in the frame, and other information for decoding video blocks in the current video frame.

[0060] Similarly, the intra-frame BC unit 85 may use some of the syntax elements (e.g., flags) among the received syntax elements to determine the following information: prediction of the current video block using the intra-frame BC mode, construction information of which video blocks of the frame are in the reconstructed region and should be stored in the DPB 92, block vectors for each intra-frame BC predicted video block of the frame, intra-frame BC prediction state for each intra-frame BC predicted video block of the frame, and other information for decoding video blocks in the current video frame.

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

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

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

[0064] In a typical video coding process, a video sequence usually consists of a set of ordered frames or pictures. Each frame may include three sample arrays, denoted as SL, SCb, and SCr. SL is a two-dimensional array of luminance samples. SCb is a two-dimensional array of Cb chrominance samples. SCr is a two-dimensional array of Cr chrominance samples. In other instances, a frame may be monochrome and therefore consist of only a two-dimensional array of luminance samples.

[0065] like Figure 4A As shown, the video encoder 20 (or more specifically, the segmentation unit 45) generates an encoded 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 arranged consecutively from left to right and top to bottom in raster scan order. Each CTU is the largest logical coding unit, and the video encoder 20 signals the width and height of the CTU in a sequence parameter set such that all CTUs in the video sequence have the same size, i.e., 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 4BAs 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 the samples of the coding tree blocks. The syntax elements describe the attributes of different types of units in the encoded pixel block and how the video sequence can be reconstructed at the video decoder 30, including inter-frame 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 the samples of the coding tree block. The coding tree block may be an NxN sample block.

[0066] To achieve better performance, the video encoder 20 can recursively perform tree splitting on the coding tree blocks of the CTU, such as binary tree splitting, ternary tree splitting, quadtree splitting, or a combination of both, and divide the CTU into smaller coding units (CUs). For example, in Figure 4C As depicted, the 64x64 CTU 400 was first divided into four smaller CUs, each with a block size of 32x32. Of these four smaller CUs, CU 410 and CU 420 were each divided into four 16x16 CUs. The two 16x16 CUs, 430 and 440, were further divided into four 8x8 CUs. Figure 4D The quadtree data structure is described, as shown in the example. Figure 4C The final result of the CTU 400 partitioning process depicted in the diagram is that each leaf node of the quadtree corresponds to a CU of a size ranging from 32x32 to 8x8. Just like... Figure 4B The CTU depicted in the image can include, for example, a CU where each CU may comprise a coded block (CB) of luminance samples and two corresponding coded blocks of chrominance samples of the same size frame, as well as syntax elements for encoding the samples of the coded blocks. In monochrome images or images with three separate color planes, a CU may comprise a single coded block and a syntax structure for encoding the samples of the coded block. It should be noted that... Figure 4C and Figure 4D The quadtree segmentation depicted is for illustrative purposes only, and a CTU can be divided into CUs to accommodate varying local features based on quadtree / ternary / binary tree segmentation. In multi-type tree structures, a CTU is segmented via a quadtree structure, and each quadtree leaf CU can be further segmented via 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.

[0067] In some implementations, the video encoder 20 can further segment the coded blocks of the CU into one or more MxN prediction blocks (PBs). A prediction block is a rectangular (square or non-square) sample block on which the same prediction (inter-frame or intra-frame) is applied. A prediction unit (PU) of the CU can 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 can include a single prediction block and a syntax structure for predicting the prediction block. The video encoder 20 can generate predicted luma, Cb, and Cr blocks for each PU of the CU.

[0068] Video encoder 20 can generate prediction blocks for the PU using intra-frame prediction or inter-frame prediction. 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.

[0069] After the video encoder 20 generates predicted luminance, Cb, and Cr blocks for one or more PUs of the CU, the video encoder 20 can generate a luminance residual block of the CU by subtracting the predicted luminance block of the CU from its original luminance coding block, 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.

[0070] In addition, such as Figure 4CAs shown, the video encoder 20 can use quadtree partitioning to decompose the luminance, Cb, and Cr residual blocks of the CU into one or more luminance, Cb, 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 can include a transform block of luminance samples, two corresponding transform blocks of chrominance samples, and syntax elements for transforming the transform block samples. Therefore, each TU of the CU can 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 can be a sub-block of the CU's luminance residual block. A Cb transform block can be a sub-block of the CU's Cb residual block. A Cr transform block can 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 can include a single transform block and syntax structures for transforming the samples of the transform block.

[0071] The video encoder 20 can apply one or more transforms to the luminance transform block of the TU to generate a luminance coefficient block of 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 of 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 of the TU.

[0072] After generating coefficient blocks (e.g., luminance coefficient blocks, Cb coefficient blocks, or Cr coefficient blocks), video encoder 20 can quantize the coefficient blocks. Quantization typically refers to quantizing transform coefficients to reduce the amount of data used to represent the transform coefficients, thereby providing further compression. After quantizing the coefficient blocks, video encoder 20 can entropy-encode the syntax elements indicating the quantized transform coefficients. For example, video encoder 20 can perform context-adaptive binary arithmetic coding (CABAC) on the syntax elements indicating the quantized transform coefficients. Finally, video encoder 20 can output a bitstream comprising bit sequences that form representations of encoded frames and associated data, which is either stored in storage device 32 or transmitted to destination device 14.

[0073] 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, at least in part, based on the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally the reverse 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 blocks of the PU of the current CU to the corresponding samples of the transform blocks 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.

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

[0075] Each entry in the palette table includes an index to the corresponding pixel value in the palette table. The palette indexes of samples within a block can be encoded to indicate which entry in the palette table will be used to predict or reconstruct which sample. This palette pattern begins with generating a palette prediction value for the first block of a group of video blocks, such as pictures, strips, tiles, or other similar blocks. As explained below, palette prediction values ​​for subsequent video blocks are typically generated by updating previously used palette prediction values. For illustration, it is assumed that palette prediction values ​​are defined at the picture level. In other words, a picture may include multiple coded blocks, each with its own palette table, but the entire picture has one palette prediction value.

[0076] To reduce the number of bits required to signal palette entries in the video bitstream, the video decoder can use palette predictions to determine new palette entries in the palette table for reconstructing video blocks. For example, palette predictions can include palette entries from previously used palette tables, or even be initialized with the most recently used palette table by including all entries from the most recently used palette table. In some implementations, palette predictions can include fewer entries than all entries in the most recently used palette table, and then merge some entries from other previously used palette tables. Palette predictions can have the same size as the palette table used to encode different blocks, or they can be larger or smaller than the palette table used to encode different blocks. In one example, the palette predictions are implemented as a first-in-first-out (FIFO) table containing 64 palette entries.

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

[0078] In some implementations, certain entries in the palette table can be signaled directly in the encoded video bitstream, rather than determined using palette predictions. For such entries, the video decoder can receive three separate m-bit values ​​from the encoded video bitstream, each indicating the pixel value of 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 palette predictions require only one bit of flag, compared to the multiple m-bit values ​​needed for directly signaling palette entries. Therefore, signaling some or all palette entries using palette predictions can significantly reduce the number of bits required to signal entries in a new palette table, thereby improving the overall coding efficiency of palette pattern coding.

[0079] In many instances, the palette prediction value for a block is determined based on the palette table used to encode one or more previously encoded blocks. However, when encoding the first coding tree unit in a picture, strip, or tile, the palette table of previously encoded blocks may not be available. Therefore, entries from previously used palette tables cannot be used to generate the palette prediction value. In such cases, a series of palette prediction value initializers can be signaled in the Sequence Parameter Set (SPS) and / or Picture Parameter Set (PPS) to generate the values ​​used to generate the palette prediction value when the previously used palette table is unavailable. The SPS typically refers to the syntax structure of syntax elements applied to a series of consecutively encoded videopictures, referred to as the encoded video sequence (CVS), as determined by the content of the syntax elements found in the PPS, which are pointed to by the syntax elements found in the header of each strip segment. PPS typically refers to the grammatical structure of the grammatical elements applied to one or more individual images within CVS, as determined by the grammatical elements found in the header of each strip segment. Therefore, SPS is generally considered a higher-level grammatical structure than PPS, meaning that the grammatical elements included in SPS typically change less frequently and apply to a larger portion of the video data compared to those included in PPS.

[0080] Figures 5A to 5B This is a block diagram illustrating examples of transform-efficiency coding using context coding and bypass coding in some implementations of this disclosure.

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

[0082] To limit the maximum number of context-coded bits (CCB) per pixel, the maximum number of CCBs for that TB is derived using the area of ​​the TB and the type of video components (i.e., luma and chroma components). In some embodiments, the maximum number of context-coded bits is equal to TB_zosize * 1.75. Here, TB_zosize represents the number of samples within the TB after the coefficients are zeroed. It should be noted that the CCB count does not take into account the coded_sub_block_flag, which is a flag indicating whether the CG contains non-zero coefficients.

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

[0084] In transform coefficient encoding in VVC, the variable `remBinsPass1` is first set to the maximum number of allowed context-coded bits (MCCB). During the encoding process, the variable is decremented by one each time context-coded bits are signaled. When `remBinsPass1` is greater than or equal to four, the coefficient is signaled using syntax elements including `sig_coeff_flag`, `abs_level_gt1_flag`, `par_level_flag`, and `abs_level_gt3_flag`, all using context-coded bits in the first channel. In the second channel, the level information for the remainder of the coefficient is encoded using the syntax element `abs_remainder` with Golomb-Rice coding and bypass coding bits. When encoding the first channel, if `remBinsPass1` becomes less than four, the current coefficient is not encoded in the first channel, but instead directly encoded in the second channel using the syntax element `dec_abs_level` with Golomb-Rice coding and bypass coding bits. After all the levels of encoding mentioned above, the sign (sign_flag) of all scan positions with a sig_coeff_flag equal to one is finally encoded as bypass bits. Figure 5AThe process is described in the document. For each TB, `remBinsPass1` is reset. The conversion from context-encoded bits for `sig_coeff_flag`, `abs_level_gt1_flag`, `par_level_flag`, and `abs_level_gt3_flag` to bypass-encoded bits for the remaining coefficients occurs at most once per TB. For a coefficient subblock, if `remBinsPass1` is less than 4 before encoding its first coefficient, the bypass-encoded bits are used to encode the entire coefficient subblock.

[0085] Unlike HEVC, where a single residual coding scheme is designed to encode both transform coefficients and transform skip coefficients, in VVC, two separate residual coding schemes are used for transform coefficients and transform skip coefficients (i.e., residuals), respectively.

[0086] For example, it has been observed that the statistical properties of the residuals in the transform skip mode differ from those of the residuals in the transform coefficient mode, and there is no energy compression around the low-frequency components. Modifications to the residual coding to account for the different signal characteristics of the (spatial) transform skip residuals include:

[0087] (1) Do not send a signal to notify the last x / y position;

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

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

[0090] (4) par_level_flag uses only one context model;

[0091] (5) Other signs greater than 5, 7, or 9;

[0092] (6) Derivation of the modified rice parameter for remainder binarization;

[0093] (7) Determine the context modeling of the symbol flag based on the adjacent coefficient values ​​on the left and above, and parse the symbol flag after sig_coeff_flag to keep all context-encoded bits together;

[0094] like Figure 5BAs shown, in the first channel, the syntax elements sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, and par_level_flag are encoded from one residual sample to another in an interleaved manner. Then, abs_level_gtX_flag bit-plane encoding is performed in the second channel, and abs_remainder encoding is performed in the third channel.

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

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

[0097] Channel 3: abs_remainder

[0098] Figure 6 This is a block diagram illustrating an exemplary process for relevant scalar quantization in some implementations of this disclosure.

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

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

[0101] exist Figure 6The diagram shows the two scalar quantizers used, denoted by Q0 and Q1. The location of the available reconstruction level is uniquely specified by the quantization step size Δ. The scalar quantizer (Q0 or Q1) used 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 the encoding or reconstruction order.

[0102] Figure 7 This is a block diagram illustrating an exemplary state machine for switching between two different scalar quantizers, according to some implementations of this disclosure.

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

[0104] It also supports signaling default and user-defined scaling matrices. In DEFAULT mode, the scaling matrix remains unchanged, with all elements equal to 16 for all TB sizes. IBC and intra-frame coding modes currently share the same scaling matrix. Therefore, for the USER_DEFINED matrix, the number of MatrixType and MatrixType_DC is updated as follows:

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

[0106] 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)

[0107] For the following scaling matrices: 16×16, 32×32, and 64×64, the DC values ​​are encoded separately. For TBs smaller than 8×8, all elements in a scaling matrix are signaled. If the TB has a size greater than or equal to 8×8, only 64 elements in an 8×8 scaling matrix are signaled as the base scaling matrix. To obtain a matrix larger than 8×8, the 8×8 base scaling matrix is ​​upsampled (by copying elements) to the corresponding matrix size (i.e., 16×16, 32×32, 64×64). When the high-frequency coefficients of the 64-point transform are zeroed, the corresponding high frequencies of the scaling matrix are also zeroed. That is, if the width or height of the TB is greater than or equal to 32, only the coefficients of the left or upper half are retained, and the remaining coefficients are assigned zero. Furthermore, the number of signaled elements 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.

[0108] 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 partial reconstruction.

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

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

[0111] ·sumAbs1: The sum of the absolute levels (absLevel1) of the partial reconstruction after the first channel in the local neighborhood;

[0112] ·sumAbs: The sum of the absolute levels of the reconstructions in the local neighborhood

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

[0114] Based on the values ​​of numSig, sumAbs1, and d, a probabilistic model is selected for encoding sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag. Based on the values ​​of sumAbs and numSig, the Rice parameter is selected for binarizing abs_remainder and dec_abs_level.

[0115] 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 in coefficient encoding, including all types of zeroing (i.e., RMTS32 and existing zeroing for high-frequency components in DCT2). Specifically, the binarization of the last non-zero coefficient position encoding is based on the reduced TU size, and the context model selection for the last non-zero coefficient position encoding is determined by the original TU size. Additionally, 60 context models are used to encode the sig_coeff_flag of the transform coefficients. The selection of the context model index is based on the absolute level of up to five previously partially reconstructed components (referred to as locSumAbsPass1) and the associated quantization state QState, as follows:

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

[0117] ctxInc=12*Max(0,QState–1)+Min((locSumAbsPass1+1)>>1,3)+(d<2?8:(d<5?4:0))

[0118] Otherwise (cIdx is greater than 0), ctxInc is derived as follows:

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

[0120] Figures 8A to 8D This is a block diagram illustrating an example of using a palette table to encode video data according to some implementations of this disclosure.

[0121] For Palette Mode (PLT) signaling, the palette mode is encoded as the prediction mode of the coding unit; that is, the prediction mode used for the coding unit can be MODE_INTRA, MODE_INTER, MODE_IBC, and MODE_PLT. If a palette mode is used, the pixel values ​​in the CU are represented by a small set of representative color values. This set is called the palette. For pixels with values ​​close to the palette colors, the palette index is signaled. For pixels with values ​​outside the palette, the pixel is represented using an escape symbol, and the quantized pixel value is signaled directly.

[0122] To decode a block encoded in palette mode, the decoder needs to decode the palette colors and indices from the bitstream. Palette colors are defined by a palette table and encoded using palette table encoding syntax (e.g., `palette_predictor_run`, `num_signaled_palette_entries`, `new_palette_entries`). For each CU, the escape flag `palette_escape_val_present_flag` is signaled to indicate whether an escape symbol exists in the current CU. If an escape symbol exists, the palette table is incremented by one entry, and the final index is assigned to the escape mode. The palette indices of all pixels in the CU form a palette index map, which is encoded using a palette index map encoding syntax (e.g., num_palette_indices_minus1, palette_idx_idc, copy_above_indices_for_final_run_flag, palette_transpose_flag, copy_above_palette_indices_flag, palette_run_prefix, palette_run_suffix). Figure 8A The image shows an example of a CU encoded using a palette pattern, where the palette size is 4. The first three samples in the CU are reconstructed using palette entries 2, 0, and 3, respectively. "x" samples in the CU represent escape symbols. The CU-level flag `palette_escape_val_present_flag` indicates whether any escape symbols exist in the CU. If escape symbols exist, the palette size is incremented by one, and the last index is used to indicate the escape symbol. Therefore, in Figure 8A In the middle, index 4 is assigned the escape symbol.

[0123] For the encoding of the palette table, maintain palette prediction values. At the beginning of each stripe, initialize the palette prediction values, resetting them to 0. For each entry in the palette prediction values, signal a reuse flag to indicate whether it is part of the current palette. Figure 8BAs shown, the reuse flag `palette_predictor_run` is sent. Following this, the number of new palette entries is signaled using exponential Golomb codes of order 0 via the syntax `num_signaled_palette_entries`. Finally, the component values ​​of the new palette entries `new_palette_entries[]` are signaled. After encoding the current CU, the palette prediction is updated using the current palette, and entries from previous palette predictions that were not reused in the current palette are appended to the end of the new palette prediction until the maximum allowed size is reached.

[0124] To encode the palette index map, the index is encoded using either a horizontal or vertical traversal scan, such as... Figure 8C As shown in the diagram. The palette_transpose_flag is used to explicitly signal the scan order in the bitstream.

[0125] Palette indices are encoded using two primary palette sample modes: 'INDEX' and 'COPY_ABOVE'. In 'INDEX' mode, the palette index is explicitly signaled. In 'COPY_ABOVE' mode, the palette index of the sample in the row above is copied. For both 'INDEX' and 'COPY_ABOVE' modes, a run value is signaled, specifying the number of pixels encoded using the same mode. A flag is used to signal the mode except for the top row (when using horizontal scan) or the first column (when using vertical scan), or when the previous mode was 'COPY_ABOVE'.

[0126] In some embodiments, the encoding order of the index map is as follows: First, the number of index values ​​in the CU is signaled using the syntax `num_palette_indices_minusl`, and then the actual number of index values ​​for the entire CU is signaled using the syntax `palette_idx_idc`. In bypass mode, both the number of indices and the index values ​​are encoded. This groups the bypass-encoded bits associated with the indexes together. Then, the palette mode (INDEX or COPY_ABOVE) and run length are signaled in an interleaved manner using the syntaxes `copy_above_palette_indices_flag`, `palette_run_prefix`, and `palette_run_suffix`. `copy_above_palette_indices_flag` is a context-encoded flag (only one bit), the codeword for `palette_run_prefix` is determined by the process described below in Table 3, and the first 5 bits are context-encoded. `palette_run_suffix` is encoded as bypass bits. Finally, the component escape values ​​corresponding to the escape samples of the entire CU are grouped together and encoded in bypass mode. After signaling the index value, an additional syntax element `copy_above_indices_for_final_run_flag` is signaled. This syntax element, combined with the number of indices, eliminates the need for signaling the run value corresponding to the last run in the block.

[0127] In the VVC (VTM) reference software, dual-tree encoding is enabled for I-stripes, which separates the coding unit partitions for the luma and chroma components. Therefore, the color palette is applied separately to the luma (Y component) and chroma (Cb and Cr components). If dual-tree encoding is disabled, the color palette is applied jointly to the Y, Cb, and Cr components.

[0128] Table 1. Syntax of Palette Coding

[0129]

[0130]

[0131]

[0132]

[0133]

[0134]

[0135] Table 2. Semantics of Palette Encoding

[0136]

[0137]

[0138]

[0139]

[0140] Table 3 shows the binary codewords of the syntax palette_run_prefix and the CABAC context selection.

[0141]

[0142]

[0143]

[0144] At the 15th JVET conference, a row-based CG (document number JVET-O0120) was proposed, and it can be used in... http: / / phenix.int-evry.fr / jvet / This approach simplifies buffer usage and syntax in palette mode in VTM 6.0. As a coefficient group (CG) used in transform coefficient encoding, the CU is divided into multiple row-based coefficient groups, each consisting of m samples. The index run for the escape mode, the palette index value, and the quantized color are sequentially encoded / parsed for each CG. Therefore, pixels in the row-based CG can be reconstructed after parsing the syntax elements (e.g., index run, palette index value, and escape-quantized color for the CG). This significantly reduces the buffer requirements in palette mode in VTM 6.0, where syntax elements for the entire CU must be parsed (and stored) before reconstruction.

[0145] In this application, based on the traversal scanning mode, each CU of the palette mode is divided into multiple segments of m samples (m=8 in this test), such as... Figure 8D As shown in the image.

[0146] The palette run-length encoding order within each segment is as follows: For each pixel, a context-encoded binary bit `run_copy_flag = 0` is signaled, indicating that the pixel has the same pattern as the previous pixel; that is, both the previously scanned pixel and the current pixel are of run-length type `COPY_ABOVE`, or both the previously scanned pixel and the current pixel are of run-length type `INDEX` and have the same index value. Otherwise, `run_copy_flag = 1` is signaled.

[0147] If the current pixel and the previous pixel have different modes, a context-encoded binary bit, `copy_above_palette_indices_flag`, is signaled, indicating the run-length type of the pixel: either `INDEX` or `COPY_ABOVE`. In this case, if the sample is in the first row (horizontal traversal scan) or the first column (vertical traversal scan), the decoder does not need to resolve the run-length type because the default mode is `INDEX`. If the previously resolved run-length type was `COPY_ABOVE`, the decoder also does not need to resolve the run-length type.

[0148] After performing palette run-length encoding on the pixels in a segment, the index values ​​(for INDEX mode) and the quantized escape color are encoded as bypass bits and grouped separately from the encoding / parsing of context-encoded bits to improve throughput within each row-based CG. Since the index values ​​are now encoded / parsed after run-length encoding, the encoder does not need to signal the number of index values ​​(num_palette_indices_minus1) and the last run type (copy_above_indices_for_final_run_flag). The syntax for CG palette mode is shown in Table 4.

[0149] Table 4. Syntax of Palette Coding

[0150]

[0151]

[0152]

[0153]

[0154]

[0155] Figure 9 This is a flowchart 900 illustrating an exemplary process by which a video decoder, according to some implementations of the present disclosure, decodes escaped samples of a coded block encoded in a palette pattern.

[0156] In some embodiments, for a given residual sample block, according to CU QP (represented as QP) CU) to determine the k parameter values of EGk. A specific example is shown, as shown in Table 5 below, where TH1 to TH4 are predefined thresholds satisfying (TH1 < TH2 < TH3 < TH4), and K0 to K4 are the predefined k parameter values. It should be noted that the same logic can be implemented differently in practice. For example, certain equations or look-up tables can also be used to derive the same k parameters based on the QP value of the current CU, as shown in Table 5. In other words, the QP value here serves the dual purpose of defining the quantization level and determining the k parameters.

[0157] Table - 5 Determination of K Parameters Based on QP Value

[0158]

[0159]

[0160] In some embodiments, different k-th order Exp-Golomb binarizations (e.g., k = 1, 2, 3, 4, 5, etc.) can be used to derive different sets of binary codewords for encoding escape values (e.g., palette_escape_val) in the palette mode. In one example, for a given escape sample block, the Exp-Golomb parameter (i.e., the value of the k parameter) is determined according to the QP value of the block (denoted as QP CU ) as shown in the example of Table 5 can be used to derive the value of the k parameter based on the given QP value of the block. Although four different thresholds (from TH1 to TH4) are listed in this example and five different k values (from K0 to K4) can be derived based on these thresholds and QP CU it should be mentioned that the number of thresholds is for illustrative purposes only. In practice, different numbers of thresholds can be used to divide the entire QP value range into different numbers of QP value segments, and for each QP value segment, different k values can be used to derive the corresponding binary codewords for encoding the escape values of the blocks encoded in the palette mode. It should also be noted that the same logic can be implemented differently in practice. For example, certain equations or look-up tables can be used to derive the same k parameters.

[0161] In some embodiments, a set of parameters and / or thresholds associated with the determination of the codewords of the syntax elements of the escape samples is signaled in the bitstream. When encoding the syntax elements of the escape samples by an entropy encoder (e.g., arithmetic coding), the determined codewords are used as binarized codewords.

[0162] It should be noted that the set of parameters and / or thresholds can be the entire set or a subset of all parameters and thresholds associated with the codeword determination of the syntax elements. The set of parameters and / or thresholds can be signaled at different levels within the video bitstream. For example, they can be signaled at the sequence level (e.g., sequence parameter set), picture level (e.g., picture parameter set and / or picture header), stripe level (e.g., stripe header), coding tree unit (CTU) level, or coding unit (CU) level.

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

[0164] It should be noted that the set of k-parameters and their corresponding thresholds can be the entire set or a subset of all k-parameters and their corresponding thresholds associated with the codeword determination of the syntax elements. The set of k-parameters and their corresponding thresholds can be signaled at different levels within the video bitstream. For example, they can be signaled at the sequence level (e.g., sequence parameter set), picture level (e.g., picture parameter set), strip level (e.g., strip header), coding tree unit (CTU) level, or coding unit (CU) level.

[0165] In one example, the k parameter used to determine the codeword used to encode the escaped sample is itself signaled in the strip header, PPS header, and / or SPS header.

[0166] In order to implement the aforementioned improved process for encoding escape samples of coding units, the video decoder 30 first receives one or more syntax elements (e.g., quantization parameter (QP) values ​​and thresholds) and video data (e.g., coding units including one or more escape samples) corresponding to the coding units encoded in palette mode from the bitstream (910).

[0167] Next, the video decoder 30 determines the value (920) of the first binarization parameter (e.g., the Exp-Golomb parameter of the Exp-Golomb binarization scheme) based on one or more syntax elements (e.g., QP value and threshold).

[0168] Then, the video decoder 30 decodes the first codeword for the escape sample within the coding unit from the video data (930).

[0169] After decoding the first codeword, the video decoder 30 converts the first codeword into the value of the escape sample within the coding unit (940) by applying the first binarization parameter to a predefined binarization scheme (e.g., the Exp-Golomb binarization scheme).

[0170] In some embodiments, one or more syntax elements include quantization parameters, and the video decoder 30 further includes determining the first binarization parameter based on one or more syntax elements by: comparing the quantization parameter with a set of thresholds, each threshold having a candidate binarization parameter; determining a pair of thresholds covering the quantization parameter; and determining the first binarization parameter as one of two candidate binarization parameters corresponding to the pair of thresholds.

[0171] In some embodiments, the threshold and the set of associated candidate binarization parameters are constant values.

[0172] In some embodiments, the threshold and its associated set of candidate binarization parameters are variables carried in one or more syntax elements.

[0173] In some embodiments, one or more syntax elements are binarization parameters.

[0174] In some embodiments, the one or more syntax elements are signaled at a level selected from the group consisting of: sequences, pictures, stripes, tiles, coding tree units (CTUs), coding units (CUs), transform units (TUs), and transform blocks (TBs).

[0175] In some embodiments, the one or more syntax elements are signaled in the bitstream.

[0176] Figure 10 This is a block diagram illustrating an example context-adaptive binary arithmetic coding (CABAC) engine based on some implementations of this disclosure.

[0177] 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 with some modifications to adapt it to the needs of video codec standards. For example, CABAC encodes binary symbols, which maintains low complexity and allows probabilistic modeling of the more frequently used bits of any symbol. It adaptively selects a probabilistic model based on local context, which allows for better probabilistic modeling because coding patterns are generally well correlated locally. Finally, CABAC uses multiplication-free range partitioning by using quantized probability ranges and probability states.

[0178] CABAC has multiple probabilistic models for different contexts. It first converts all non-binary symbols to binary. Then, for each binary bit (also called a "bit"), the encoder selects the probabilistic model to use and optimizes the probability estimate using information from nearby elements. Finally, arithmetic coding is applied to compress the data.

[0179] Context modeling provides an estimate of the conditional probability of the encoded symbol. Using a suitable context model, given inter-symbol redundancy can be achieved by switching between different probability models based on the already encoded symbols in the neighborhood of the current symbol to be encoded. Encoding data symbols involves the following stages.

[0180] Binarization: CABAC uses binary arithmetic coding, meaning that only binary decisions (1 or 0) are encoded. Before arithmetic coding, non-binary value symbols (e.g., transform coefficients or motion vectors) are "binarized" or converted into binary code. This process is similar to converting data symbols into variable-length codes, but the binary code is further encoded (by the arithmetic encoder) before transmission. The stages are repeated for each binary bit (or "bit") of the binarized symbol.

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

[0182] Arithmetic encoding: The arithmetic encoder encodes each binary bit according to the selected probability model. It should be noted that each binary bit has only two subranges (corresponding to "0" and "1").

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

[0184] In CABAC, further processing of each binary bit value depends on an associated encoding 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 binary bits. The latter is a bit-by-bit selection, where the bits are assumed to be uniformly distributed, and thus the entire regular binary arithmetic encoding (and decoding) process is simply bypassed. In the regular encoding mode, each binary bit value is encoded using a regular binary arithmetic encoding engine, where the associated probabilistic model is determined by a fixed choice based on the syntax element type and the binary bit position or the binary bit index (binIdx) in the binary representation of the syntax element, or adaptively selected from two or more probabilistic models based on relevant auxiliary information (e.g., spatial neighbors, components, depth or size of CU / PU / TU, or position 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, usually zero-order probabilistic model. In this way, CABAC achieves selective adaptive probabilistic modeling at the sub-symbol level, and thus provides an efficient tool for utilizing inter-symbol redundancy with a significantly reduced overall modeling or learning cost. It should be noted that, in principle, for both the fixed and adaptive cases, the switch from one probabilistic model to another can occur between any two consecutive bits of conventionally encoded data. Generally, the design of the context model in CABAC reflects the goal of finding a good trade-off between avoiding unnecessary modeling-cost overhead and the conflicting objective of largely utilizing statistical correlations.

[0185] The parameters of the probabilistic models in CABAC are adaptive, meaning that in the encoder and decoder, the model probabilities are adapted to statistical changes in the bit source on a bit-by-bit basis in a backward adaptive and synchronous manner; this process is called probability estimation. For this purpose, each probabilistic model in CABAC can choose one of 126 distinct states, each with an associated model probability value p ranging from [0:01875; 0:98125]. Two parameters for each probabilistic model are stored in the context memory as 7-bit entries: 6 bits for each of the 63 probabilistic states, representing the model probability pLPS of the minimum probability symbol (LPS), and 1 bit for nMPS, the value of the maximum probability symbol (MPS).

[0186] In one or more examples, the described functionality may be implemented using hardware, software, firmware, or any combination thereof. If implemented using software, the functionality may be stored on a computer-readable medium and executed by a hardware-based processing unit, or transmitted via a computer-readable medium as one or more instructions or code. 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, including any medium that facilitates, for example, the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may generally correspond to: (1) a non-transitory tangible computer-readable storage medium; or (2) a communication medium such as a signal or carrier waveform. A data storage medium may be any available medium that can be accessed 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. A computer program product may include a computer-readable medium.

[0187] The terminology used in the description of the implementation herein is for the purpose of describing a particular implementation only and is not intended to limit the scope of the claims. As used in the description of the implementation and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or,” as used herein, refers to and covers any one or more of the associated listed items and all possible combinations thereof. It will also be understood that when the terms “comprising” and / or “including” are used in this specification, they 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.

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

[0189] The description of this application is presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications, variations, and alternative implementations will be apparent to those skilled in the art from the teachings given in the foregoing description and the associated drawings. 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 invention in various implementations, and preferably to utilize the basic principles and various implementations with various modifications to suit a particular intended use. Therefore, it should be understood that the scope of the claims is not limited to the specific examples of the disclosed implementations, and that modifications and other implementations are intended to be included within the scope of the appended claims.

Claims

1. A method for encoding video data, the method comprising: A run-length duplication flag is signaled, indicating whether a pixel in the encoding unit has the same run type as a previously scanned pixel. If a pixel in the encoding unit has a different run type than the previously scanned pixel, a flag associated with the palette index of the pixel in the encoding unit is signaled. Determine whether the encoding unit in the palette mode includes escape samples; A signal is sent to indicate whether the encoding unit includes a flag indicating the escaped sample; as well as In the case where the encoding unit includes the escaped sample, The first codeword of the escape sample is determined by using a 5th-order Exp-Golomb binarization scheme associated with the first binarization parameter, in order to encode the value of the escape sample. The 5th-order Exp-Golomb binarization scheme is determined based on one or more syntax elements using a lookup table.

2. The method of claim 1, wherein, The one or more syntax elements are signaled at a level selected from the group consisting of: sequences, pictures, stripes, tiles, coding tree units (CTUs), coding units (CUs), transform units (TUs), and transform blocks (TBs).

3. The method of claim 1, further comprising: Signal the one or more syntax elements in the bit stream.

4. 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 electronic device causes: A run-length duplication flag is signaled, indicating whether a pixel in the encoding unit has the same run type as a previously scanned pixel. If a pixel in the encoding unit has a different run type than the previously scanned pixel, a flag associated with the palette index of the pixel in the encoding unit is signaled. Determine whether the encoding unit in the palette mode includes escape samples; A signal is sent to indicate whether the encoding unit includes a flag indicating the escaped sample; as well as In the case where the encoding unit includes the escaped sample, The first codeword of the escape sample is determined by using a 5th-order Exp-Golomb binarization scheme associated with the first binarization parameter, in order to encode the value of the escape sample. The 5th-order Exp-Golomb binarization scheme is determined based on one or more syntax elements using a lookup table.

5. The electronic device according to claim 4, wherein, The one or more syntax elements are signaled at a level selected from the group consisting of: sequences, pictures, stripes, tiles, coding tree units (CTUs), coding units (CUs), transform units (TUs), and transform blocks (TBs).

6. The electronic device according to claim 4, wherein, When the plurality of programs are executed by the one or more processing units, the electronic device causes the electronic device to signal the one or more syntax elements in the bit stream.

7. A method for decoding video data, the method comprising: Receive video data from the bitstream corresponding to the encoded units encoded in palette mode; Receive a run-length copy flag, the run-length copy flag indicating whether the pixel in the encoding unit has the same run type as the previously scanned pixel; When a pixel in the encoding unit has a different run type than the previously scanned pixel, a flag associated with the palette index of the pixel in the encoding unit is received; The 5th-order Exp-Golomb binarization scheme associated with the first binarization parameter is determined using a lookup table based on one or more syntax elements. Decode the first codeword for the escape sample within the coding unit from the video data; as well as By using the 5th-order Exp-Golomb binarization scheme, a value corresponding to the first codeword used for the escape sample in the coding unit is obtained.

8. The method according to claim 7, wherein, The one or more syntax elements are signaled at a level selected from the group consisting of: sequences, pictures, stripes, tiles, coding tree units (CTUs), coding units (CUs), transform units (TUs), and transform blocks (TBs).

9. The method according to claim 7, wherein, The one or more syntax elements are signaled in the bitstream.

10. 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 electronic device causes: Receive video data from the bitstream corresponding to the encoded units encoded in palette mode; Receive a run-length copy flag, the run-length copy flag indicating whether the pixel in the encoding unit has the same run type as the previously scanned pixel; When a pixel in the encoding unit has a different run type than the previously scanned pixel, a flag associated with the palette index of the pixel in the encoding unit is received; The 5th-order Exp-Golomb binarization scheme associated with the first binarization parameter is determined using a lookup table based on one or more syntax elements. Decode the first codeword for the escape sample within the coding unit from the video data; as well as By using the 5th-order Exp-Golomb binarization scheme, a value corresponding to the first codeword used for the escape sample in the coding unit is obtained.

11. The electronic device according to claim 10, wherein, The one or more syntax elements are signaled at a level selected from the group consisting of: sequences, pictures, stripes, tiles, coding tree units (CTUs), coding units (CUs), transform units (TUs), and transform blocks (TBs).

12. The electronic device according to claim 10, wherein, The one or more syntax elements are signaled in the bitstream.

13. A non-transitory computer-readable storage medium storing a plurality of programs for execution by an electronic device having one or more processing units, wherein, When the plurality of programs are executed by the one or more processing units, the electronic device performs the method according to any one of claims 1-3 to generate a bit stream and transmit the bit stream.

14. A computer program product comprising a plurality of programs, said plurality of programs being executed by an electronic device having one or more processing units, wherein, When the plurality of programs are executed by the one or more processing units, the electronic device performs the method according to any one of claims 1-3 to generate a bit stream and transmit the bit stream.

15. A method for transmitting a bit stream, comprising: Perform the method according to any one of claims 1 to 3 to generate a bitstream; as well as The bit stream is sent to the decoding device.

Images