VIDEO CODING METHODS AND APPARATUS THAT USE PALETTE MODE

Abstract

An electronic device performs a method of decoding video data. The method comprises: receiving, from the bitstream, a plurality of syntax elements associated with an encoding unit, wherein the plurality of syntax elements indicates the encoding tree type of the encoding unit and whether local dual-tree mode is enabled for the encoding unit; and, based on the determination that the encoding tree type of the encoding unit is single-tree and that local dual-tree mode is enabled for the encoding unit; disabling palette mode for the encoding unit when the encoding unit is equal to or smaller than a predetermined threshold.In some modes, disabling palette mode for the encoding unit includes: disabling palette mode for both the luma and chroma components of the encoding unit, or disabling palette mode only for the chroma component of the encoding unit.

Description

VIDEO CODING METHODS AND APPARATUS THAT USE PALETTE MODE FIELD OF INVENTION This application relates, in general, to video data encoding and compression and, in particular, to a video encoding method and system that uses palette mode. BACKGROUND OF THE INVENTION Digital video is supported by a variety of electronic devices, such as digital televisions, desktop and laptop computers, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video conferencing devices, 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 the MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4 Part 10, Advanced Video Coding (AVC), High Efficiency Video Coding (HEVC), and Versatile Video Coding (VVC) standards.Typically, video compression involves performing spatial (intrastructure) and / or temporal (interstructure) prediction to reduce or eliminate inherent redundancy in video data. For block-based video coding, a video structure is divided into one or more slices, with each slice containing multiple video blocks, also known as encoding tree units (CTUs). Each CTU can contain a single encoding unit (CU) or be repeatedly divided into smaller CUs until a predefined minimum CU size is reached. Each CU (also called a leaf CU) contains one or more transformation units (TUs) and one or more prediction units (PUs). Each CU can be encoded in either intra-, inter-, or IBC modes.Video blocks in an intra-coded (I) slice of a video structure are encoded using spatial prediction with respect to reference samples in surrounding blocks within the same video structure. Video blocks in an inter-coded (P or B) slice of a video structure can use spatial prediction with respect to reference samples in surrounding blocks within the same video structure or temporal prediction with respect to reference samples in other reference video structures, both previous and / or future. Spatial or temporal prediction based on a previously encoded reference block, such as a surrounding block, results in a predictive block for the current video block to be encoded. The process of finding the reference block can be carried out using a block-matching algorithm. Residual data representing pixel differences between the current block to be encoded and the predictive block are referred to as a residual block or prediction errors. An inter-coded block is encoded according to a motion vector pointing toward a reference block in a reference structure that forms the predictive block and the residual block. The process of determining the motion vector is typically referred to as motion estimation. An intra-coded block is encoded according to an intra-prediction mode and the residual block.For further understanding, the residual block is transformed from the pixel domain into a transformation domain, for example, a frequency domain, resulting in residual transformation coefficients, which can then be quantized. The quantized transformation coefficients, initially placed in a two-dimensional array, can be scanned to produce a one-dimensional vector of transformation coefficients and then encoded by entropy into a video bitstream to achieve even greater compression. The encoded video bitstream is then stored on a computer-readable storage medium (e.g., flash memory) for access by another electronic device with digital video capability or for direct transmission to the electronic device, either wirelessly or via cable. The electronic device then performs video decompression (the opposite of video compression, as described above) by, for example, parsing the encoded video bitstream to extract syntax elements from the bitstream and reconstructing the digital video data in its original format from the encoded video bitstream, based at least in part on the syntax elements extracted. The reconstructed digital video data is then displayed on the electronic device. With digital video quality ranging from high definition to 4Kx2K or even 8Kx4K, the amount of video data to be encoded / decoded grows exponentially. It is a constant challenge to find ways to encode / decode video data more efficiently while maintaining the image quality of the decoded video data. BRIEF DESCRIPTION OF THE INVENTION This application describes implementations related to the encoding and decoding of video data and, more particularly, to the encoding and decoding system and method that uses palette mode. According to a first aspect of the present application, a method for decoding video data includes: receiving, from the bitstream, a plurality of syntax elements associated with an encoding unit, wherein the plurality of syntax elements indicates the encoding tree type of the encoding unit and whether local dual-tree mode is enabled for the encoding unit; and, according to the determination that the encoding tree type of the encoding unit is a single tree, and that local dual-tree mode is enabled for the encoding unit: disabling palette mode for the encoding unit when the encoding unit is equal to or smaller than a predefined threshold. In some modes, disabling palette mode for the encoding unit includes: disabling palette mode for both the luma and chroma components of the encoding unit. In some modes, disabling palette mode for the encoding unit includes: disabling palette mode only for the chroma component of the encoding unit. According to a second aspect of this application, an electronic device includes one or more processing units, memory, and a plurality of programs stored in memory. When the programs are executed by the one or more processing units, they cause the electronic device to perform the video data decoding method as described above. According to a third aspect of this application, a non-transient, computer-readable storage medium stores a plurality of programs for execution by an electronic device having one or more processing units. When the program is executed by the one or more processing units, it causes the electronic device to perform the video data decoding method as described above. BRIEF DESCRIPTION OF THE FIGURES The accompanying figures, which are included to provide a better understanding of the implementations and are incorporated herein and form part of the specification, illustrate the described implementations and, together with the description, serve to explain the underlying principles. Equal numerical references refer to corresponding parts. FIGURE 1 is a block diagram illustrating an exemplary video encoding and decoding system, according to some implementations of the present description. FIGURE 2 is a block diagram illustrating an exemplary video encoder, according to some implementations of the present description. FIGURE 3 is a block diagram illustrating an exemplary video decoder, according to some implementations of the present description. Figures 4A to 4E are block diagrams that illustrate how a structure is recursively divided into multiple video blocks of different sizes and shapes, according to some implementations of the present description. Figures 5A to 5D are block diagrams that illustrate examples of the use of palette tables for video data encoding, according to some implementations of the present description. FIGURE 6 is a flowchart illustrating an exemplary process by which a video decoder implements video data decoding techniques, according to some implementations of the present description. FIGURE 7 is a block diagram illustrating an exemplary context-adapted binary arithmetic coding (CABAC) engine, according to some implementations of the present description. DETAILED DESCRIPTION OF THE INVENTION Specific implementations will now be discussed in detail, examples of which are illustrated in the accompanying figures. The following detailed description includes numerous specific, non-limiting details intended to aid in understanding the subject matter presented herein. However, it will be apparent to one of ordinary experience in the field that various alternatives may be used without departing from the scope of the claims, and the subject matter may be practiced without these specific details. For example, it will be apparent to one of ordinary experience in the field that the subject matter presented herein may be implemented in many types of electronic devices with digital video capabilities. nznz Ln / zznz / E / YiAi Figure 1 is a block diagram illustrating an exemplary system 10 for parallel encoding and decoding of video blocks, according to some implementations of the present description. As shown in Figure 1, the system 10 includes a source device 12 that generates and encodes video data to be decoded at a later time by a destination device 14. The source device 12 and destination device 14 can comprise any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, digital signal decoders, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or the like.In some implementations, the source device 12 and destination device 14 are equipped with wireless communication capabilities. In some implementations, the destination device 14 can receive the encoded video data for decoding via a link 16. Link 16 can comprise any type of communication medium or device capable of moving the encoded video data from the source device 12 to the destination device 14. For example, link 16 might comprise a communication medium that allows the source device 12 to transmit the encoded video data directly to the destination device 14 in real time. The encoded video data can be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium can comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines.The communication medium may be part of a packet-based network, such as a local area network, a wide area network, or a global network, such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful in facilitating communication from the source device 12 to the destination device 14. In some other implementations, the encoded video data can be transmitted from output interface 22 to a storage device 32. The encoded video data on storage device 32 can then be accessed by the destination device 14 through input interface 28. Storage device 32 can be any of a variety of data storage media, accessed locally or in a distributed manner, such as a hard drive, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other digital storage medium suitable for storing encoded video data. In another example, storage device 32 could be a file server or other intermediate storage device that holds the encoded video data generated by the source device 12.Destination device 14 can access the stored video data from storage device 32 via streaming or download. The file server can be any type of computer capable of storing and transmitting encoded video data to destination device 14. Examples of file servers include a network server (e.g., for a networked site), an FTP server, network-attached storage (NAS) devices, or a local disk drive. Destination device 14 can access the encoded video data through any standard data connection, including a wireless channel (e.g., a Wi-Fi connection) or a wired connection (e.g., DSL, cable modem, etc.).or a combination of both, suitable for accessing encoded video data stored on a file server. The transmission of encoded video data from storage device 32 can be a continuous stream transmission, a download transmission, or a combination of both. As shown in FIGURE 1, the source device 12 includes a video source 18, a video encoder 20, and an output interface 22. A video source 18 can include a source such as a video capture device, for example, a video camera, a video file containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as the video source, or a combination of such sources. For example, if the video source 18 is a video camera in a security surveillance system, the source device 12 and destination device 14 could be camera phones or video phones.However, the implementations described in this application may be applicable to video encoding in general, and may be applied in wireless and / or wired connection applications. Computer-generated, captured, or pre-captured video can be encoded using video encoder 20. The encoded video data can be transmitted directly to the destination device 14 via output interface 22 of the source device 12. The encoded video data can also be stored (or alternatively) on storage device 32 for later access by the destination device 14 or other devices for decoding and / or playback. Output interface 22 may also include a modem and / or a transmitter. The destination device 14 includes an input interface 28, a video decoder 30, and a display device 34. The input interface 28 may include a receiver and / or a modem and receive the encoded video data over link 16. The encoded video data, communicated over link 16 or provided on storage device 32, may include a variety of syntax elements generated by video encoder 20 for use by video encoder 30 in decoding the video data. Such syntax elements may be included within the encoded video data, transmitted over a communication medium, stored on a storage medium, or stored on a file server. In some implementations, the target device 14 may include a display device 34, which may be an integrated display device and an external display device that is configured to communicate with the target device 14. The display device 34 displays the decoded video data to a user, and may comprise 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. The video encoder 20 and video decoder 30 can operate in accordance with proprietary or industry standards, such as WC, HEVC, MPEG-4 Part 10, Advanced Video Coding (AVC), or extensions of such standards. It should be understood that this application is not limited to any specific video encoding / decoding standard and may be applicable to other video encoding / decoding standards. It is generally envisaged that the video encoder 20 of the source device 12 can be configured to encode video data in accordance with any of these current or future standards. Similarly, it is generally also envisaged that the video encoder 30 of the destination device 14 can be configured to decode video data in accordance with any of these current or future standards. The video encoder 20 and video decoder 30 can each be implemented as any of a variety of suitable encoder circuitry, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When partially implemented in software, an electronic device can store instructions for the software on a suitable, non-transient, computer-readable medium and execute the instructions in hardware using one or more processors to perform the video encoding / decoding operations described herein.Each of the video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined encoder / decoder (CODEC) in a respective device. Figure 2 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- and inter-predictive coding of video blocks within video frames. Intra-predictive coding relies on spatial prediction to reduce or eliminate spatial redundancy in video data within a given video frame or image. Inter-predictive coding relies on temporal prediction to reduce or eliminate temporal redundancy in video data within adjacent video frames or images of a video sequence. As shown in FIGURE 2, the video encoder 20 includes a video data memory 40, prediction processing unit 41, decoded image buffer (DPB) 64, summing device 50, transform processing unit 52, quantization unit 54, and entropy encoding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, motion compensation unit 44, splitting unit 45, intra-prediction processing unit 46, and intra-block copy (BC) unit 48. In some implementations, the video encoder 20 also includes an inverse quantization unit 58, inverse transform processing unit 60, and summing device 62 for video block reconstruction.A deblocking filter (not shown) can be placed between the summing device 62 and DPB 64 to filter block boundaries in order to remove block-shaped artifacts from reconstructed video. A loop filter (not shown) can also be used in addition to the deblocking filter to filter the output of the summing device 62. The video encoder 20 can take the form of a fixed or programmable hardware unit or can be divided among one or more of the illustrated fixed or programmable hardware units. Video data memory 40 can store video data to be encoded by the 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 in encoding video data by video encoder 20 (for example, in intra- or inter-predictive encoding modes). Video data memory 40 and DPB 64 can be formed using any of a variety of memory devices. In some instances, video data memory 40 may be on-chip with other components of video encoder 20 or off-chip in relation to those components. As shown in Figure 2, after receiving video data, the splitting unit 45 within the prediction processing unit 41 divides the video data into video blocks. This splitting can also include dividing a video structure into slices, tiles, or other larger coding units (CUs) according to a predefined splitting structure, such as a quad-tree structure, associated with the video data. The video structure can be split into multiple video blocks (or sets of video blocks referred to as tiles). The prediction processing unit 41 can select one of a plurality of possible predictive coding modes, such as one of a plurality of intra-predictive coding modes or one of a plurality of inter-predictive coding modes, for the current video block based on error results (e.g., coding rate and distortion level).The prediction processing unit 41 can provide the resulting intra- or inter-prediction encoded block to the summing device 50 to generate a residual block and to the summing device 62 to reconstruct the encoded block for later use as part of a reference structure. The prediction processing unit 41 also provides syntax elements, such as movement vectors, intra-mode flags, split information, and other syntax information, to the entropy encoding unit 56. In order to select a suitable intra-predictive coding mode for the current video block, the intra-predictive processing unit 46 within the prediction processing unit 41 can perform intra-predictive coding of the current video block relative to one or more surrounding blocks in the same structure as the current block to be coded, thus providing spatial prediction. The motion estimation unit 42 and the motion compensation unit 44 within the prediction processing unit 41 perform inter-predictive coding of the current video block relative to one or more predictive blocks in one or more reference structures, thus providing temporal prediction. The video encoder 20 can perform multiple coding steps, for example, to select a suitable coding mode for each video data block. nznz Ln / zznz / E / YiAi In some implementations, the motion estimation unit 42 determines the interprediction mode for a current video structure by generating a motion vector. This vector indicates the displacement of a prediction unit (PU) of a video block within the current video structure, relative to a predictive block within a reference video structure, according to a predetermined pattern within a sequence of video structures. The motion estimation performed by motion estimation unit 42 is the process of generating motion vectors that estimate movement for video blocks.For example, a motion vector can indicate the displacement of a PU of a video block within a current video or image structure relative to a predictive block within a reference structure (or other encoded unit) relative to the current block being encoded within the current structure (or other encoded unit). The default pattern can designate video structures in the sequence as P-structures or B-structures. The intra-BC unit 48 can determine vectors, for example, block vectors, for intra-BC encoding in a manner similar to the determination of motion vectors by the motion estimation unit 42 for inter-prediction, or it can use the motion estimation unit 42 to determine the block vector. A predictive block is a block in a reference structure that is considered to precisely match the PU of the video block to be encoded in terms of pixel difference, which can be determined by sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some implementations, the video encoder 20 can compute values ​​for non-integer pixel positions from reference structures stored in DPB 64. For example, the video encoder 20 can interpolate values ​​for quarter-pixel positions, eighth-pixel positions, and other fractional pixel positions in the reference structure. Consequently, the motion estimation unit 42 can perform a motion search relative to whole-pixel and fractional-pixel positions and output a motion vector with fractional-pixel accuracy. The motion estimation unit 42 calculates a motion vector for a PU of a video block in an inter-prediction encoded structure by comparing the position of the PU with respect to the position of a predictive block of a reference structure selected from a first reference structure list (List 0) or a second reference structure list (List 1), each of which identifies one or more reference structures stored in DPB 64. The motion estimation unit 42 sends the calculated motion vector to the motion compensation unit 44 and then to the entropy encoding unit 56. Motion compensation, performed by motion compensation unit 44, can involve capturing or generating the predictive block based on the motion vector determined by motion estimation unit 42. After receiving the motion vector for the current video block's PU, motion compensation unit 44 can locate a predictive block pointed to by the motion vector in one of the reference structure lists, retrieve the predictive block from DPB 64, and send the predictive block to summing device 50. Summing device 50 then forms a residual video block of pixel difference values ​​by subtracting the pixel values ​​of the predictive block, provided by motion compensation unit 44, from the pixel values ​​of the current video block being encoded.The pixel difference values ​​that make up the residual video block can include luma or chroma difference components, or both. The motion compensation unit 44 can also generate syntax elements associated with the video blocks of a video structure for use by the video decoder 30 in decoding the video blocks of the video structure. Syntax elements can include, for example, syntax elements that define the motion vector used to identify the predictive block, indicating any prediction mode indicator, or any other syntax information described herein. It is mentioned that the motion estimation unit 42 and the motion compensation unit 44 can be extensively integrated, but they are illustrated separately for conceptual purposes. In some implementations, the BC 48 intra unit can generate capture predictive vectors and blocks in a manner similar to that described above in connection with the motion estimation unit 42 and the motion compensation unit 44, but with the predictive blocks located in the same structure as the current block being encoded and with the vectors referred to as block vectors, as opposed to motion vectors. Specifically, the BC 48 intra unit can determine an intra-prediction mode that uses the encoding of a current block. In some examples, the BC 48 intra unit can encode a current block using various intra-prediction modes, for example, during separate encoding steps, and evaluate its performance through velocity distortion analysis.Next, the BC 48 intra unit can select, from among the various evaluated intra-prediction modes, a suitable mode to use and generate an intra-mode indicator accordingly. For example, the BC 48 intra unit can calculate rate distortion values ​​using a rate distortion analysis for the various evaluated intra-prediction modes and select the mode with the best rate distortion characteristics as the appropriate mode to use. Generally, the rate distortion analysis determines the amount of distortion (or error) between a coded block and the original, uncoded block that was encoded to produce the coded block, as well as the bit transfer rate (i.e., the number of bits) used to produce the coded block.The BC 48 intra unit can calculate indices from distortions and speeds of the various encoded blocks in order to determine which intra prediction mode exhibits the best speed-distortion value for the block. In other examples, the intra-BC unit 48 may use the motion estimation unit 42 and motion compensation unit 44, in whole or in part, to perform such intra-BC prediction functions according to the implementations described herein. In any case, for intra-block copying, a predictive block may be a block that is considered to be an exact match to the block to be encoded, in terms of pixel differences, which may be determined by the sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. The identification of the predictive block may include calculating values ​​for pixel positions less than an integer. If the predictive block is of the same structure within the prediction, or a different structure within the prediction, the video encoder 20 can form a residual video block by subtracting pixel values ​​from the predictive block from the pixel values ​​of the current video block being encoded, forming pixel difference values. The pixel difference values ​​that form the residual video block can include differences in both luma and chroma components. The intra-prediction processing unit 46 can intra-predict a current video block, as an alternative to the inter-prediction performed by the motion estimation unit 42 and the motion compensation unit 44, or the intra-block copy prediction performed by the intra-BC unit 48, as described above. In particular, the intra-prediction processing unit 46 can determine an intra-prediction mode to be used in encoding a current block. To do this, the intra-prediction processing unit 46 can encode a current block using various intra-prediction modes, for example, during separate encoding steps, and the intra-prediction processing unit 46 (or a mode selection unit, in some examples) can select a suitable intra-prediction mode to use from the evaluated intra-prediction modes.The intra-prediction processing unit 46 can provide information indicative of the selected intra-prediction mode for the entropy-coding unit block 56. The entropy-coding unit 56 can encode the information indicating the selected intra-prediction mode in the bit stream. After the prediction processing unit 41 determines the predictive block for the current video block, either through inter-prediction or intra-prediction, the summing device 50 forms a residual video block by subtracting the predictive video block from the current video block. The residual video data in the residual block can be included in one or more transformation units (TUs) and is provided to the transformation processing unit 52. The transformation processing unit 52 transforms the residual video data into residual transformation coefficients using a transformation, such as a discrete cosine transform (DCT) or a conceptually similar transformation. The transformation processing unit 52 can send the resulting transformation coefficients to the quantization unit 54. The quantization unit 54 quantizes the transformation coefficients to further reduce the bit transfer 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 a quantization parameter. In some examples, the quantization unit 54 can then perform a scan of an array that includes the quantized transformation coefficients. Alternatively, the entropy coding unit 56 can perform the scan. After quantization, the entropy coding unit 56 entropy-encodes the quantized transformation coefficients into a video bitstream using, for example, context-adaptive variable-length encoding (CAVLC), context-adaptive binary arithmetic (CABAC), syntax-based context-adaptive binary arithmetic (SBAC), probability interval division entropy (PIPE), or another entropy-coding methodology or technique. The encoded bitstream can then be transmitted to the video decoder 30 or archived to the storage device 32 for later transmission or retrieval by the video decoder 30. The entropy coding unit 56 can also entropy-encode motion vectors and other syntax elements for the current video structure being encoded. The inverse quantization unit 58 and the inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain for generating a reference block for predicting other video blocks. As mentioned above, the motion compensation unit 44 can generate a motion-compensated predictive block from one or more reference blocks of the structures stored in DPB 64. The motion compensation unit 44 can also apply one or more interpolation filters to the predictive block to calculate sub-integer pixel values ​​for use in motion estimation. The summing device 62 adds the reconstructed residual block to the motion-compensated predictive block, produced by the motion compensation unit 44, to produce a reference block for storage in DPB 64. The reference block can then be used by the intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 as a predictive block to interpredict another video block in a subsequent video structure. Figure 3 is a block diagram illustrating an exemplary video decoder 30 according to some implementations of the present application. The video decoder 30 includes video data memory 79, entropy decoding unit 80, prediction processing unit 81, inverse quantization unit 86, inverse transform processing unit 88, summing device 90, and DPB 92. The prediction processing unit 81 further includes motion compensation unit 82, intra-prediction unit 84, and intra-BC unit 85. The video decoder 30 can perform a decoding process that is generally the reciprocal of the encoding process described above with respect to the video encoder 20 in connection with Figure 2.For example, the motion compensation unit 82 can generate prediction data based on motion vectors received from the entropy decoding unit 80, while the intra-prediction unit 84 can generate prediction data based on intra-prediction mode indicators received from the entropy decoding unit 80. In some examples, a single video decoder unit 30 may be assigned the task of carrying out the implementations described herein. Also, in some examples, the implementations described herein may be divided among one or more units of the video decoder 30. For example, the intra unit BC 85 may carry out the implementations described herein, either alone or in combination with other video decoder units 30, such as the motion compensation unit 82, intra prediction unit 84, and entropy decoding unit 80. In some examples, the video decoder 30 may not include the intra unit BC 85, and the functionality of the intra unit BC 85 may be carried out by other components of the prediction processing unit 81, such as the motion compensation unit 82. Video data memory 79 can store video data, such as an encoded video bitstream, to be decoded by the other components of video decoder 30. The video data stored in video data memory 79 can be obtained, for example, from storage device 32, from a local video source such as a camera, via wireless or wired video data network communication, or by accessing a physical data storage medium (for example, a flash memory unit or hard drive). Video data memory 79 can include a coded picture buffer (CPB) that stores encoded video data from an encoded video bitstream.The decoded picture buffer (DPB) 92 of video decoder 30 stores reference video data for use in decoding video data by video decoder 30 (for example, in intra- or inter-predictive coding modes). The video data buffer 79 and DPB 92 can be formed by any of a variety of memory devices, such as dynamic random-access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data buffer 79 and DPB 92 are shown as two separate components of video decoder 30 in Figure 3. However, it will be apparent to someone skilled in the art that the video data buffer 79 and DPB 92 can be provided by the same memory device or by separate memory devices.In some examples, the video data memory 79 may be located on the chip with other video decoder components 30, or off the chip in relation to those components. During the decoding process, video decoder 30 receives a stream of encoded video bits, representing video blocks from an encoded video structure and associated syntax elements. Video decoder 30 can receive the syntax elements at the video structure level and / or at the video block level. The entropy decoding unit 80 of video decoder 30 entropy-decodes the bit stream to generate quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. The entropy decoding unit 80 then sends the motion vectors and other syntax elements to the prediction processing unit 81. When the video structure is encoded as an intra-predictive encoded structure (I) or for intra-encoded predictive blocks in other types of structures, the intra-prediction unit 84 of the prediction processing unit 81 can generate prediction data for a video block of the current video structure based on a specified intra-prediction mode and reference data from previously decoded blocks of the current structure. When the video structure is encoded as an inter-predictive encoded structure (i.e., B or P), the motion compensation unit 82 of the processing unit by prediction 81 produces one or more predictive blocks for a video block of the current video structure based on the motion vectors and other syntax elements received from the entropy decoding unit 80. Each of the predictive blocks can be produced from a reference structure within one of the reference structure lists. The video decoder 30 can construct the reference structure lists, List 0 and List 1, using default construction techniques based on reference structures stored in DPB 92. In some examples, when the video block is encoded according to the intra BC mode described herein, the intra BC unit 85 of the prediction processing unit 81 produces predictive blocks for the current video block based on block vectors and other syntax elements received from the entropy decoding unit 80. The predictive blocks can be found within a reconstructed region of the same image as the current video block, defined by the video encoder 20. The motion compensation unit 82 and / or intra BC unit 85 determines prediction information for a video block from the current video structure by syntactic analysis of motion vectors and other syntax elements, and then uses the prediction information to produce the predictive blocks for the current video block being decoded.For example, the motion compensation unit 82 uses some of the received syntax elements in order to determine a prediction mode (e.g., intra or inter prediction) used to encode video blocks of the video structure, an inter prediction structure type (e.g., B or P), construction information for one or more of the reference structure lists for the structure, motion vectors for each encoded, inter predictive video block of the structure, inter prediction state for each encoded, inter predictive video block of the structure, and other information for decoding the video blocks in the current video structure. Similarly, the intra BC 85 unit can use some of the received syntax elements, for example, a flag, to determine that the current video block was predicted using intra BC mode, construction information of which the video blocks of the structure are within the reconstructed region and should be stored in the DPB 92, block vectors for each intra BC predicted video block of the structure, intra BC prediction state for each intra BC predicted video block of the structure, and other information to decode the video blocks in the current video structure. Motion compensation unit 82 can also perform interpolation using the interpolation filters employed by video encoder 20 during video block encoding to calculate interpolated values ​​for pixels smaller than integer in the reference blocks. In this case, motion compensation unit 82 can determine the interpolation filters used by video encoder 20 from the received syntax elements and use those filters to produce predictive blocks. The inverse quantization unit 86 inversely quantizes the quantized transformation coefficients, provided in the bitstream and entropy-decoded by the entropy decoding unit 80, which uses the same quantization parameter calculated by the video encoder 20 for each video block in the video structure, in order to determine a degree of quantization. The inverse transformation processing unit 88 applies an inverse transformation, for example, an inverse DCT, an inverse integer transformation, or a conceptually similar inverse transformation process, to the transformation coefficients in order to reconstruct the remaining blocks in the pixel domain. After the motion compensation unit 82 or intra-BC unit 85 generates the predictive block for the current video block based on the vectors and other syntax elements, the summing device 90 reconstructs the decoded video block for the current video block by summing the residual block from the inverse transform processing unit 88 and a corresponding predictive block generated by the motion compensation unit 82 and intra-BC unit 85. A loop filter (not illustrated) can be placed between the summing device 90 and DPB 92 for further processing of the decoded video block. The decoded video blocks in a given structure are then stored in DPB 92, which stores reference structures used for subsequent motion compensation of the following video blocks.The DPB 92, or a separate memory device from the DPB 92, can also store decoded video for later display on a display device, such as display device 34 in FIGURE 1. In a typical video encoding process, a video sequence typically includes an ordered set of frames or images. Each frame may include three sample arrays, denoted as SL, SCb, and SCr. SL is a two-dimensional array of chroma samples. SCb is a two-dimensional array of chroma samples. SCr is a two-dimensional array of chroma samples. In other cases, a frame may be monochromatic and therefore include only a two-dimensional array of luma samples. As shown in FIGURE 4A, the video encoder 20 (or more specifically, the splitting unit 45) generates an encoded representation of a structure by first splitting the structure into a set of encoding tree units (CTUs). A video structure can include any number of CTUs arranged sequentially on a frame scanner, from left to right and top to bottom. Each CTU is the largest logical encoding unit, and the width and height of the CTU are specified by the video encoder 20 in a set of sequence parameters, such that all CTUs in a video sequence are the same size, corresponding to 128x128, 64x64, 32x32, and 16x16. However, it should be noted that the present application is not necessarily limited to any particular size.As shown in FIGURE 4B, each CTU can comprise one luma sample coding tree block (CTB), two corresponding chroma sample coding tree blocks, and syntax elements used to encode the samples in the coding tree blocks. The syntax elements describe properties of different unit types within a pixel coded block and how the video sequence can be reconstructed in the video decoder, including inter- or intra-prediction, intra-prediction mode, motion vectors, and other parameters. In monochrome images or images with three separate color planes, a CTU can comprise a single coding tree block and syntax elements used to encode the samples in the coding tree block. A coding tree block can be an NxN sample block. To achieve improved performance, the video encoder 20 can recursively perform tree splitting, such as binary tree splitting, ternary tree splitting, quad tree splitting, or a combination thereof, on the CTU's encoding tree blocks and divide the CTU into smaller encoding units (CUs). As illustrated in Figure 4C, the 64x64 CTU 400 is first split into four smaller CUs, each with a block size of 32x32. Among the four smaller CUs, CU 410 and CU 420 are each split into four 16x16 CUs by block size. The two 16x16 CUs 430 and 440 are further each split into four 8x8 CUs by block size.Figure 4D illustrates a quad-tree data structure that illustrates the final result of the CTU 400 splitting process illustrated in Figure 4C, with each leaf node of the corresponding quad-tree varying to a CU of a respective size from 32x32 to 8x8. Like the CTU illustrated in Figure 4B, each CU may comprise one luma sample encoding block (BC) and two corresponding chroma sample encoding blocks of the same size, and syntax elements used to encode the samples in the encoding blocks. In monochrome images or images having three separate color planes, a CU may comprise a single encoding block and syntax structures used to encode the samples in the encoding block.It should be mentioned that the quad tree split illustrated in FIGURES 4C and 4D is for illustrative purposes only, and a CTU can be split into CUs to suit varying local characteristics, based on quad / ternary / binary tree splits. In the multi-type tree structure, a CTU is split by a quad tree structure, and each quad tree leaf CU can be further split into a binary and ternary tree structure. As shown in FIGURE 4E, there are five types of splitting: quad tree split, horizontal binary split, vertical binary split, horizontal ternary split, and vertical ternary split. In some implementations, the Video Encoder 20 can further divide a CU's encoding block into one or more MxN prediction blocks (PBs). A prediction block is a rectangular (square or non-square) block of samples to which the same, inter- or intra-prediction is applied. A prediction unit (PU) in a CU can comprise a luma sample prediction block, two corresponding chroma sample prediction blocks, and syntax elements used to predict the prediction blocks. In monochrome images or images with three separate color planes, a PU can comprise a single prediction block and syntax structures used to predict the prediction block. The Video Encoder 20 can generate luma predictive blocks, Cb and Cr for luma, and Cb and Cr prediction blocks for each PU in the CU. The video encoder 20 can use intra-prediction or inter-prediction to generate the predictive blocks for a PU. If the video encoder 20 uses intra-prediction to generate the predictive blocks for a PU, it can generate the PU's predictive blocks based on decoded samples of the structure associated with the PU. If the video encoder nznz Ln / zznz / E / YiAi uses inter-prediction to generate the predictive blocks for a PU, it can generate the PU's predictive blocks based on decoded samples of one or more structures other than the structure associated with the PU. After the video encoder 20 generates predictive luma blocks, Cb and Cr, for one or more PUs of a CU, the video encoder 20 can generate a luma residual block for the CU by subtracting the predictive luma blocks of the CU from its original luma encoding block, such that each sample in the luma residual block of the CU indicates a difference between a luma sample in one of the predictive luma blocks of the CU and a corresponding sample in the original luma encoding block of the CU.Similarly, the video encoder 20 can generate a Cb residual block and a Cr residual block for the CU, respectively, such that each sample in the CU's Cb residual block indicates a difference between a Cb sample in one of the CU's predictive Cb blocks and a corresponding sample in the CU's original Cb encoding block, and each sample in the CU's Cr residual block can indicate a difference between a Cr sample in one of the CU's predictive Cr blocks and a corresponding sample in the CU's original Cr encoding block. Furthermore, as illustrated in FIGURE 4C, the video encoder 20 can use quad tree splitting to decompose the luma, Cb, and Cr residual blocks of a CU into one or more luma, Cb, and Cr transform blocks. A transform block is a rectangular (square or non-square) block of samples to which the same transformation is applied. A transform unit (TU) of a CU can comprise a luma sample transform block, two corresponding chroma sample transform blocks, and syntax elements used to transform the transform block samples. Thus, each TU of a CU can be associated with a luma transform block, a Cb transform block, and a Cr transform block. In some examples, the luma transform block associated with the TU can be a sub-block of the CU's luma residual block.The Cb transformation block can be a sub-block of the Cb residual block of the CU. The Cr transformation block can be a sub-block of the Cr residual block of the CU. In monochrome images or images that have three separate color planes, a TU can comprise a single transformation block and syntax structures used to transform the samples within the transformation block. The video encoder 20 can apply one or more transformations to a luma transformation block of a TU to generate a luma coefficient block for the TU. A luma coefficient block can be a two-dimensional array of transformation coefficients. A transformation coefficient can be a scalar quantity. The video encoder 20 can apply one or more transformations to a Cb transformation block of a TU to generate a Cb coefficient block for the TU. The video encoder 20 can apply one or more transformations to a Cr transformation block of a TU to generate a Cr coefficient block for the TU. After generating a coefficient block (for example, a luma coefficient block, a Cb coefficient block, or a Cr coefficient block), the Video Encoder 20 can quantize the coefficient block. Generally, quantization refers to a process in which the transformation coefficients are quantized to potentially reduce the amount of data used to represent the transformation coefficients, providing additional compression. After the Video Encoder 20 quantizes a coefficient block, it can entropy-encode the syntax elements that indicate the quantized transformation coefficients. For example, the Video Encoder 20 can perform Context Adaptive Binary Arithmetic Coding (CABAC) on the syntax elements that indicate the quantized transformation coefficients.Finally, the video encoder 20 can output a bitstream that includes a bit sequence that forms a representation of encoded structures and associated data, which is either stored on the storage device 32 or transmitted to the destination device 14. After receiving a bitstream generated by video encoder 20, video decoder 30 can parse the bitstream to extract syntax elements. Video decoder 30 can then reconstruct the video data structures based on at least some of the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally the reciprocal of the encoding process performed by video encoder 20. For example, video decoder 30 can perform inverse transformations on the coefficient blocks associated with the TUs of a current CU to reconstruct residual blocks associated with the TUs of the current CU.The video decoder 30 also reconstructs the encoding blocks of the current CU by adding samples from the predictive blocks for PUs of the current CU to corresponding samples from the transformation blocks of the TUs of the current CU. After reconstructing the encoding blocks for each CU of a structure, the video decoder 30 can reconstruct the structure. As mentioned above, video coding achieves video compression using two basic modes: intra-structure prediction (or intra-prediction) and inter-structure prediction (or inter-prediction). Palette-based coding is another coding scheme adopted by many video coding standards. In palette-based coding, which can be particularly suitable for encoding screen-generated content, a video encoder (e.g., video encoder 20 or video decoder 30) creates a palette table of colors representing the video data of a given block. The palette table includes the most dominant (e.g., frequently used) pixel values ​​in the given block. Pixel values ​​that are not frequently represented in the video data of the given block are either not included in the palette table or are included as escape colors. Each entry in the palette table includes an index to a corresponding pixel value found in the palette table. The palette indices for samples within the block can be encoded to indicate which palette table entry is to be used to predict or reconstruct that sample. This palette mode begins with the process of generating a palette predictor for the first block of an image, slice, mosaic, or other such grouping of video blocks. As will be explained below, the palette predictor for subsequent video blocks is typically generated by updating a previously used palette predictor. For illustrative purposes, it is assumed that the palette predictor nznz Ln / zznz / E / YiAi is defined at the image level. In other words, an image may include multiple encoding blocks, each having its own palette table, but there is one palette predictor for the entire image. To reduce the number of bits required for signaling palette entries in the video bitstream, a video decoder can use a palette predictor to determine new palette entries in the palette table used to reconstruct a video block. For example, the palette predictor might include palette entries from a previously used palette table or even start with the most recently used palette table by including all the entries from that table. In some implementations, the palette predictor might include fewer entries from the entire most recently used palette table and then incorporate some entries from other previously used palette tables.The palette predictor can be the same size as the palette tables used for encoding different blocks, or it can be larger or smaller than the palette tables used for encoding different blocks. In one example, the palette predictor is implemented as a first-in, first-out (FIFO) table that includes 64 palette entries. In order to generate a palette table for a block of video data from the palette predictor, a video decoder can receive, from the encoded video bitstream, a one-bit flag for each palette predictor entry. The one-bit flag can have a first value (for example, a binary one) indicating that the associated palette predictor entry is to be included in the palette table, or a second value (for example, a binary zero) indicating that the associated palette predictor entry is not to be included in the palette table. If the size of the palette predictor is larger than the palette table used for a block of video data, then the video decoder can stop receiving more flags once a maximum size for the palette table is reached. In some implementations, certain entries in a palette table can be pointed directly to in the encoded video bitstream, rather than determined using the palette predictor. For such entries, the video decoder can receive, from the encoded video bitstream, three separate m-bit values ​​indicating the pixel values ​​for the luma and two chroma components associated with the input, where m represents the bit depth of the video data. Compared to the multiple m-bit values ​​required to directly point to palette entries, those palette entries derived from the palette predictor require only a single bit pointer.Therefore, signaling some or all of the palette inputs using the palette predictor can significantly reduce the number of bits needed to signal the inputs of a new palette table, thus improving the overall encoding efficiency of palette-mode coding. In many cases, the palette predictor for a block is determined based on the palette table used to encode one or more previously encoded blocks. However, when the first encoding tree unit is encoded in an image, slice, or mosaic, the palette table for a previously encoded block may not be available. Consequently, a palette predictor nznz ίη / ζζηζ / E / γίΛΐ cannot be generated using entries from previously used palette tables. In such a case, a sequence of palette predictor initializers can be specified in a sequence parameter set (SPS) and / or an image parameter set (PPS), which are values ​​used to generate a palette predictor when a previously used palette table is unavailable.A Syntax Structure (SPS) generally refers to a syntax structure or syntax elements that apply to a series of consecutive, encoded video images, called an Encoded Video Sequence (CVS), as determined by the content of a syntax element found in the PPS referenced by a syntax element found in each cut segment header. A PPS generally refers to a syntax structure of syntax elements that apply to one or more individual images within a CVS, as determined by a syntax element found in each cut segment header. Therefore, an SPS is generally considered a higher-level syntax structure than a PPS, meaning that the syntax elements included in the SPS typically change less frequently and apply to a larger portion of video data compared to the syntax elements included in the PPS. Figures 5A to 5B are block diagrams that illustrate examples of using palette tables for video data encoding according to some implementations of the present description. For palette mode (PLT) signaling, the palette mode is encoded as a prediction mode for an encoding unit; that is, the prediction modes for an encoding unit can be MODEJNTRA, MODEJNTER, MODEJBC, and MODE_PLT. If palette mode is used, the pixel values ​​in the encoding unit are represented by a small set of representative colors. This set is referred to as the palette. For pixels with values ​​close to the palette colors, palette indices are signaled. For pixels with values ​​outside the palette, the pixels are indicated with an escape symbol, and the quantized pixel values ​​are signaled directly. The syntax and associated semantics of palette mode in a current WC draft specification are illustrated in Table 1 and Table 2 below, respectively. To decode a block encoded in palette mode, the decoder needs to decode the palette colors and bitstream indices. The palette colors are defined by a palette table and encoded using the palette table's encoding syntax (for example, palette_predictor_run, num_signaled_palette_entries, new_palette_entries). An escape flag, `palette escape val present flag`, is set for each CU to indicate whether escape symbols are present in the current CU. If escape symbols are present, the palette table is incremented by one or more entries, and the last index is assigned to escape mode. The palette indices of all pixels in a CU form a palette index map and are encoded by the palette index map encoding syntax (e.g., num_palette_indices_minus1, palettejdxjdc, copy_above_indices_for_final_run_flag, palette_transpose_flag, copy_above_palette_indices_flag, palette_run_prefix, palette_run_suffix).An example of a palette-encoded CU is illustrated in Figure 5A, in which the palette size is 4. The first three samples in the CU use palette inputs 2, 0, and 3, respectively, for reconstruction. Sample “x” in the CU represents an escape symbol. A CU level indicator, palette_escape_val_present_flag, indicates whether any escape symbols are present in the CU. If escape symbols are present, the palette size is increased by one, and the last index is used to indicate the escape symbol. Therefore, in Figure 5A, index 4 is assigned to the escape symbol. If a palette index (e.g., index 4 in FIGURE 5A) corresponds to the escape symbol, an additional heading is noted to indicate the corresponding sample colors. In some modes, on the encoding side, it is necessary to derive a suitable palette for use with the CU. For palette derivation for lossy encoding, a modified k-means grouping algorithm is used. The first sample in the block is added to the palette. Then, for each subsequent sample in the block, the sum of the absolute differences (SADs) between the sample and each of the colors in the current palette is calculated. If the distortion of each component is less than a threshold value for the palette input corresponding to the minimum SAD, the sample is added to the group belonging to that palette input. Otherwise, the sample is added to a new palette input. When the number of samples graphically represented in a group exceeds a threshold, a centroid for that group is updated and becomes the palette input for that group. In the next stage, the groups are sorted in descending order of use. Then, the palette entry corresponding to each entry is updated. Normally, the group's centroid is used as the palette entry. However, a rate distortion analysis is performed to determine if any input from the palette predictor might be more suitable as the updated palette entry instead of the centroid, considering the encoding cost of the palette entries. This process continues until all groups are processed or the maximum palette size is reached. Finally, if a group has only one sample and the corresponding palette entry is not found in the palette predictor, the sample is converted to an escape symbol. Additionally, duplicate palette entries are removed, and their groups are merged. After palette derivation, each sample in the block is assigned the index of the nearest palette entry (in SAD). The samples are then assigned to either 'INDEX' or 'COPYABOVE' mode. For each sample that can use either 'INDEX' or 'COPYABOVE' mode, the step size for each mode is determined. The encoding cost for each mode is then calculated. The mode with the lowest cost is selected. For palette table encoding, a palette predictor is maintained. The maximum palette size and the maximum palette predictor size can both be signaled in the SPS (or other encoding levels such as PPS, slice header, etc.). The palette predictor is run at the beginning of each slice, where it is reset to 0. For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette. As shown in Figure 5B, the reuse flags, palette_predictor_run, are sent. After this, the number of new palette entries is signaled using exponential Golomb code of order 0 through the syntax num_signaled_palette_entries. Finally, the component values ​​for the new palette entries are signaled, new_palette_entries[].After the current CU is encoded, the palette predictor is updated using the current palette, and the entries from the previous palette predictor that were not reused in the current palette will be added to the end of the new palette predictor until the maximum allowed size is reached. For encoding the palette index map, the indices are encoded using horizontal or vertical traverse scans, as shown in Figure 5C. The scan order is explicitly indicated in the bitstream that uses the palette_transpose_flag. Palette indices are encoded using two main palette sampling modes: 'INDEX' and 'COPYABOVE'. In 'INDEX' mode, the palette index is explicitly referenced. In 'COPYABOVE' mode, the palette index is copied from the sample in the previous row. For both 'INDEX' and 'COPYABOVE' modes, a step value is specified, indicating the number of pixels encoded using that mode. The mode is indicated by a flag, except for the top row when using horizontal scanning, the first column when using vertical scanning, or when the previous mode was 'COPYABOVE'. In some modes, the encoding order for the index map is as follows: First, the number of index values ​​for the CU is specified using the syntax num_paletteindices_minus1, followed by the actual index values ​​for the entire CU being specified using the syntax paletteidxidc. Both the number of indices and the index values ​​are encoded in offset mode. This groups together the offset-encoded intervals related to the index. Then, the palette mode (INDEX or COPY_ABOVE) and the step are specified in an interleaved manner using the syntax copy_above_palette_indices_flag, palette_run_prefix, and palette_run_suffix. copy_above_palette_indices_flag is a context-coded flag (only a binary value), palette_run_prefix passwords are determined through the process described in Table 3 below and the first 5 binary values ​​are context-coded.`palette_run_suffix` is encoded as a binary bypass value. Finally, the component escape values ​​corresponding to the entire CU escape samples are grouped together and encoded in bypass mode. An additional syntax element, `copy_above_indices_for_final_run_flag`, is noted after the index values ​​are noted. This syntax element, in conjunction with the index number, eliminates the need to note the step value corresponding to the last step in the block. In the VVC (VTM), the dual tree is enabled for 1-cut, which separates the encoding unit division for luma and chroma components. As a result, the palette is applied to luma (Y component) and chroma (Cb and Cr components) separately. If the dual tree is disabled, the palette will be applied to the Y, Cb, and Cr components together. nznz Ln / zznz / E / YiAi Table 1 Palette Encoding Syntax palette_coding( xO, yO, cbWidth, cbHeight, startComp, numComps ) { Descriptor palettePredictionFinished = 0 NumPredictedPaletteEntries = 0 for( predictorEntryldx = 0; predictorEntryldx < PredictorPaletteSize[ startComp ] && IpalettePredictionFinished && NumPredictedPaletteEntries[ startComp ] < palette_max_size; predictorEntryldx++ ) { palette_predictor_run ae(v) if( palette_predictor_run != 1 ) { if( palette_predictor_run > 1 ) predictorEntryldx += palette_predictor_run - 1 PalettePredictorEntryReuseFlags[ predictorEntryldx ] = 1 NumPredictedPaletteEntries++} else palettePredictionFinished = 1} if( NumPredictedPaletteEntries < palette_max_size ) num_signaled_palette_entries ae(v) for( cldx = startComp; cldx < ( startComp + numComps); cldx++ ) for( i = 0; i < num_signaled_palette_entries;Í++ ) new_palette_entries[ cldx ][ i ] ae(v) if( CurrentPaletteSize[ startComp ] > 0 ) paletteescapevalpresentflag ae(v) if( MaxPalettelndex > 0 ) { n u m_palette_ind ices_m i n us 1 ae(v) adjust = 0 for( i = 0; i <= num_palette_indices_minus1; i++ ) { if( MaxPalettelndex - adjust > 0 ) { palettejdxjdc ae(v) Palettelndexldc[ i ] = palettejdxjdc} adjust = 1} copy above Índices for final run flag ae(v) palette_transpose_flag ae(v)} if( treeType != DUAL_TREE_CHROMA && palette_escape_val_present_flag ){ if( cu_qp_delta_enabled_flag && HsCuQpDeltaCoded ) { cu_qp_delta_abs ae(v) if( cu_qp_delta_abs ) cu_qp_delta_sign_flag ae(v)}}; nznz ίη / ζζηζ / Ε / γίΛΐ if( treeType != DUAL_TREE_LUMA && palette_escape_val_present_flag ) { if( cuchromaqpoffsetenabledflag && lIsCuChromaQpOffsetCoded ) { cuchromaqpoffsetflag ae(v) if( cuchromaqpoffsetflag ) cu_chroma_qp_offset_idx ae(v)}} remainingNumlndices = num_palette_¡nd¡ces_m¡nus1 + 1 PaletteScanPos = 0 log2CbWidth = Log2( cbWidth ) log2CbHeight = Log2( cbHeight) while( PaletteScanPos < cbWidth*cbHeightt) { xC = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 0 ] yC = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 1 ] if( PaletteScanPos > 0 ) { xcPrev = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 0 ] ycPrev = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 1 ]} PaletteRunMinusI = cbWidth * cbHeight - PaletteScanPos - 1 RunToEnd = 1 CopyAbovelndicesFlag[ xC ][ yC ] = 0 if( MaxPalettelndex > 0 ) if( (( !palette_transpose_flag && yC > 0 ) | | ( palette_transpose_flag && xC > 0 )) &&CopyAbovelndicesFlag[ xcPrev ][ ycPrev ] == 0) if( remainingNumlndices > 0 && PaletteScanPos < cbWidth* cbHeight - 1 ){ co py_a bove_pa I ette_¡ nd ices_f I ag ae(v) CopyAbovelndicesFlag[ xC ][ yC ] = copy_above_palette_indices_flag} else { if( PaletteScanPos = = cbWidth * cbHeight - 1 && remainingNumlndices > 0) CopyAbovelndicesFlag[ xC ][ yC ] = 0 else CopyAbovelndicesFlag[ xC ][ yC ] = 1} if ( CopyAbovelndicesFlag[ xC ][ yC ] == 0){ currNumlndices = num_palette_indices_minus1 + 1 - remainingNumlndices ηζηζ ίη / ζζηζ / Ε / γίΛΐ PalettelndexMap[ xC ][ yC ] = Palettelndexldc[ currNumlndices ]} if( MaxPalettelndex > 0 ) { if( CopyAbovelndicesFlag[xC ][ yC ] == 0) remainingNumlndices - = 1 if( remainingNumlndices > 0 || CopyAbovelndicesFlag[ xC ][ yC ] != copy_above_indices_for_f¡nal_run_flag ) { PaletteMaxRunMinusI = cbWidth * cbHeight - PaletteScanPos - 1 remainingNumlndices - copy_above_indices_for_final_run_flag RunToEnd = 0 if( PaletteMaxRunMinusI > 0 ) { palette_run_prefix ae(v) if( ( palette_run_prefix > 1 ) && (PaletteMaxRunMinusI != ( 1 « ( palette_run_prefix - 1 )))) palette_run_suffix ae(v)}}} runPos = 0 while (runPos <- PaletteRunMinusI ) { xR = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 0 ] yR = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 1 ] if( CopyAbovelndicesFlag[xC ][ yC ] == 0){ CopyAbovelndicesFlag[ xR ][ yR ] = 0 PalettelndexMap[ xR ][ yR ] - PalettelndexMap[ xC ][ yC ]} else { CopyAbovelndicesFlag[ xR ][ yR ] = 1 if(!palette_transpose_flag ) PalettelndexMap[ xR ][ yR ] = PalettelndexMap[ xR ][ yR - 1 ] else PalettelndexMap[ xR ][ yR ] = PalettelndexMap[ xR - 1 ][ yR ]} runPos++ PaletteScanPos ++}} if( palette_escape_val_present_flag) { for( cldx = startComp; cldx < ( startComp + numComps ); cldx++ ) for( sPos = 0; sPos < cbWidth* cbHeight; sPos++ ) { xC - xO + TraverseScanOrder[ log2CbWidth][ log2CbHeight ][ sPos ][ 0 ] ηζηζ ίη / ζζηζ / Ε / γίΛΐ yC = yO + TraverseScanOrder[ log2CbWidth][ log2CbHeight ][ sPos ][ 1 ] if( PalettelndexMap[ cldx ][ xC ][ yC ] = = MaxPalettelndex ) { palette_escape_val ae(v) PaletteEscapeVal[ cldx ][ xC ][ yC ] = palette escape val}}}} nznz Ln / zznz / E / YiAi Tabla 2 Semantics of palette codification In subsequent semantics, the array indices xO, yO specify the location (xO, yO) of the upper-left luma sample of the encoding block in question relative to the upper-left luma sample of the image. The array indices xC, yC specify the location (xC, yC) of the sample relative to the upper-left luma sample of the image. The array index startComp specifies the first color component in the current palette table. startComp equal to 0 indicates the Y component; startComp equal to 1 indicates the Cb component; startComp equal to 2 indicates the Cr component. numComps specifies the number of color components in the current palette table. The palette predictor consists of palette inputs from previous encoding units that are used to predict inputs in the current palette. The variable PredictorPaletteSize[startComp] specifies the size of the palette predictor for the first color component of the current palette table, startComp. Setting the variable PalettePredictorEntryReuseFlags[i] to 1 specifies that the i-th entry in the palette predictor is reused in the current palette. Setting PalettePredictorEntryReuseFlags[i] to 0 specifies that the i-th entry in the palette predictor is not an entry in the current palette. All elements of the array PalettePredictorEntryReuseFlags[i] are set to 0. palette_predictor_run is used to determine the number of zeros preceding the non-zero entry in the PalettePredictorEntryReuseFlags array. It is a bitstream compliance requirement that the value of palette_predictor_run must be in the range of 0 to (PredictorPaletteSize - predictorEntryldx), inclusive, where predictorEntryldx corresponds to the current position in the PalettePredictorEntryReuseFlags array. The variable NumPredictedPaletteEntries specifies the number of entries in the current palette that are reused from the predictor palette. The value of NumPredictedPaletteEntries must be in the range of 0 to palette_max_size, inclusive. num_signaled_palette_entries specifies the number of entries in the current palette that are explicitly signaled for the first color component of the current palette table startComp. When there are no num signaled palette entries, it is deduced that it is equal to 0. The variable CurrentPaletteSize[startComp] specifies the current palette size for the first color component of the current palette table startComp and is derived as follows: CurrentPaletteSize[ startComp ] = NumPredictedPaletteEntries + num_signaled_palette_entries The value of CurrentPaletteSize[ startComp ] must be in the range of 0 to palette max size, inclusive. new_palette_entries[ cldx ][ i ] specifies the value for the ith palette entry pointed to for color component cldx. The variable PredictorPaletteEntries[ cldx ][ i ] specifies the ith element in the predictor palette for the color component cldx. The variable CurrentPaletteEntries[ cldx ][ i ] specifies the ith element in the current palette for the color component cldx and is derived as follows: numPredictedPaletteEntries = 0 for( i = 0; i < PredictorPaletteSize[ startComp ]; i++ ) if( PalettePredictorEntryReuseFlags[ i ]) { for( cldx =startComp; cldx < ( startComp + numComps ); cldx++ ) CurrentPaletteEntries[ cldx ][ numPredictedPaletteEntries ] = PredictorPaletteEntries[ cldx ][ i ] numPredictedPaletteEntries++} for( cldx = startComp; cldx < (startComp + numComps); cldx++) for( i = 0; i < num_signaled_palette_entries[startComp]; i++ ) CurrentPaletteEntries[ cldx ][ numPredictedPaletteEntries + ! ] = new_palette_entries[ cldx ][ i ] palette_escape_val_present_flag equal to 1 specifies that the current encoding unit contains at least one encoded escape sample, escape val present flag equal to 0 specifies that there are no encoded escape samples in the current encoding unit. When not presented, the value of palette_escape_val_present_flag is assumed to be equal to 1. The MaxPalettelndex variable specifies the maximum possible value for a palette index for the current encoding unit. The value of MaxPalettelndex is determined to be equal to CurrentPaletteSize[startComp] - 1 + palette_escape_val_present flag. num_palette_indices_minus1 plus 1 is the number of palette indices explicitly pointed out or deducted for the current block. When num_palette_indices_minus1 is not present, it is assumed to be equal to 0. palettejdxjdc is an indication of an index for the palette table, CurrentPaletteEntries. The value of palettejdxjdc must be in the range of 0 to MaxPalettelndex, inclusive, for the first index in the block, and in the range of 0 to (MaxPalettelndex - 1), inclusive, for the remaining indices in the block. When palettejdxjdc is not present, it is deduced that it is equal to 0. nznz Ln / zznz / E / YiAi The variable Palettelndexldc[i] stores the ith paleta_idx_idc explicitly indicated or deduced. All elements of the array Palettelndexldc[i] are set to 0. `copy_above_indices_for_final_run_flag` equal to 1 specifies that the palette indices of the last positions in the encoding unit are copied from the palette indices in the previous row if horizontal run scanning is used, or from the palette indices in the left column if vertical run scanning is used. `copy_above_indices_for_final_run_flag` equal to 0 specifies that the palette indices of the last positions in the encoding unit are copied from `Palettelndexldc[num_palette_indices_minus1]`. When copy_above_indices_for_final_run_flag is not present, it is assumed to be equal to 0. A `palette_transpose_flag` value of 1 specifies that vertical traverse scanning is applied for scanning sample indices in the current encoding unit. A `palette_transpose_flag` value of 0 specifies that horizontal traverse scanning is applied for scanning sample indices in the current encoding unit. When not displayed, the value of `palette_transpose_flag` is assumed to be 0. The TraverseScanOrder array specifies the scan order array for pallet encoding. TraverseScanOrder is assigned to the horizontal scan order HorTravScanOrder if palette_transpose_flag is equal to 0, and TraverseScanOrder is assigned to the vertical scan order VerTravScanOrder if palette_transpose_flag is equal to 1. `copy_above_palette_indices_flag` equals 1 and specifies that the palette index is equal to the palette index at the same location in the previous row if horizontal scan is used, or the same location in the left column if vertical scan is used. `copy_above_palette_indices_flag` equals 0 and specifies that an indication of the sample's palette index is either encoded in the bitstream or inferred. The variable CopyAbovelndicesFlag[xC][yC] equal to 1 specifies that the palette index is copied from the palette index in the previous row (horizontal scan) or left column (vertical scan). CopyAbovelndicesFlag[xC][yC] equal to 0 specifies that the palette index is explicitly encoded in the bitstream or inferred. The array indices xC and yC specify the location (xC, yC) of the sample relative to the upper-left luma sample in the image. The value of MapaíndicePaleta[xC][yC] must be in the range of 0 to (MaxPalettelndex - 1), inclusive. The variable PalettelndexMap[xC][yC] specifies a palette index, which is an index to the array represented by CurrentPaletteEntries. The array indices xC and yC specify the location (xC, yC) of the sample relative to the luma sample at the top left of the image. The value of PalettelndexMap[xC][yC] must be in the range of 0 to and including MaxPalettelndex. The adjustedRefPalettelndex variable is derived as follows: adjustedRefPalettelndex = MaxPalettelndex + 1 if( PaletteScanPos > 0 ) { nznz Ln / zznz / E / YiAi xcPrev = χθ + TraverseScanOrder[ log2CbWidth ][ log2bHeight ][ PaletteScanPos - 1 ][ 0 ] ycPrev = yO + TraverseScanOrder[ log2CbWidth ][ log2bHeight][ PaletteScanPos - 1 ][ 1 ] if( CopyAbovelndicesFlag[ xcPrev ][ ycPrev ] = = 0 ) { adjustedRefPalettelndex = PalettelndexMap[ xcPrev ][ ycPrev ] {} else { if( !palette_transpose_flag) adjustedRefPalettelndex - PalettelndexMap[ xC ][ yC - 1 ] else adjustedRefPalettelndex = PalettelndexMap[ xC - 1 ][ yC ]} } When CopyAbovelndicesFlag[ xC ][ yC ] is equal to 0, the variable CurrPalettelndex is derived as follows: if( CurrPalettelndex >= adjustedRefPalettelndex ) CurrPalettelndex++ When palette_run_prefix is ​​present, it specifies the prefix part in the binarization of PaletteRunMinusI. The `palette_run_suffix` suffix is ​​used in the derivation of the `PaletteRunMinusI` variable. When it is not present, the value of `palette_run_suffix` is assumed to be 0. When RunToEnd equals 0, the PaletteRunMinusI variable is derived as follows: - If PaletteMaxRunMinusI is equal to 0, PaletteRunMinusI is set equal to 0. - Otherwise (PaletteMaxRunMinusI is greater than 0) the following applies: - If palette_run_prefix is ​​less than 2, the following applies: PaletteRunMinusI = palette_run_prefix - Otherwise (palette_run_prefix is ​​greater than or equal to 2), apply the following: PrefixOffset = 1 « ( paletterunprefix - 1 ) PaletteRunMinusI = PrefixOffset + palette_run_suffix The PaletteRunMinusI variable is used as follows: - If CopyAbovelndicesFlag[ xC ][ yC ] is equal to 0, PaletteRunMinusI specifies the number of consecutive locations less 1 with the same palette index. - Otherwise, if palette_transpose_flag equals 0, PaletteRunMinusI specifies the number of consecutive locations less 1 with the same palette index used in the corresponding position in the previous row. nznz Ln / zznz / E / YiAi Otherwise, PaletteRunMinusI specifies the number of consecutive locations less 1 with the same palette index used in the corresponding position in the left column. When RunToEnd is equal to 0, the variable PaletteMaxRunMinusI represents the maximum possible value for PaletteRunMinusI and it is a bitstream conformance requirement that the value of PaletteMaxRunMinusI must be greater than or equal to 0. palette_escape_val specifies the quantized value of the encoded escape sample for a component. The variable PaletteEscapeVal[cldx][xC][yC] specifies the escape value of a sample for which PalettelndexMap[xC][yC] is equal to MaxPalettelndex and palette_escape_val_present_flag is equal to 1. The array index cldx specifies the color component. The array indices xC, yC specify the location (xC, yC) of the sample relative to the luma sample at the top left of the image. It is a bitstream conformance requirement that PaletteEscapeVal[ cldx ][ xC ][ yC ] must be in the range of 0 to (1 « ( BitDepthY +1 )) - 1, inclusive, for cldx equal to 0, and in the range of 0 to (1 « ( BitDepthC + 1 )) - 1, inclusive, for cldx not equal to 0. nznz Ln / zznz / E / YiAi Table 3 The binary password and CABAC context selection for the palette_run_prefix syntax The binary password for palette run prefix is ​​derived through the Rice truncated binarization process described below with the input parameters cMax = Floor( Log2( PaletteMaxRunMinusI )) + 1, cRiceParam = 0. Rice Truncated Binarization Process The input to this process is a truncated binarization request of Rice (TR), cMax, and cRiceParam. The result of this process is the binarization of TR, which associates each symbolVal I value with a corresponding binary string. A TR binary string is a concatenation of a binary prefix string and, when present, a binary suffix string. To derive the binary prefix string, apply the following: - The prefix value of symbolVal, prefixVal I, is derived as follows: prefixVal = symbolVal » cRiceParam - The TR binary string prefix is ​​specified as follows: If prefixVal is less than cMax » cRiceParam, the prefix binary string is a binary string of length prefixVal + 1 indexed by binldx. Binary values ​​for binldx less than prefixVal + 1 are equal to 1. The binary value with binldx equal to prefixVal + 1 is equal to 0. Table 3-1 below illustrates the binary strings of this binary binarization for prefixVal. - In other words, the binary string is a bit string of length cMax » cRiceParam where all binary values ​​are equal to 1. Table 3-1 - Nail binarization binary string (informative) nznz Ln / zznz / E / YiAi prefixVal Bin string 0 0 1 1 0 2 1 1 0 3 1 1 1 0 4 1 1 1 1 0 5 1 1 1 1 1 0 binldx 0 1 2 3 4 5 When cMax is greater than symbolVal and cRiceParam is greater than 0, the TR binary string suffix is ​​presented and derived as follows: - The suffix value suffixVal is derived as follows: suffixVal = symbolVal - ((prefixVal) « cRiceParam) - The TR binary string suffix is ​​specified by invoking the fixed-length (FL) binarization process specified in the VVC specification for suffixVal with a cMax value equal to (1 « cRiceParam) - 1. NOTE - For input parameter cRiceParam = 0, TR's binarization is exactly a truncated nail binarization and is always invoked with a cMax value equal to the maximum possible value of the syntax element being decoded. Deriving process of ctxlnc for the palette run prefix syntax element The inputs to this process are the binary index binldx and the syntax elements copy_above_palette_indices_flag and palette_idx_idc. The result of this process is the variable ctxlnc. The variable ctxlnc is derived as follows: - If copy_above_palette_indices_flag is equal to 0 and binldx is equal to 0, cbdnc is derived as follows: ctxlnc = (palette idx idc < 1)70:(( palette idx idc <3)?1:2) - Otherwise, ctxlnc is provided by Table 3-2: Table 3-2 - ctxldxMap specification[ copy_above_palette_indices_flag ][ binldx ] nznz Ln / zznz / E / YiAi binldx 0 1 2 3 4 >4 copy_above_palette_indices_flag = = 1 5 6 6 7 7 bypass copy_above_palette_indices_flag = = 0 0, 1, 2 3 3 4 4 bypass As the coefficient group (CG) used in the transformation coefficient encoding, a multi-line-based coefficient group (CU) is used, each consisting of m samples, where the index steps, palette index values, and quantized escape colors are sequentially encoded / parsed for each CG. As a result, the pixels in a line-based CG can be reconstructed after the syntactic parsing of the syntax elements, e.g., index steps, palette index values, and quantized escape colors for the CG, which greatly reduces the buffer requirement in palette mode in VTM6.0, where the syntax elements for the entire CU have to be parsed (and stored) before reconstruction. In this application, each palette-mode CU is divided into multiple segments of m samples (m = 8 in this evaluation) based on the path scan mode, as shown in Figure 5D. The encoding order for palette step encoding in each segment is as follows: For each pixel, a run copy flag = 0 with a context-coded binary value of 0 is set, indicating that the pixel is the same as the previous pixel; that is, the previous scanned pixel and the current pixel are both of type COPYABOVE step, or the previous scanned pixel and the current pixel are both of type INDEX step and have the same index value. Otherwise, run_copy_flag = 1 is set. If the current pixel and the previous pixel are of different modes, a context-encoded binary value `copy_above_palette_indices_flag` is flagged, indicating the pixel's step type—either `INDEX` or `COPY ABOVE`. In this case, the decoder does not need to parse the step type if the sample is in the first row (horizontal scan) or the first column (vertical scan), as `INDEX` mode is used by default. The decoder also does not need to parse the step type if the previously parsed step type is `COPY ABOVE`. After step-by-step palette encoding of the pixels in a segment, the index values ​​(for INDEX mode) and quantized escape colors are encoded as binary offset values ​​and grouped separately from the context-coded binary encoding / parsing to improve performance within each line-based CG. Because the index value is now parsed / encoded after step-by-step encoding, the encoder does not need to specify the number of index values ​​(num_palette_indices_minus1) and the last step type (copy_above_indices_for_final_run_flag). The CG palette mode syntax is illustrated in Table 4. Table 4. Palette coding syntax nznz Ln / zznz / E / YiAi palette_coding( xO, yO, cbWidth, cbHeight, startComp, numComps ) { Descriptor palettePredictionFinished = 0 NumPredictedPaletteEntries = 0 for( predictorEntryldx = 0; predictorEntryldx < PredictorPaletteSize[ startComp ] && IpalettePredictionFinished && NumPredictedPaletteEntries[ startComp ] < palette_max_size; predictorEntryldx++ ) { palette_predictor_run ae(v) if( palette_predictor_run != 1 ) { if( palette_predictor_run > 1 ) predictorEntryldx += palette_predictor_run - 1 PalettePredictorEntryReuseFlags[ predictorEntryldx ] = 1 NumPredictedPaletteEntries++} else palettePredictionFinished = 1} if( NumPredictedPaletteEntries < palettemaxsize ) num_signaled_palette_entries ae(v) for( cldx = startComp; cldx < ( startComp + numComps); cldx++ ) for( i = 0; i < num_signaled_palette_entries;i++ ) new_palette_entñes[ cldx ][ i ] ae(v) if( CurrentPaletteSize[ startComp ] > 0 ) paletteescapevalpresentflag ae(v) if( MaxPalettelndex > 0 ) { adjust = 0 palette_transpose_flag ae(v)} if( treeType != DUAL TREE CHROMA && palette escape val present flag ) {; if( cu_qp_delta_enabled_flag && HsCuQpDeltaCoded ) { cuqpdeltaabs ae(v) if( cu_qp_delta_abs ) cu_qp_delta_sign_flag ae(v)}} if( treeType != DUALTREELUMA && palette escape val present flag ) { if( cu chroma qp offset enabled flag && HsCuChromaQpOffsetCoded ) { cu_chroma_qp_offset_flag ae(v) if( cu_chroma_qp_offset_flag ) cu_chroma_qp_offset_idx ae(v)}} PreviousRunTypePosition = 0 PreviousRunType = 0 for (subSetld = 0; subSetld <= (cbWidth* cbHeight -1) » 4; subSetld++) { minSubPos = subSetld « 4 if( minSubPos + 16 > cbWidth * cbHeight) maxSubPos = cbWidth * cbHeight else maxSubPos = minSubPos + 16 RunCopyMap[ 0 ][ 0 ] = 0 log2CbWidth = Log2( cbWidth ) log2CbHeight = Log2( cbHeight) PaletteScanPos = minSubPos while( PaletteScanPos < maxSubPos ) { xC = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 0 ] ηζηζ ίη / ζζηζ / Ε / γίΛΐ yC = y0 + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 1 ] if( PaletteScanPos > 0 ) { xcPrev = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 0] ycPrev = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 1]} if ( MaxPalettelndex > 0 && PaletteScanPos > 0) { run_copy_flag ae(v) RunCopyMap[ xC ][ yC ] = run_copy_flag} CopyAbovelndicesFlag[ xC ][ yC ] = 0 if( MaxPalettelndex > 0 && ! RunCopyMap[startComp][xC][yC] ) { if( ((!palette_transpose_flag && yC > 0 ) | | ( palette_transpose_flag && xC > 0 )) && CopyAbovelndicesFlag[ xcPrev ][ ycPrev ] = = 0){ co py_a bove_pa I ette_i nd ices_f I ag ae(v) CopyAbovelndicesFlag[ xC ][ yC ] = copy_above_palette_ind ¡ces_flag} PreviousRunType = CopyAbovelndicesFlag[ xC ][ yC ] PreviousRunTypePosition = curPos} else { CopyAbovelndicesFlag[ xC ][ yC ] = CopyAbovelndicesFlag[xcPrev][ ycPrev]}} PaletteScanPos ++} PaletteScanPos = minSubPos while( PaletteScanPos <maxSubPos ) { zhiz in / zhiz / E / yLi xC = χθ + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 0 ] yC = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos ][ 1 ] if( PaletteScanPos > 0 ) { xcPrev = xO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 0] ycPrev = yO + TraverseScanOrder[ log2CbWidth ][ log2CbHeight ][ PaletteScanPos - 1 ][ 1 ]} if ( MaxPalettelndex > 0 ) { if (! RunCopyMap [ x C][ yC ] && CopyAbovelndicesFlag[ xC ][ yC ] = = 0 ) { if( MaxPalettelndex - adjust > 0 ) { palette_idx_idc} adjust = 1}} if (! RunCopyMap [ xC][ yC ] && CopyAbovelndicesFlag[ xC ][ yC ] - - 0 ) { CurrPalettelndex = palette_idx_idc if( CopyAbovelndicesFlag[ xC ][ yC ] = = 0 ) { PalettelndexMapj xC ][ yC ] = CurrPalettelndex} else { if (!palette_transpose_flag ) PalettelndexMapf xC ][ yC ] - PalettelndexMap[ xC ][ yC - 1 ] else PalettelndexMap[ xC ][ yC ] = PalettelndexMap[ xC - 1 ][ yC ]}} if( palette_escape_val_present_flag ) { for( cldx = startComp;cldx < ( startComp + numComps ); cldx++ ); ηζηζ ίη / ζζηζ / Ε / γίΛΐ for( sPos = minSubPos ; sPos < maxSubPos; sPos++ ) { xC = xO + TraverseScanOrder[ log2CbWidth][ log2CbHeight ][ sPos ][ 0 ] yC = yO + TraverseScanOrder[ log2CbWidth][ log2CbHeight ][ sPos ][ 1 ] if( PalettelndexMapj cldx ][ xC ][ yC ] = = MaxPalettelndex ) { palette_escape_val ae(v) PaletteEscapeValf cldx ][ xC ][ yC ] = palette escape val}}}}} nznz Ln / zznz / E / YiAi Figure 6 is a flowchart 600 illustrating an exemplary process by which a video decoder (e.g., video decoder 30) implements video data decoding techniques according to some implementations of the present description. For palette mode in the VVC, palette mode can be applied to CUs that are equal to or smaller than 64x64 pixels. In some modes, a minimum palette mode block size is used to reduce complexity, such that palette mode is disabled for encoding units whose size is less than or equal to the minimum palette mode block size. For example, palette mode is disabled for all blocks smaller than a certain threshold, such as 16 samples. Because there are different chroma formats (e.g., 4:4:4, 4:2:2, 4:2:0) and different encoding tree types (e.g., SINGLE_TREE, DUAL_TREE_LUMA, and DUAL_TREE_CHROMA), this threshold can vary. “SINGLE_TREE” indicates that the luma and chroma components of an image are split equally, such that these two components share the same palette table and palette predictor under palette mode.In contrast, “DUAL TREE” indicates that the luma and chroma components of an image are separated, such that these two components have different palette tables and palette predictors under palette mode. For example, for “DUAL_TREE OBLE” cases, where the chroma component is considered separately, palette mode for the chroma component of CUs with 16 or fewer samples should be disabled to reduce complexity. Table 5 below provides an example of the designated syntax. Table 5 Palette Mode Enablement Indicator Under Different Encoding Tree Types and Chroma Formats codlng_unit( xO, yO, cbWidth, cbHeight, cqtDepth, treeType, modeType ) { Descriptor if( CuPredMode[ chType ][ xO ][ yO ] == MODEJNTRA && sps_palette_enabled_flag && cbWidth <= 64 && cbHeight <= 64 && cu skip flag[ xO ][ yO ] = = 0 && modeType != MODE TYPE INTER && (cbWidth* cbHeight > (treeType != DUAL TREE CHROMA? 16:16* SubWidthC* SubHeightC))) pred_mode_plt_flag u(1)}} nznz Ln / zznz / E / YiAi Chroma format SubWidthC SubHeightC Monochrome 1 1 4:4:4 1 1 4:2:2 2 1 4:2:0 2 2 In Table 5, `pred_mode_plt_flag` specifies whether palette mode is enabled (for example, a value of 1) or disabled (for example, a value of 0) for the encoding unit. Parameters such as `SubWidthC` and `SubHeightC` are associated with the chroma format for the encoding unit as follows: In monochromatic sampling, there is only one sample array, which is nominally considered the luma array. In 4:2:0 sampling, each of the two chroma arrays has half the height and half the width of the luma array. In 4:2:2 sampling, each of the two chroma arrays has the same height and half the width of the luma array. In 4:4:4 sampling, each of the two chroma arrays has the same height and width as the luma array. In another scenario, for single-tree cases, palette mode is disabled for CUs with small luma block sizes. For example, palette mode is disabled for CUs with a luma block size of 16 pixels or less in single-tree cases. However, in a specific example, palette mode can be enabled for an 8x4 CU containing 8x4 luma samples and two 4x2 chroma samples, as palette enablement is conditional on the luma sample size, regardless of the chroma size. In some modes, in the single-tree case, the luma component (e.g., Y) and the chroma component (e.g., Cb and Cr) of a CU are split in the same way. In a double-tree case, the luma and chroma components have different split trees. In a local double-tree case, the luma and chroma components have different palette tables under a single-tree case. Under the local double-tree case, palette encoding is applied separately to the luma and chroma components within the CU. In another mode, for local double-tree cases, palette mode is disabled for small blocks. For example, in local double-tree cases, palette mode is disabled for CUs that are less than or equal to 32 pixels. In some modes, palette mode excludes local double-tree cases. In VVC, for single-tree cases, palette mode applies to CUs with a luma block that is equal to or less than 64x64 pixels and greater than 4x4 pixels. For double-tree cases, palette mode applies to CUs that are equal to or less than 64x64 pixels and greater than 4x4 pixels, for both luma and chroma components. In another mode, to reduce complexity, palette mode is disabled for local double-tree cases. Table 6 below provides an example of the syntax in VVC design. When the CU's modeType is equal to MODE_TYPE_INTRA in VVC, it means the CU is in a double-tree case. The changes to VVC are illustrated below. Table 6 Exemplary syntax for palette mode exclusion in the case of local double tree nznz Ln / zznz / E / YiAi - coding_unit( xO, yO, cbWidth, cbHeight, cqtDepth, treeType, modeType ) { Descriptor - - - if( CuPredMode[ chType ][ xO ][ yO ] == MODEJNTRA && sps_palette_enabled_flag && cbWidth <= 64 && cbHeight <= 64 && cu_skip_flag[ xO ][ yO ] = = 0 && modeType != MODE TYPE INTER && (cbWidth* cbHeight > (treeType != DUAL TREE CHROMA? 16:16* SubWidthC* SubHeightC)) && ( modeType ! = MODE_TYPE_INTRA)) pred_mode_plt_flag - ae(v) -} - - -} - In another scenario, for local double-tree cases, palette mode is disabled only for the chroma component. In other words, under the local double-tree case, palette mode is applicable to a luma CU, but not to a chroma CU. Table 7 below provides an example of the syntax in the VVC design. When the CU's modeType is equal to MODE_TYPE_INTRA and the CU's treeType is equal to DUALTREECHROMA in the VVC design, it means that the CU is a chroma component and a local double-tree case. The changes to the VVC are illustrated below in Table 7. Table 7 Example syntax for deactivating palette mode only for the chroma component in the case of a local double tree - coding_unit( xO, yO, cbWidth, cbHeight, cqtDepth, treeType, modeType ) { Descriptor - - - if( CuPredMode[ chType ][ xO ][ yO ] == MODEJNTRA && sps_palette_enabled_flag && cbWidth <= 64 && cbHeight <= 64 && cu_skip_flag[ xO ][ yO ] = = 0 && modeType != MODE TYPE INTER && (cbWidth* cbHeight > (treeType != DUALTREECHROMA? 16:16* SubWidthC* SubHeightC)) && ((modeType ! = MODE TYPE INTRA) | | (treeType I = DUAL TREE CHROMA))) pred_mode_plt_flag - ae(v) -} - - -} - nznz Ln / zznz / E / YiAi In some local double-tree configurations, palette prediction is updated for both the chroma and luma components. According to the current VVC specification, under local double-tree configurations, the palette prediction update process is performed only for the chroma component. More specifically, palette prediction may not be updated while each luma CU is being encoded in palette mode under local double-tree configurations. Palette prediction may be updated after the last chroma component of each chroma CU is encoded in palette mode within the local double-tree configuration. The palette prediction update process defined in the VVC, as described above, is not efficient for encoding performance. In some of the modes described here, to improve encoding efficiency under the local double tree case, the palette prediction update process is performed for both luma and chroma CUs. More specifically, the palette prediction can be updated first while encoding each luma CU under the local double tree, followed by encoding each chroma CU under the same local double tree. Table 8 below provides an example of the syntax in the VVC design. In the VVC design, the `cldx` variable specifies the color / video component of the current CU: 0 for luma, 1 for Cb, and 2 for the Cr component. The changes to the VVC are illustrated below. Table 8 Example syntax of palette prediction update process, carried out for both luma and chroma components in the case of double local tree nznz Ln / zznz / E / YiAi Decoding process for palette mode When localDualTree equals 1, the following applies: If treeType is equal to DUALTREELUMA, the following applies for i = O..num_signalled_palette_entries[ startComp ] - 1: CurrentPaletteEntries[ 1 ][ NumPredictedPaletteEntries + i ] = « ( BitDepth - 1 )(450) CurrentPaletteEntries[ 2 ][ NumPredictedPaletteEntries + i ] = «( BitDepth - 1 )(451) Otherwise (if treeType is equal to DUAL TREE CHROMA), the following applies for i = O..num_signalled_palette_entries[ startComp ] - 1: CurrentPaletteEntries[ 0 ][ NumPredictedPaletteEntries + i ] = « ( BitDepth - 1 )(452) The variables CurrentPaletteSize[ 0 ], startComp, numComps and maxNumPalettePredictorSize are derived as follows: CurrentPaletteSize[ 0 ] = CurrentPaletteSizef startComp ] startComp = 0 numComps = 3 maxNumPalettePredictorSize = 63 When one of the following conditions is true: - cldx is equal to 0 and numComps is equal to 1; cldx is equal to 0 and localDualTree is equal to 1; cldx is equal to 2; - The value of PredictorPaletteSize[startComp] and the PredictorPaletteEntries array are derived or modified as follows: In some modes, palette prediction is partially updated in local double-tree cases. As mentioned above, under the local double-tree case, the palette prediction update process is performed for both luma and chroma CUs. More specifically, palette prediction can be updated first while encoding each luma CU under the local double-tree, followed by encoding each chroma CU under the same local double-tree. Since the CUs under the local double tree are all small CUs, performing the updated palette prediction process on these CUs sequentially requires a significant number of computation cycles. According to some implementations, to reduce complexity, a shared palette table is used for some or all CUs under the local double tree, without table updates. In one example, for local double-tree cases, the palette prediction update process is disabled under palette mode. Table 9 below provides an example of the syntax in the VVC design, where lines of code 450 to 456 in Table 8 are also removed. In the VVC design, the cldx variable specifies the color component of the current CU: 0 for luma, 1 for Cb, and 2 for the Cr component. The changes to the VVC are illustrated below. Table 9 Example syntax of palette prediction update process, disabled for both components, luma and chroma, in the case of double local tree nznz Ln / zznz / E / YiAi Decoding process for palette mode When one of the following conditions is true: cldx is equal to 0 and numComps is equal to 1 and localDualTree is not equal to 1; cldx is equal to 2 and localDualTree is not equal to 1; - The value of PredictorPaletteSize[startComp] and the PredictorPaletteEntries array are derived or modified as follows: In some modes, under the local double-tree case, the palette prediction update process in palette mode is disabled for CUs with a luma block size less than or equal to 32 pixels. In this case, the palette prediction update process in palette mode can be enabled for an 8x8 or larger CU that contains samples of at least 8x8 lumas. In yet another configuration, for local double-tree cases, the palette prediction update process is disabled only for chroma CUs. Table 10 below provides an example of the syntax in the VVC design. In the WC design, the cldx variable specifies the color component of the current CU: 0 for luma, 1 for Cb, and 2 for the Cr component. The changes to the VVC are illustrated below. Table 10 Exemplary syntax of palette prediction update process, disabled only for chroma component in the case of double local tree Decoding process for palette mode When localDualTree equals 1, the following applies: If treeType is equal to DUALTREELUMA, the following applies for i = O..num_signalled_palette_entries[ startComp ] - 1: CurrentPaletteEntriesj 1 ][ NumPredictedPaletteEntries + i ] = 1 « ( BitDepth - 1 ) CurrentPaletteEntriesj 2 ][ NumPredictedPaletteEntries + i ] = 1 « ( BitDepth - 1 - The variables CurrentPaletteSizel[O], startComp, numComps and maxNumPalettePredictorSize are derived as follows: CurrentPaletteSizej 0 ] = CurrentPaletteSizej startComp ] startComp = 0 numComps = 3 maxNumPalettePredictorSize = 63 When one of the following conditions is true: cldx is equal to 0 and numComps is equal to 1; cldx is equal to 0 and localDuaITree is equal to 1; cldx is equal to 2 and localDualTree is not equal to 1; - The value of PredictorPaletteSize[startComp] and the PredictorPaletteEntries array are derived or modified as follows: nznz Ln / zznz / E / YiAi In some modes, under the case of local double tree, the palette prediction update process in palette mode is updated independently for different video components. As mentioned above, under the local double tree case, the palette prediction update process is performed sequentially. This also means that decoding a chroma CU in palette mode, under a local double tree, cannot begin until all luma CUs under the same local double tree have been decoded. This can cause an undesirable delay in hardware codec implementations. To solve the problem described above, according to some approaches, the palette prediction update process is carried out independently for different video components (e.g., luma and chroma) in a local double tree, so that palette mode encoding for the chroma component can be performed in parallel with the luma component. In one example of this approach, under a local double tree, the palette at the beginning of the local double tree is used as the starting palette for both CUs, luma and chroma. In some modes, improvements are implemented to the palette prediction update process in local double-tree cases. Under local double-tree cases, the palette prediction update process is performed separately for luma and chroma components. More specifically, the palette prediction may be updated first while encoding each luma CU under the local double-tree, followed by encoding each chroma CU under the same local double-tree. As a result, when updating the palette prediction while encoding a luma CU under the local double-tree, the chroma information of co-localized pixels may not be available, and vice versa. In some modes, to improve encoding efficiency, when updating the palette prediction while encoding a CU of a video component (e.g., luma and / or chroma) under a local double tree, the values ​​of the other video component (e.g., chroma and / or luma) from the previously available palette candidate can be used. In an example for local double tree cases, during the palette prediction update process for the luma component, the chroma component of the first available candidate can be used as the chroma component of the newly added palette entry. Table 11 below provides an example of the syntax in the VVC design. Changes to the WC are illustrated below. Table 11 Example syntax of palette prediction update process using the chroma component of the first available candidate nznz Ln / zznz / E / YiAi Proceso de decodificación para modo paleta Cuando localDualTree es igual a 1, se aplica lo siguiente: If treeType is equal to DUALTREELUMA, the following applies for i = O..num_signalled_palette_entr¡es[ startComp ] - 1: If NumPredictedPaletteEntries is not equal to 0: CurrentPaletteEntriesf 1 ][ NumPredictedPaletteEntries + i ] = CurrentPaletteEntriesf 1 ][ 0 ] CurrentPaletteEntries[ 2 ][ NumPredictedPaletteEntries + i ] = CurrentPaletteEntriesf 2 ][ 0 ] Otherwise: CurrentPaletteEntries[ 1 ][ NumPredictedPaletteEntries + i ] = « ( BitDepth - 1 ) CurrentPaletteEntries[ 2 ][ NumPredictedPaletteEntries + i ] = « ( BitDepth - 1 ) Otherwise (if treeType is equal to DUAL_TREE_CHROMA), the following applies for i = O..num_signalled_palette_entries[ startComp ] - 1: If NumPredictedPaletteEntries is not equal to 0: CurrentPaletteEntries[ 0 ][ NumPredictedPaletteEntries + i ] = CurrentPaletteEntries[ 0 ][ 0 ] Otherwise: CurrentPaletteEntries[ 0 ][ NumPredictedPaletteEntries + i ] = « ( BitDepth - 1 ) nznz Ln / zznz / E / YiAi As shown in FIGURE 6, in some modes, the video decoder 30 receives, from the bitstream, a plurality of syntax elements associated with an encoding unit, and the plurality of syntax elements indicates a type of encoding tree of the encoding unit and whether a local double tree mode is enabled for the encoding unit (610). The video decoder 30, in accordance with the determination that the encoding tree type is a single tree, and the local dual tree mode enabled for the encoding unit (620), disables the palette mode for the encoding unit when the encoding unit is equal to or less than a predefined threshold (630). In some modes, disabling palette mode for the encoding unit (630) includes disabling palette mode for both the luma component and the chroma component of the encoding unit (640). In some modes, disabling palette mode for the encoding unit (630) includes disabling palette mode only for the chroma component of the encoding unit (650). In some modes, disabling palette mode only for the chroma component of the encoding unit includes: determining, from the plurality of syntax elements that further indicate whether a video component of the encoding unit is the chroma component or a luma component; and in accordance with a determination that the video component of the encoding unit is the chroma component: disabling palette mode for the chroma component of the encoding unit. In some modes, disabling palette mode only for the chroma component of the encoding unit includes: determining, from the plurality of syntax elements, which further indicate whether a video component of the encoding unit is the chroma component or a luma component; in accordance with a determination that the video component of the encoding unit is the luma component; receiving, from the bitstream, a palette mode enable flag associated with the luma component of the encoding unit; and decoding the encoding unit in accordance with the palette mode enable flag. In some modes, the video decoder 30 receives, from the bitstream, a palette prediction enable syntax; and updates the palette prediction for the luma component of the encoding unit according to the palette prediction enable syntax. In some modes, the video decoder 30 disables the updating of a palette prediction for the luma component of the encoding unit. In some modes, the video decoder 30 determines a minimum palette mode luma block size; and, in accordance with the determination that the encoding unit luma component size is less than or equal to the minimum palette mode luma block size: it disables the palette prediction update for the encoding unit luma component. In some modes, the minimum luma block size for palette mode is 32 by 32 luma samples. In some modes, the minimum luma block size for palette mode is 8 by 8 luma samples. In some modes, a syntax element included in the plurality of syntax elements, which indicates whether a local double tree mode is enabled for the encoding unit, is MODETYPEINTRA. In some modes, a syntax element included in the plurality of syntax elements, which indicates whether the video component of the encoding unit is a chroma component or a luma component, is DUAL_TREE_CHROMA. In some modalities, the predefined threshold in stage 630 is 32 by 32 samples. In some modalities, the predefined threshold in stage 630 is 16 by 16 samples. FIGURE 7 is a block diagram illustrating an exemplary context-adapted binary arithmetic coding (CABAC) engine, according to some implementations of the present description. Context-adapted binary arithmetic coding (CABAC) is a form of entropy coding used in many video coding standards, such as H.264 / MPEG-4 AVC, High Efficiency Video Coding (HEVC), and VVC. CABAC is based on arithmetic coding, with a few innovations and changes to suit the needs of video coding standards. For example, CABAC encodes binary symbols, which keeps complexity low and allows for probability modeling of the most frequently used bits of any symbol. Probability models are selected adaptively based on the local context, allowing for better probability modeling because the nznz Ln / zznz / E / YiAi coding modes are typically well-correlated locally.Finally, CABAC uses a multiplication-free range division by using quantified probability ranges and probability states. CABAC has multiple probability modes for different contexts. First, it converts all non-binary symbols to binary. Then, for each binary value (or expressed bit), the encoder selects which probability model to use, then uses information from nearby elements to optimize the estimated probability. Finally, arithmetic coding is applied to compress the data. Context-based modeling provides conditional probability estimates for encoding symbols. By using context-appropriate models, inter-symbol redundancy can be exploited by switching between different probability models, based on symbols already encoded in the vicinity of the current symbol to be encoded. Encoding a data symbol involves the following steps. Binarization: CABAC uses Binary Arithmetic Coding, which means that only binary decisions (1 or 0) are encoded. A symbol valued as non-binary (for example, a transformation coefficient or movement vector) is "binarized" or converted to a binary code before arithmetic encoding. This process is similar to the process of converting a data symbol into a variable-length code, but the binary code is further encoded (by the arithmetic encoder) before transmission. The steps are repeated for each binary value (or "bit") of the binarized symbol. Model selection by context. A “model by context” is a probability model for one or more binary values ​​of the binarized symbol. This model can choose from a selection of available models, depending on the symbol statistics of the newly encoded data. The model by context stores the probability that each binary value is “1” or “0”. Arithmetic Coding: An arithmetic encoder encodes each binary value according to the selected probability model. It is mentioned that there are only two sub-ranges for each binary value (corresponding to “0” and “1”). Probability update: The model for selected context is updated based on the actual coded value (e.g., if the binary value was “1”, the frequency count of “1” is increased). By breaking down each non-binary syntax element into a sequence of binary values, the further processing of each binary value in CABAC depends on the choice of the associated encoding mode, which can be either regular or bypass mode. The latter is chosen for binary values, which are assumed to be uniformly distributed, and for which, consequently, the entire process of regular binary arithmetic encoding (and decoding) is simply bypassed.In regular encoding mode, each binary value is encoded using the regular binary arithmetic encoding engine, where the associated probability model is either determined by a fixed choice, based on the syntax element type and the binary value position or binary value index (binldx) in the binary representation of the syntax element, or is chosen adaptively from two or more probability models that depend on information from the related nznz Ln / zznz / E / YiAi side (e.g., spatial proximity, component, depth or size of the CU / PU / TU, or position within the TU). The selection of the probability model is referred to as context-based modeling.As a key design decision, the latter case is generally applied to the most frequently observed binary values, while the former, typically less frequently observed binary values, are handled using a joint, usually a null-order probability model. In this way, CABAC enables adaptive, selective probability modeling at a sub-symbol level and thus provides an efficient tool for exploiting inter-symbol redundancies at significantly reduced modeling or learning costs. It is noted that, for both the adaptive and fixed cases, a change from one probability model to another can, in principle, occur between any two consecutive, regularly coded binary values.In general, the context-based model design in CABAC reflects the purpose of finding a good compromise between the conflicting objectives of avoiding unnecessary modeling cost overhead and exploiting statistical dependencies to a large extent. The probability model parameters in CABAC are adaptive, meaning that the model probabilities are adjusted to the statistical variations in the binary source on a binary-to-binary basis, in a synchronized and background-adapted manner, in both the encoder and decoder. This process is called probability estimation. For this purpose, each probability model in CABAC can take one of 126 different states with associated model probability values, p, ranging from 0.01875 to 0.98125. The two parameters of each probability model are stored as 7-bit entries in a context memory: 6 bits for each of the 63 probability states representing the model probability pLPS of the least likely symbol (LPS), and 1 bit for nMPS, the value of the most likely symbol (MPS). In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored in or transmitted over a computer-readable medium, such as one or more instructions or codes, and executed by a hardware-based processing unit. The computer-readable medium may include computer-readable storage media, which corresponds to a tangible medium, such as a data storage medium, or a communication medium, which includes any means that facilitates the transfer of a computer program from one location to another, for example, according to a communication protocol. Thus, the computer-readable medium may generally correspond to (1) a tangible, non-transient computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave.The 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 structures, and / or data for the implementation of the implementations described in this application. A computer program product may include a computer-readable medium. The terminology used in the description of the implementations herein is for the purpose of describing only particular implementations and is not intended to limit the scope of the claims. As used in the description of the implementations and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It shall also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the aforementioned points. It shall further be understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of certain features, elements, and / or components, but do not preclude the presence or addition of one or more different features, elements, components, and / or groups thereof. It should also be understood that, although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited to these terms. These terms are used only to distinguish one element from another. For example, a first electrode could be called a second electrode and, similarly, a second electrode could be called a first electrode, without departing from the scope of the implementations. The first electrode and the second electrode are both electrodes, but they are not the same electrode. The description in this application is provided for illustrative and descriptive purposes and is not intended to be exhaustive or limited to the invention as described. Many modifications, variations, and alternative implementations will be apparent to those of ordinary experience in the art, who benefit from the lessons presented in the foregoing descriptions and associated figures. The embodiment was chosen and described to better explain the principles of the invention, its practical application, and to enable others skilled in the art to understand the invention for various implementations and to better utilize the underlying principles and various implementations with different modifications that are suitable for the particular use contemplated.Therefore, it should be understood that the scope of the claims should not be limited to the specific examples of the implementations described and that modifications and other implementations are intended to be included within the scope of the appended claims.

Claims

1. A method for decoding video data, characterized in that it comprises: determining, from a bitstream, a plurality of variables associated with an encoding unit, wherein the plurality of variables indicates a type of encoding tree of the encoding unit and whether a local double tree mode is enabled for the encoding unit; and, according to a determination that the type of encoding tree is a single tree, and that the local double tree mode is enabled for the encoding unit: disabling palette mode for the encoding unit when the encoding unit has a size equal to or less than a predefined threshold.

2. The method according to claim 1, further characterized in that the deactivation of the palette mode for the encoding unit comprises: deactivation of the palette mode for both the luma component and the chroma component of the encoding unit.

3. The method according to claim 1, further characterized in that it additionally comprises: according to a determination that the encoding tree type of the encoding unit is a single tree, and the local dual tree mode is enabled for the encoding unit: deactivating the palette mode only for the chroma component of the encoding unit, when the encoding unit has a size greater than a predefined threshold.

4. The method according to claim 3, further characterized in that the deactivation of palette mode only for the chroma component of the encoding unit comprises: determining, from at least one of the plurality of variables, whether a video component of the encoding unit is the chroma component or a luma component; and according to a determination that the video component of the encoding unit is the chroma component: deactivating palette mode for the chroma component of the encoding unit.

5. The method according to claim 3, further characterized in that the deactivation of palette mode only for the chroma component of the encoding unit comprises: determining, from at least one of the plurality of variables, whether a video component of the encoding unit is the chroma component or a luma component; and at least in accordance with a determination that the video component of the encoding unit is the luma component: receiving, from the bitstream, a palette mode enable indicator associated with the luma component of the encoding unit; and decoding the encoding unit in accordance with the palette mode enable indicator.

6. The method according to claim 5, further characterized in that it additionally comprises: deriving, from the bitstream, a local double tree identifier; and updating a palette prediction for the luma component of the encoding unit in response to the local double tree identifier being 1.

7. The method according to claim 6, further characterized in that it additionally comprises: deactivating an update of a palette prediction for the chroma component of the encoding unit in response to the local double tree identifier which is 1.

8. The method according to claim 5, further characterized in that it additionally comprises: determining a luma block size threshold in palette mode; and, according to a determination that the luma component size of the encoding unit is less than or equal to the luma block size threshold in palette mode: disabling an update of a palette prediction for the luma component of the encoding unit.

9. The method according to claim 8, further characterized in that the luma block size threshold in palette mode is 32 by 32 luma samples.

10. The method according to claim 8, further characterized in that the luma block size threshold in palette mode is 8 by 8 luma samples.

11. The method according to claim 1, further characterized in that it is determined whether the local double tree mode is enabled for the encoding unit based on whether a variable included in the plurality of variables is MODE_TYPE_INTRA.

12. The method according to claim 4, further characterized in that it is determined whether the video component of the encoding unit is the chroma component or a luma component on the basis that a variable included in the plurality of variables is DUALTREECHROMA.

13. The method according to claim 1, further characterized in that the predefined threshold is 16.

14. An electronic apparatus characterized in that it comprises: one or more processing units; a memory coupled to the one or more processing units; wherein the one or more processors are configured to carry out the method in accordance with any of claims 1 to 13.

Images