Code Prediction for Block-Based Video Coding.

Abstract

An embodiment of the present disclosure provides a video decoding apparatus and method for transform coefficient code prediction at a video decoder side. The method may include receiving a bitstream including a sequence of code signaling bits for a set of candidate transform coefficients. The method may further include generating, by a processor of the decoder, a set of predictive codes for the set of candidate transform coefficients associated with a transform block of a video frame of the video. The method may further include decoding, by the processor, the sequence of code signaling bits based on one or more contexts used to entropy code the sequence of code signaling bits to obtain an indication of correctness of the predictive code of each of the candidate transform coefficients. The method may further include estimating, by the processor, an original code of the set of candidate transform coefficients based on the set of predictive codes and the sequence of decoded code signaling bits.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on U.S. Provisional Patent Application No. 63 / 290,307, filed December 16, 2021, and claims priority to U.S. Provisional Patent Application No. 63 / 290,307. This application is further based on PCT Application No. PCT / US22 / 49264, filed November 8, 2022, and claims priority to PCT Application No. PCT / US22 / 49264, which in turn claims priority to U.S. Provisional Patent Application No. 63 / 277,705, filed November 10, 2021. This application is further based on PCT Application No. PCT / US22 / 43607, filed September 15, 2022, and claims priority to PCT Application No. PCT / US22 / 43607. PCT Application No. PCT / US22 / 43607 further claims priority to U.S. Provisional Application No. 63 / 244,317, filed September 15, 2021, and U.S. Provisional Application No. 63 / 250,797, filed September 30, 2021. This application is further based on and claims priority to PCT Application No. PCT / US22 / 40442, filed August 16, 2022. PCT Application No. PCT / US22 / 40442 further claims priority to U.S. Provisional Application No. 63 / 233,940, filed August 17, 2021. The contents of all of the above applications are incorporated herein by reference in their entireties.

[0002] This application relates to video encoding and compression, and more specifically, to a video processing system and method for symbol prediction in block-based video encoding. [Background technology]

[0003] Digital video is supported by a variety of electronic devices, such as digital televisions, laptop or desktop computers, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video conferencing devices, video streaming devices, and the like. The electronic devices transmit, receive, or communicate digital video data over a communication network and / or store the digital video data in a storage device. Due to the limited bandwidth capacity of the communication network and the limited memory resources of the storage device, video coding may be used to compress the video data according to one or more video coding standards before communicating or storing the video data. For example, video coding standards include Versatile Video Coding (VVC), Joint Search and Test Model (JEM), High Efficiency Video Coding (HEVC / H.265), Advanced Video Coding (AVC / H.264), or Moving Picture Experts Group (MPEG) coding, and the like. Video coding generally employs prediction methods (e.g., inter-prediction or intra-prediction, and the like) that exploit the redundancy inherent in video data. Video coding aims to compress video data into a form that uses a lower bit rate while avoiding or minimizing degradation of the video quality. Summary of the Invention [Problem to be solved by the invention]

[0004] An implementation of the present disclosure provides a video decoding method for sign prediction of transform coefficients. The video decoding method may include receiving a bitstream including a sequence of code signaling bits for a set of candidate transform coefficients. The video decoding method may further include generating, by a processor of the decoder, a set of predictive codes for the set of candidate transform coefficients associated with a transform block of a video frame of the video. The video decoding method may further include decoding, by the processor, the sequence of code signaling bits based on one or more contexts used to entropy code the sequence of code signaling bits to obtain an indication of correctness of the predictive code of each of the candidate transform coefficients. The video decoding method may further include estimating, by the processor, an original code of the set of candidate transform coefficients based on the set of predictive codes and the sequence of decoded code signaling bits.

[0005] Implementations of the present disclosure also provide a video decoding device, which may include a memory configured to perform the video decoding method for sign prediction of transform coefficients summarized above.

[0006] Implementations of the present disclosure also provide a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by a processor, cause the processor to perform the video decoding method for sign prediction of transform coefficients summarized above. Implementations of the present disclosure further provide a non-transitory computer-readable storage medium having stored thereon a bitstream including a sequence of sign signaling bits for a set of candidate transform coefficients. The bitstream is decodable by the video decoding method for sign prediction of transform coefficients summarized above.

[0007] Implementations of the present disclosure also provide a video encoding method for sign prediction of transform coefficients. The video encoding method may include generating, by a processor of an encoder, a set of predictive codes for a set of candidate transform coefficients associated with a transform block of a video frame of a video. The video encoding method may further include determining, by the processor, one or more contexts for entropy coding a sequence of code signaling bits for the set of candidate transform coefficients. The video encoding method may further include determining, by the processor, a sequence of code signaling bits in response to the one or more contexts. The code signaling bits are entropy coded using the one or more contexts to indicate correctness of the predictive codes of each of the candidate transform coefficients compared to an original code of the set of candidate transform coefficients. The video encoding method may further include storing in a bitstream the coded data of the quantization levels of the candidate transform coefficients and the coded sequence of code signaling bits for the candidate transform coefficients.

[0008] Implementations of the present disclosure also provide a video encoding device, which may include a memory configured to perform the video encoding method for sign prediction of transform coefficients summarized above.

[0009] Implementations of the present disclosure also provide a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by a processor, cause the processor to perform the video encoding method for sign prediction of transform coefficients summarized above. Implementations of the present disclosure further provide a non-transitory computer-readable storage medium having stored thereon a bitstream including a sequence of sign signaling bits for a set of candidate transform coefficients. The bitstream is decodable by the video encoding method for sign prediction of transform coefficients summarized above.

[0010] It is to be understood that both the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present disclosure.

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate examples in accordance with the present disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram illustrating an example system for encoding and decoding video blocks according to some implementations of the present disclosure. [Diagram 2] 1 is a block diagram illustrating an example video encoder according to some implementations of the present disclosure. [Diagram 3] 1 is a block diagram illustrating an example video decoder according to some implementations of the present disclosure. [Figure 4A] 1 is a diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes in accordance with some implementations of the present disclosure. [Figure 4B] 1 is a diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes in accordance with some implementations of the present disclosure. [Figure 4C] 1 is a diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes in accordance with some implementations of the present disclosure. [Figure 4D] 1 is a diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes in accordance with some implementations of the present disclosure. [Figure 4E] 1 is a diagram illustrating how a frame is recursively divided into multiple video blocks of different sizes and shapes in accordance with some implementations of the present disclosure. [Diagram 5] 1 is a diagram illustrating a top-left scan order of transform coefficients within a coefficient group, according to some examples. [Figure 6] 1 is a diagram illustrating a Low Frequency Non-Separable Transform (LFNST) process, according to some examples. [Figure 7]11 is a diagram showing the upper left region of primary transform coefficients input to a forward LFNST, according to some examples. [Figure 8] 1 is a diagram illustrating search regions for intra-template matching, with some examples; [Figure 9] 1 is a diagram illustrating an example process of code prediction according to some examples. [Figure 10] 1 is a diagram illustrating the computation of a cost function for code prediction with some examples; [Figure 11] 1 is a diagram illustrating two example scalar quantizers used in dependent scalar quantization, in accordance with some examples. [Figure 12A] 1 is a diagram illustrating state transitions using a state machine in which four states are used in dependent scalar quantization, according to some examples. [Figure 12B] 12B is a table illustrating example quantizer selection in response to the state transitions of FIG. 12A in accordance with some examples. [Figure 13] 1 is a block diagram illustrating an example code prediction process in block-based video coding according to some implementations of this disclosure. [Figure 14] 1 is a diagram illustrating an example hypothesis generation based on a linear combination of templates according to some implementations of the present disclosure. [Figure 15A] 1 is a diagram illustrating an example implementation of an existing symbol prediction scheme, according to some examples. [Figure 15B] 1 is a diagram illustrating an example implementation of a vector-based code prediction scheme according to some implementations of the present disclosure. [Figure 16A] 11 is a diagram illustrating an example calculation of a left-diagonal cost function along a left-diagonal direction according to some implementations of the present disclosure. [Figure 16B] 11 is a diagram illustrating an example calculation of a right-diagonal cost function along a right-diagonal direction according to some implementations of the present disclosure. [Figure 17] 1 is a flow diagram of a method for capturing dominant gradient directions of neighboring samples of a reconstructed current block according to some implementations of the present disclosure. [Figure 18A] 1 is a diagram illustrating example template samples and gradient filter windows in gradient-based selection of sample extrapolation direction of a cost function, according to some implementations of the present disclosure. [Figure 18B] 1 is a diagram illustrating an example Histogram of Gradients (HoG) for gradient-based selection of sample extrapolation directions of a cost function, according to some implementations of the present disclosure. [Figure 19] 1 is a diagram illustrating a sign prediction area for predicting signs of transform coefficients according to some examples; [Figure 20A] 1 is a diagram illustrating example context modeling for transform coefficient sign prediction according to some implementations of the present disclosure. [Figure 20B] 1 is a diagram illustrating another example context modeling for transform coefficient sign prediction according to some implementations of the present disclosure. [Figure 21] 1 is a flow diagram of an example method for symbol prediction in block-based video coding according to some implementations of the present disclosure. [Figure 22] 1 is a flow diagram of an example video encoding method for transform coefficient sign prediction performed by a video encoder according to certain implementations of this disclosure. [Diagram 23] 4 is a flow diagram of an example video decoding method for transform coefficient sign prediction performed by a video decoder according to certain implementations of this disclosure. [Figure 24] FIG. 1 is a block diagram illustrating a computing environment coupled with a user interface according to some implementations of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Reference will now be made in detail to specific implementations. Examples of these specific implementations are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth to aid in understanding the subject matter provided herein. However, it will be apparent to one skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details. For example, it will be apparent to one skilled in the art that the subject matter presented herein may be implemented in any type of electronic device having digital video capabilities.

[0014] It should be explained that terms such as "first" and "second" used in this specification, claims and accompanying drawings of the present disclosure are used to distinguish objects and are not used to describe any particular order or sequence. It should be understood that the data used in this manner can be substituted for each other under appropriate conditions, and thus the embodiments of the present disclosure described herein may be implemented in an order other than that shown in the accompanying drawings or described in this disclosure.

[0015] 1 is a block diagram illustrating an example system 10 for encoding and decoding video blocks in parallel, according to some implementations of the present disclosure. As shown in FIG. 1, the system 10 includes a source device 12 that generates and encodes video data to be subsequently decoded by a destination device 14. The source device 12 and the destination device 14 may include any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, set-top boxes, digital televisions, cameras, displays, digital media players, video game consoles, or video streaming devices. In some implementations, the source device 12 and the destination device 14 include wireless communication capabilities.

[0016] In some implementations, the destination device 14 can receive the encoded video data to be decoded via a link 16. The link 16 can comprise any type of communication medium or device capable of sending the encoded video data from the source device 12 to the destination device 14. In one example, the link 16 can comprise a communication medium to enable 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) band or one or more physical transmission paths. The communication medium can form part of a packet-based network, such as a local area network, a wide area network, or a global network, such as the Internet. The communication medium can comprise a router, a switch, a base station, or any other equipment that can be useful in facilitating communication from the source device 12 to the destination device 14.

[0017] In some other implementations, the encoded video data may be transmitted from the output interface 22 to the storage device 32. The encoded video data in the storage device 32 may then be accessed by the destination device 14 via the input interface 28. The storage device 32 may comprise any of a variety of distributed or locally accessed data storage media, such as a hard drive, a Blu-ray disc, a digital versatile disc (DVD), a compact disc read-only memory (CD-ROM), a flash memory, a volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In a further example, the storage device 32 may correspond to a file server or another intermediate storage device capable of storing the encoded video data generated by the source device 12. The destination device 14 may access the stored video data by streaming or downloading from the storage device 32. The file server may be any type of computer capable of storing the encoded video data and transmitting the encoded video data to the destination device 14. Exemplary file servers include a web server (e.g., a web server for a website), a file transfer protocol (FTP) server, a network attached storage (NAS) device, or a local disk drive. Destination device 14 may access the encoded video data by any standard data connection, including a wireless channel (e.g., a Wireless Fidelity (Wi-Fi) connection), a wired connection (e.g., a Digital Subscriber Line (DSL), a cable modem, etc.), or any combination thereof suitable for accessing encoded video data stored on a file server. The transmission of the encoded video data from storage device 32 may be a streaming transmission, a download transmission, or a combination of both.

[0018] 1, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources such as a video capture device, e.g., a video camera, a video archive containing pre-captured video, a video distribution interface for receiving video data from a video content provider, and / or a computer graphics system for generating computer graphics data as the source video, or a combination of such sources. As an example, if video source 18 is a video camera of a security surveillance system, source device 12 and destination device 14 may include a camera phone or a video phone. However, implementations described in this disclosure may be applicable to video encoding in general and may be applied to wireless and / or wired applications.

[0019] The captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video data may be transmitted directly to destination device 14 via output interface 22 of source device 12. Additionally (or alternatively), the encoded video data may be stored in storage device 32 for later access by destination device 14 or other devices for decoding and / or playback purposes. Output interface 22 may further comprise a modem and / or a transmitter.

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

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

[0022] Video encoder 20 and video decoder 30 may operate according to a proprietary or industry standard, such as VVC, HEVC, MPEG-4, Part 10, AVC, or extensions of such standards. It should be understood that the present disclosure is not limited to a particular video encoding / decoding standard and may be applicable to other video encoding / decoding standards. In general, it is contemplated that video encoder 20 of source device 12 may be configured to encode video data according to any of the aforementioned current or future standards. Similarly, it is also contemplated that video decoder 30 of destination device 14 may be configured to decode video data according to any of the aforementioned current or future standards.

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

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

[0025] As shown in FIG. 2, the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a division unit 45, an intra prediction processing unit 46, and an intra block copy (BC) unit 48. In some implementations, the video encoder 20 further includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction. An in-loop filter 63, such as a deblocking filter, may be disposed between the adder 62 and the DPB 64 to filter block boundaries to remove block artifacts from the reconstructed video data. In addition to the deblocking filter, another in-loop filter, such as a SAO filter and / or an adaptive in-loop filter (ALF), may be used to filter the output of the adder 62. In some examples, the in-loop filter may be omitted, and the decoded video block may be provided directly to DPB 64 by summer 62. Video encoder 20 may be in the form of a non-programmable or programmable hardware unit, or may be split across one or more of the illustrated non-programmable or programmable hardware units.

[0026] Video data memory 40 may store video data to be encoded by components of video encoder 20. The video data in video data memory 40 may be obtained, for example, from video source 18 as shown in FIG. 1. DPB 64 is a buffer that stores reference video data (e.g., reference frames or pictures) for use in encoding the video data by video encoder 20 (e.g., in intra- or inter-predictive encoding modes). Video data memory 40 and DPB 64 may be formed by any of a variety of memory devices. In various examples, video data memory 40 may be on-chip with other components of video encoder 20 or off-chip with respect to other components of video decoder 20.

[0027] As shown in FIG. 2, after receiving the video data, a partitioning unit 45 in the prediction processing unit 41 partitions the video data into video blocks. This partitioning may also include partitioning the video frame into slices, tiles (e.g., a set of video blocks), or other larger coding units (CUs) according to a predefined partitioning structure, such as a quadtree (QT) structure associated with the video data. A video frame can be considered to be a two-dimensional array or matrix of samples having sample values, or such a two-dimensional array or matrix. The samples in the array are sometimes referred to as pixels or pels. A number of samples in the horizontal and vertical directions (or axes) of the array or picture define the size and / or resolution of the video frame. The video frame can be partitioned into multiple video blocks, for example, by using QT partitioning. Again, a video block can be considered to be a two-dimensional array or matrix of two-dimensional arrays or matrices of samples having smaller dimensions than a video frame but having sample values, or such a two-dimensional array or matrix. A number of samples in the horizontal and vertical directions (or axes) of a video block define the size of a video block. A video block may be further divided into one or more block partitions or sub-blocks (which may also form blocks), e.g., by repeatedly using QT partitioning, binary tree (BT) partitioning, ternary tree (TT) partitioning, or any combination thereof. It should be noted that the term "block" or "video block" as used herein may be a portion of a frame or picture, in particular a rectangular (square or non-square) portion. For HEVC and VVC, for example, a block or video block may be or correspond to a coding tree unit (CTU), CU, prediction unit (PU) or transform unit (TU), and / or may be or correspond to a corresponding block, e.g., a coding tree block (CTB), coding block (CB), prediction block (PB) or transform block (TB). Alternatively or in addition, a block or video block may be or correspond to a sub-block, such as a CTB, CB, PB, TB, etc.

[0028] Prediction processing unit 41 may select one of a number of possible predictive coding modes, such as one of a number of intra-predictive coding modes or one of a number of inter-predictive coding modes, for the current video block based on the error results (e.g., coding rate and level of distortion). Prediction processing unit 41 may provide the resulting intra- or inter-predictive coded block (e.g., a predictive block) to summer 50 to generate a residual block, and to summer 62 to reconstruct the coded block for later use as part of a reference frame. Prediction processing unit 41 also applies syntax elements, such as motion vectors, intra-mode indicators, partition information, and other such syntax information to entropy coding unit 56.

[0029] To select a suitable intra-prediction coding mode for the current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-prediction coding of the current video block relative to one or more neighboring blocks in the same frame as the current block to be encoded to perform spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 perform inter-prediction coding of the current video block relative to one or more predictive blocks in one or more reference frames to perform temporal prediction. Video encoder 20 may perform multiple encoding passes, e.g., to select a suitable coding mode for each block of video data.

[0030] In some implementations, motion estimation unit 42 determines the inter prediction mode for the current video frame by generating a motion vector that indicates the displacement of a video block in the current video frame relative to a predictive block in a reference frame in response to a predetermined pattern in the sequence of video frames. Motion estimation performed by motion estimation unit 42 may be a process of generating motion vectors that can estimate motion for a video block. The motion vector may indicate, for example, the displacement of a video block in a current video frame or picture relative to a predictive block in a reference frame. The predetermined pattern may designate a video frame in the sequence as a P frame or a B frame. Intra BC unit 48 may determine the block vector in a manner similar to vectors for intra BC coding, e.g., motion vectors determined by motion estimation unit 42 for inter prediction, or may utilize motion estimation unit 42 to determine the block vector.

[0031] A prediction block for a video block may be or may correspond to a block of a reference frame or a reference block that is interpreted as closely matching the video block to be encoded in terms of pixel differences, which may be determined by sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some implementations, video encoder 20 may calculate values ​​for sub-integer pixel locations of the reference frame stored in DPB 64. For example, video encoder 20 may interpolate values ​​for quarter-pixel, eighth-pixel, or other fractional pixel locations of the reference frame. Thus, motion estimation unit 42 may perform motion searches for unit and fractional pixel locations and output motion vectors with fractional pixel accuracy.

[0032] Motion estimation unit 42 calculates a motion vector for a video block in an inter-predictive coded frame by comparing the position of the video block to the position of a predictive block of a reference frame selected from a first reference frame list (List 0) or a second reference frame list (List 1), each of which identifies one or more reference frames stored in DPB 64. Motion estimation unit 42 sends the calculated motion vector to motion compensation unit 44 and then to entropy coding unit 56.

[0033] The motion compensation performed by motion compensation unit 44 may involve fetching or generating a predictive block based on the motion vector determined by motion estimation unit 42. Upon receiving the motion vector for a current video block, motion compensation unit 44 may locate the predictive block to which the motion vector points in one of the reference frame lists, retrieve the predictive block from DPB 64, and send the forward predicted block to summer 50. Summer 50 then forms a residual block of pixel difference values ​​by subtracting pixel values ​​of the predictive block provided by motion compensation unit 44 from pixel values ​​of the current video block being coded. The pixel difference values ​​forming the residual block may include luma or chroma difference components, or both. Motion compensation unit 44 may also generate syntax elements associated with the video blocks of the video frames for use by video decoder 30 in decoding the video blocks of the video frames. The syntax elements may include, for example, syntax elements that define the motion vector used to identify the predictive block, any flags indicating a prediction mode, or any other syntax information described herein. Note that motion estimation unit 42 and motion compensation unit 44 may be incorporated together, but are shown separately in FIG. 2 for conceptual purposes.

[0034] In some implementations, the intra BC unit 48 may generate vectors and fetch predictive blocks in a manner similar to that described above with respect to the motion estimation unit 42 and the motion compensation unit 44, but where the predictive block is the same frame as the current block being coded, and the vectors are referred to as block vectors in contrast to motion vectors. In particular, the intra BC unit 48 may determine an intra prediction mode to be used to code the current block. In some examples, the intra BC unit 48 may code the current block using various intra prediction modes, e.g., during separate coding passes, and test the performance by rate-distortion analysis. The intra BC unit 48 may then select an appropriate intra prediction mode to be used from among the various tested intra prediction modes, and generate an intra mode indicator accordingly. For example, the intra BC unit 48 may calculate rate-distortion values ​​using the rate-distortion analysis for the various tested intra prediction modes, and select the intra prediction mode with the best rate-distortion characteristics among the tested modes as the appropriate intra prediction mode to be used. The rate-distortion analysis roughly determines the amount of distortion (or error) between a coded block and the original uncoded block that was coded to generate the coded block, and the bitrate (i.e., number of bits) used to generate the coded block. Intra BC unit 48 may calculate ratios from the distortions and rates for the various coded blocks to determine which intra prediction mode exhibits the best rate-distortion value for the block.

[0035] In other examples, intra BC unit 48 may use all or a portion of motion estimation unit 42 and motion compensation unit 44 to perform the aforementioned functions for intra BC prediction according to implementations described herein. In either case, for intra block copying, the predictive block may be a block that is interpreted as closely matching the block to be coded in terms of pixel differences, which may be determined by SAD, SSD, or other difference metrics, and identifying the predictive block may include computing values ​​of sub-integer pixel positions.

[0036] Regardless of whether the predictive block is derived from the same frame according to intra prediction or a different frame according to inter prediction, video encoder 20 may form a residual block by subtracting pixel values ​​of the predictive block from pixel values ​​of the current video block being encoded to form pixel difference values. The pixel difference values ​​that form the residual block may include both luma and chroma component differences.

[0037] Intra-prediction processing unit 46 may intra-predict the current video block as an alternative to inter prediction performed by motion estimation unit 42 and motion compensation unit 44 or intra block copy prediction performed by intra BC unit 48, as described above. In particular, intra-prediction processing unit 46 may determine an intra-prediction mode to use to encode the current block. For example, intra-prediction processing unit 46 may encode the current block using various intra-prediction modes, e.g., during separate encoding passes, and intra-prediction processing unit 46 (or in some examples, a mode selection unit) may select an appropriate intra-prediction mode to use from the tested intra-prediction modes. Intra-prediction processing unit 46 may provide information indicative of the selected intra-prediction mode for the block to entropy coding unit 56. Entropy coding unit 56 may encode the information indicative of the selected intra-prediction mode into the bitstream.

[0038] After prediction processing unit 41 determines a predictive block for a current video block by inter- or intra-prediction, summer 50 forms a residual block by subtracting the predictive block from the current video block. The residual video data in the residual block, which may be included in one or more TUs, is provided to transform processing unit 52. Transform processing unit 52 converts the residual video data into transform coefficients using a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform.

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

[0040] After quantization, entropy coding unit 56 may encode the quantized transform coefficients into a video bitstream using an entropy coding technique, such as context adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), syntax-based context adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding method or technique. The encoded bitstream may then be transmitted to video decoder 30 shown in FIG. 1 or archived to storage device 32 shown in FIG. 1 for later transmission or retrieval by video decoder 30. Entropy coding unit 56 may also encode motion vectors and other syntax elements for the current video frame being coded using an entropy coding technique.

[0041] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain to generate a reference block for prediction of other video blocks. In this way, a reconstructed residual block may be generated. As described above, motion compensation unit 44 may generate a motion compensated prediction block from one or more reference blocks of a frame stored in DPB 64. Motion compensation unit 44 may also apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values ​​for use in motion estimation.

[0042] Summer 62 adds the reconstructed residual block to the motion compensated predictive block produced by motion compensation unit 44 to generate a reference block for storage in DPB 64. The reference block may then be used by intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 as a predictive block to inter predict another video block in a subsequent video frame.

[0043] 3 is a block diagram illustrating an example video decoder 30 according to some implementations of the present application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra prediction unit 84, and an intra BC unit 85. The video decoder 30 may perform a decoding process that is generally the reverse of the encoding process described above for the video encoder 20 in connection with FIG. 2. For example, the motion compensation unit 82 may generate prediction data based on a motion vector received from the entropy decoding unit 80, while the intra prediction unit 84 may generate prediction data based on an intra prediction mode received from the entropy decoding unit 80.

[0044] In some examples, the units of the video decoder 30 may be tasked to perform implementations of the present application. Furthermore, in some examples, implementations of the present disclosure may be divided among one or more of the units of the video decoder 30. For example, the intra BC unit 85 may perform implementations of the present application alone or in combination with other units of the video decoder 30, such as the motion compensation unit 82, the intra prediction unit 84, and the entropy decoding unit 80. In some examples, the video decoder 30 may not include an intra BC unit 85, and the functions of the intra BC unit 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82.

[0045] The video data memory 79 may store video data, such as an encoded video bitstream, to be decoded by other components of the video decoder 30. The video data stored in the video data memory 79 may be obtained, for example, from the storage device 32, from a local video source, such as a camera, via wired or wireless network communication of the video data, or by access to a physical data storage medium (e.g., a flash drive or hard disk). The video data memory 79 may include a coded picture buffer (CPB) that stores the coded video data from the coded video bitstream. The DPB 92 of the video decoder 30 stores reference video data for use in the decoding of the video data by the video decoder 30 (e.g., in intra- or inter-prediction coding modes). The video data memory 79 and the DPB 92 may be formed by any of a variety of memory devices, such as dynamic random access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and the DPB 92 are shown in FIG. 3 as two different components of the video decoder 30. However, it will be apparent to one skilled in the art that video data memory 79 and DPB 92 may be provided by the same memory device or by separate memory devices. In some examples, video data memory 79 may be on-chip with other components of video decoder 30, or may be off-chip with respect to other components of video decoder 30.

[0046] During the decoding process, video decoder 30 receives an encoded video bitstream representing video blocks of encoded video frames and associated syntax elements. Video decoder 30 may receive the syntax elements at the video frame level and / or the video block level. Entropy decoding unit 80 of video decoder 30 decodes the bitstream using entropy decoding techniques, which may result in quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Entropy decoding unit 80 then sends the motion vectors or intra-prediction mode indicators and other syntax elements to prediction processing unit 81.

[0047] If a video frame is coded as an intra-prediction coded (e.g., I) frame, or coded for intra-coded predictive blocks in other types of frames, intra prediction unit 84 of prediction processing unit 81 may generate predictive data for video blocks of the current video frame based on the signaled intra-prediction mode and reference data from previously decoded blocks of the current frame.

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

[0049] In some examples, when a video block is encoded according to the intra BC modes described herein, intra BC unit 85 of prediction processing unit 81 generates a predictive block for the current video block based on the block vectors and other syntax elements received from entropy decoding unit 80. The predictive block may be within the same reconstructed region of the picture as the current video block being processed by video encoder 20.

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

[0051] Similarly, intra BC unit 85 may use some of the received syntax elements, e.g., flags, to determine that the current video block was predicted using intra BC mode, configuration information regarding which video blocks of the frame are included in the reconstructed region and should be stored in DPB 92, block vectors for each of the video blocks of the intra BC predicted frame, intra BC prediction status for each of the video blocks of the intra BC predicted frame, and other information for decoding the video blocks in the current video frame.

[0052] Motion compensation unit 82 may also perform interpolation using an interpolation filter, such as one used by video encoder 20 during encoding of the video block, to calculate interpolated values ​​of sub-integer pixels of the reference block. In this case, motion compensation unit 82 may determine the interpolation filter used by video encoder 20 from the received syntax elements and use the interpolation filter to generate the predictive block.

[0053] Inverse quantization unit 86 inverse quantizes the quantized transform coefficients provided in the bitstream and decoded by entropy decoding unit 80 using the same quantization parameters calculated by video encoder 20 for each video block in a video frame to determine the degree of quantization. Inverse transform processing unit 88 applies an inverse transform, such as an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process, to the transform coefficients in order to reconstruct the residual block in the pixel domain.

[0054] After motion compensation unit 82 or intra BC unit 85 generates a predictive block for the current video block based on the vectors and syntax elements, summer 90 reconstructs a decoded video block for the current video block by summing the residual block from inverse transform processing unit 88 and the corresponding predictive block generated by motion compensation unit 82 and intra BC unit 85. The decoded video block may also be referred to as a reconstructed block for the current video block. An in-loop filter 91, such as a deblocking filter, an SAO filter, and / or an ALF, may be disposed between summer 90 and DPB 92 to further process the decoded video block. In some examples, in-loop filter 91 may be omitted and the decoded video block may be provided directly to DPB 92 by summer 90. The decoded video blocks in a given frame are then stored in DPB 92, which stores reference frames that are later used to motion compensate subsequent video blocks. DPB 92, or a memory device separate from DPB 92, may also store the decoded video for later display on a display device, such as display device 34 of FIG.

[0055] In a typical video encoding process (e.g., including a video encoding process and a video decoding process), a video sequence generally includes an ordered set of frames or pictures. Each frame may include three sample arrays, denoted as SL, SCb, and SCr. SL is a two-dimensional array of luma samples. SCb is a two-dimensional array of Cb chroma samples. SCr is a two-dimensional array of Cr chroma samples. In other cases, a frame may be monochrome and thus includes only one two-dimensional array of luma samples.

[0056] As shown in FIG. 4A, video encoder 20 (or, more precisely, splitting unit 45) generates a representation of an encoded frame by first splitting the frame into a set of CTUs. A video frame may include an integer number of CTUs arranged consecutively from left to right and top to bottom in raster scan order. Each CTU is the largest logical coding unit, and the width and height of the CTU are signaled by video encoder 20 in the sequence parameter set, resulting in all CTUs in a video sequence having the same size, which is one of 128×128, 64×64, 32×32, and 16×16. However, it should be noted that CTUs of this disclosure are not necessarily limited to a particular size. As shown in FIG. 4B, each CTU may include one CTB of luma samples, a corresponding coding tree block of two chroma samples, and syntax elements used to code the samples of the coding tree block. The syntax elements describe the properties of various types of units of coding blocks of pixels and how the video sequence may be reconstructed at video decoder 30, including inter or intra prediction, intra prediction modes, motion vectors, and other parameters. In a monochrome picture or a picture with three different color planes, a CTU may include syntax elements used to code a single coding tree block and samples of the coding tree block. A coding tree block may be an N×N block of samples.

[0057] To achieve better performance, video encoder 20 may recursively perform tree partitioning, such as binary tree partitioning, ternary tree partitioning, quad tree partitioning, or a combination thereof, on the coding tree blocks of the CTU to partition the CTU into smaller CUs. As shown in FIG. 4C, 64×64 CTU 400 is first partitioned into four smaller CUs, each with a block size of 32×32. Among the four smaller CUs, CU 410 and CU 420 are each partitioned into four CUs with a block size of 16×16. Two 16×16 CUs 430 and 440 are each further partitioned into four CUs with a block size of 8×8. FIG. 4D shows a quad tree data structure illustrating the final result of the partitioning process of CTU 400 shown in FIG. 4C, where each leaf node of the quad tree corresponds to one CU, each with a size ranging from 32×32 to 8×8. Similar to the CTU shown in FIG. 4B, each CU may include a CB of luma samples and two coding blocks of chroma samples of the corresponding same-sized frame, as well as syntax elements used to code the coding block samples. In a monochrome picture or a picture with three different color planes, a CU may include a single coding block and syntax structures used to code the coding block samples. It should be noted that the quadtree partitioning shown in FIG. 4C and FIG. 4D is only for illustration, and one CTU can be divided into CUs based on quadtree / ternary tree / binary tree partitions to accommodate different local characteristics. In a multi-tree structure, one CTU is divided by a quadtree structure, and each quadtree leaf CU can be further divided by binary tree and ternary tree structures. As shown in FIG. 4E, there are multiple possible partitioning schemes of a coding block with width W and height H, namely, quad partitioning, vertical bisection, horizontal bisection, vertical trisection, vertical extended trisection, horizontal extended trisection, and horizontal extended trisection.

[0058] In some implementations, video encoder 20 may further divide the coding blocks of a CU into one or more M×N PBs. A PB may include rectangular (square or non-square) blocks of samples to which the same inter or intra prediction is applied. A PU of a CU may include a PB of luma samples, two PBs of corresponding chroma samples, and syntax elements used to predict the PB. In a monochrome picture or a picture with three different color planes, a PU may include a single PB and syntax structures used to predict the PB. Video encoder 20 may generate predicted luma, Cb, and Cr blocks for the luma, Cb, and Cr PBs of each PU of a CU.

[0059] Video encoder 20 may generate predictive blocks for a PU using intra prediction or inter prediction. If video encoder 20 generates predictive blocks for a PU using intra prediction, video encoder 20 may generate predictive blocks for the PU based on decoded samples of a frame associated with the PU. If video encoder 20 generates predictive blocks for a PU using inter prediction, video encoder 20 may generate predictive blocks for the PU based on decoded samples of one or more frames other than the frame associated with the PU.

[0060] After video encoder 20 generates the predictive luma, Cb, and Cr blocks for one or more PUs of a CU, video encoder 20 may generate a luma residual block of the CU by subtracting the predictive luma block of the CU from the original luma coding block of the CU, 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 coding block of the CU. Similarly, video encoder 20 may generate a Cb residual block and a Cr residual block of the CU, respectively, such that each sample in the Cb residual block of the CU indicates a difference between a Cb sample in one of the predictive Cb blocks of the CU and a corresponding sample in the original Cb coding block of the CU, and each sample in the Cr residual block of the CU may indicate a difference between a Cr sample in one of the predictive Cr blocks of the CU and a corresponding sample in the original Cr coding block of the CU.

[0061] Further, as shown in FIG. 4C, video encoder 20 may use quadtree partitioning to decompose the luma, Cb, and Cr residual blocks of a CU into one or more luma, Cb, and Cr transform blocks, respectively. A transform block may include a rectangular (square or non-square) block of samples to which the same transform is applied. A TU of a CU may include a transform block of luma samples, two transform blocks of corresponding chroma samples, and syntax elements used to transform the transform block samples. Thus, each TU of a CU may 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 a TU may be a sub-block of the luma residual block of the CU. The Cb transform block may be a sub-block of the Cb residual block of the CU. The Cr transform block may be a sub-block of the Cr residual block of the CU. In monochrome pictures or pictures with three separate color planes, a TU may include a single transform block and syntax structures used to transform samples of the transform block.

[0062] Video encoder 20 may apply one or more transforms to a luma transform block of the TU to generate a luma coefficient block for the TU. The coefficient block may be a two-dimensional array of transform coefficients. The transform coefficients may be scalar quantities. Video encoder 20 may apply one or more transforms to a Cb transform block of the TU to generate a Cb coefficient block for the TU. Video encoder 20 may apply one or more transforms to a Cr transform block of the TU to generate a Cr coefficient block for the TU.

[0063] After generating a coefficient block (e.g., a luma coefficient block, a Cb coefficient block, or a Cr coefficient block), the video encoder 20 may quantize the coefficient block. Quantization generally refers to a process of quantizing transform coefficients to potentially reduce the amount of data used to represent the transform coefficients and achieve further compression. After the video encoder 20 quantizes the coefficient block, the video encoder 20 may apply entropy coding techniques to encode syntax elements indicating the quantized transform coefficients. For example, the video encoder 20 may perform CABAC on the syntax elements indicating the quantized transform coefficients. Finally, the video encoder 20 may output a bitstream including a sequence of bits forming a representation of the encoded frame and associated data, which may be stored in the storage device 32 or transmitted to the destination device 14.

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

[0065] As mentioned above, video coding mainly uses two modes, intra-frame prediction (or intra-prediction) and inter-frame prediction (or inter-prediction), to achieve video compression. Note that intra-block copy (IBC) can be interpreted as intra-frame prediction or a third mode. Of the two modes, inter-frame prediction contributes more to coding efficiency than intra-frame prediction by virtue of using motion vectors to predict a current video block from a reference video block.

[0066] However, with the continuous improvement of video data capture technology and the refinement of video block sizes for storing details in video data, the amount of data required to represent the motion vector for the current frame also increases significantly. One way to overcome this difficulty is to benefit from a group of neighboring CUs not only having similar video data for prediction in both spatial and temporal domains, but also having similar motion vectors between these neighboring CUs. Therefore, the motion information of spatially neighboring CUs and / or temporally co-located CUs can be used as an approximation of the motion information (e.g., motion vector) of the current CU by searching for spatial and temporal correlation, and this approximation is also called the "motion vector predictor (MVP)" of the current CU.

[0067] Instead of encoding the actual motion vector of the current CU into the video bitstream (e.g., the apparent motion vector is determined by motion estimation unit 42, as described above with respect to FIG. 2), the motion vector predictor of the current CU is subtracted from the apparent motion vector of the current CU to generate a motion vector differential (MVD) for the current CU. In this manner, motion vectors for each CU of the frame, as determined by motion estimation unit 42, do not need to be encoded and included in the video bitstream, and the amount of data used to represent motion information in the video bitstream can be significantly reduced.

[0068] Similar to the process of selecting a predictive block in a reference frame during inter-frame prediction of a code block, after constructing a motion vector candidate list (also known as a "merge list") for a current CU using possible candidate motion vectors associated with spatially neighboring CUs and / or temporally co-located CUs of the current CU, a set of rules can be adopted by both the video encoder 20 and the video decoder 30 to select one member from the motion vector candidate list as a motion vector predictor for the current CU. By doing so, there is no need to transmit the motion vector candidate list itself from the video encoder 20 to the video decoder 30, and the index of the motion vector predictor in the selected motion vector candidate list is sufficient for the video encoder 20 and the video decoder 30 to use the same motion vector predictor in the motion vector candidate list for encoding and decoding the current CU. Therefore, only the index of the selected motion vector predictor needs to be transmitted from the video encoder 20 to the video decoder 30.

[0069] Herein, a brief description is provided on transform coefficient coding in a block-based video coding process (e.g., Enhanced Compression Model (ECM)). Specifically, each transform block is first divided into multiple coefficient groups (CG), each of which includes transform coefficients of 4×4 sub-blocks for luma components and transform coefficients of 2×2 sub-blocks for chroma components. The coding of transform coefficients in a transform block is performed in units of coefficient groups. For example, the coefficient groups within a transform block are scanned and coded based on a first predetermined scanning order. When coding each coefficient group, the transform coefficients of the coefficient group are scanned within each sub-block based on a second predetermined scanning order. In ECM, the same top-left scanning order is applied to scan the coefficient groups within a transform block and the different transform coefficients within each coefficient group (e.g., both the first predetermined scanning order and the second predetermined scanning order are top-left scanning orders). FIG. 5 is a diagram illustrating the top-left scanning order of transform coefficients within a coefficient group according to some examples. Numbers 0-15 in FIG. 5 indicate respective scanning orders of transform coefficients within corresponding coefficient groups.

[0070] According to the transform coefficient coding scheme in ECM, first, for each transform block, a flag is signaled indicating whether the transform block contains any non-zero transform coefficient. If there are at least non-zero transform coefficients in the transform block, the position of the last non-zero transform coefficient scanned according to the top-left scanning order is explicitly signaled from the video encoder 20 to the video decoder 30. By signaling the position of the last non-zero transform coefficient, flags for all coefficient groups coded before the last coefficient group (i.e., the coefficient group containing the last non-zero coefficient) are further signaled. Correspondingly, the number of flags indicates whether each coefficient group contains a non-zero transform coefficient. If the flag of the coefficient group is equal to 0 (indicating that all transform coefficients in the coefficient group are 0), no further information about the coefficient group needs to be transmitted. Otherwise (e.g., if the flag of the coefficient group is equal to 1), the absolute value and sign of each of the transform coefficients in the coefficient group are signaled in the bitstream according to the scanning order. However, in existing designs, the signs of the transform coefficients are bypass coded (e.g., the context model is not applied), making the transform coding of the current design inefficient. According to the present disclosure, an improved LFNST process that uses sign prediction of the transform coefficients to improve the transform coding efficiency is described in more detail below.

[0071] FIG. 6 is a diagram illustrating an LFNST process according to some examples. In VVC, a secondary transform tool (e.g., LFNST) is applied to compress the energy of transform coefficients of an intra-coded block after a primary transform. As shown in FIG. 6, a forward LFNST 604 is applied between a forward primary transform 603 and a quantization 605 in the video encoder 20, and an inverse LFNST 608 is applied between an inverse quantization 607 and an inverse primary transform 609 in the video decoder 30. For example, an LFNST process may include both a forward LFNST 604 and an inverse LFNST 608. As some examples, for a 4×4 forward LFNST 604, there may be 16 input coefficients, for an 8×8 forward LFNST 604, there may be 64 input coefficients, for a 4×4 inverse LFNST 608, there may be 8 input coefficients, and for an 8×8 inverse LFNST 608, there may be 16 input coefficients.

[0072] In the forward LFNST 604, a non-separable transform is applied using different transform sizes based on the size of the coding block that can be represented using a matrix multiplication process. For example, assume that the forward LFNST 604 is applied to a 4×4 block. The samples in the 4×4 block can be represented using the matrix X shown in equation (1) below.

number

[0073] The matrix X is shown in the following formula (2): It can be serialized as JPEG2024546895000003.jpg1551.

number

[0074] In the above formula (1) or (2), X represents the coefficient matrix obtained by the forward linear transform 603, and X ij Let x denote the linear transform coefficients in matrix X. Then, the forward LFNST 604 is applied according to equation (3) below.

Number

[0075] JPEG2024546895000006.jpg45166

[0076] In some implementation forms, a reduced non-separable transform kernel can be applied in the LFNST process. For example, based on the above formula (3), the forward LFNST 604 is based on a direct matrix multiplication that is costly in terms of computational operations and memory resources for storing transform coefficients. Therefore, the reduced non-separable transform kernel can be used in the LFNST design to reduce the implementation cost of the LFNST process by mapping an N-dimensional vector to an R-dimensional vector in a different space of R < N. For example, instead of using an N×N matrix for the transform kernel, an R×N matrix is used as the transform kernel in the forward LFNST 604 shown in formula (4).

Number

[0077] In the above formula (4), the R basis vectors in TR×N are generated by selecting the first R basis of the original N-dimensional transform kernel (i.e., N×N). Further, since TR×N is orthogonal, the inverse transform matrix for the inverse LFNST 608 is the transpose of the forward transform matrix TR×N.

[0078] For 8×8 LFNST, when coefficients N / R=4 are applied, the 64×64 transform matrix is ​​reduced to a 16×48 transform matrix in the case of forward LFNST 604, and the 64×64 inverse transform matrix is ​​reduced to a 48×16 inverse transform matrix for inverse LFNST 608. This is achieved by applying the LFNST process to the 8×8 sub-block in the top-left region of the primary transform coefficients. Specifically, when 16×48 forward LFNST is applied, 48 transform coefficients from the three 4×4 sub-blocks in the top-left 8×8 sub-block (excluding the bottom-right 4×4 sub-block) are utilized as input. In some examples, the LFNST process is restricted to be applicable only when all transform coefficients outside the top-left 4×4 sub-block are zero. This implies that when LFNST is applied, all of the primary-only transform coefficients must be zero. Furthermore, to control the worst-case complexity (in terms of multiplications per pixel), the LFNST matrices for 4x4 and 8x8 coded blocks are forced to undergo 8x16 and 8x48 transforms, respectively. For 4xM and Mx4 coded blocks (M>4), the non-separable transform matrix of the LFNST is 16x16.

[0079] In LFNST transform signaling, there are a total of four transform sets, and two non-separable transform kernels per transform set are enabled in the LFNST design. A transform set is selected from the four transform sets according to the intra prediction mode of the intra block. The mapping from intra prediction mode to transform set is pre-determined as shown in Table 1 below. If one of the three Cross Component Linear Model (CCLM) modes (e.g., inTRA_LT_CCLM, inTRA_T_CCLM, or INTRA_L_CCLM) is used for the current block (81≦predModeIntra≦83), transform set "0" is selected for the current chroma block. For each transform set, the selected non-separable secondary transform candidate is indicated by signaling an LFNST index in the bitstream. [Table 1]

[0080] In some examples, since LFNST is restricted to be applied to intra blocks when all transform coefficients outside the first 16x16 sub-block are zero, the signaling of the LFNST index depends on the position of the last significant (i.e., non-zero) transform coefficient. For example, for 4x4 and 8x8 coding blocks, the LFNST index is signaled only if the position of the last significant transform coefficient is less than 8. For other coding block sizes, the LFNST index is signaled only if the position of the last significant transform coefficient is less than 16. Otherwise (i.e., the LFNST index is not signaled), the LFNST index is inferred to be 0, i.e., LFNST is disabled.

[0081] Furthermore, to reduce the size of the buffer for caching transform coefficients, LFNST is not allowed if the width or height of the currently coded block signaled in the sequence parameter set (SPS) is larger than the maximum transform size (i.e., 64). Meanwhile, LFNST is only applied when the primary transform is DCT2. In addition, LFNST is applied to intra-coded blocks for both luma and chroma components in both intra and inter slices. If dual tree or local tree is enabled (when the partitions of the luma and chroma components do not match), LFNST indexes are signaled separately for the luma and chroma components (i.e., the luma and chroma components can apply different LFNST transforms). Otherwise, if a single tree is applied (when the partitions of the luma and chroma components match), a single LFNST index is signaled and LFSNT is applied only to the luma component.

[0082] The LFNST design in ECM is similar to that in VVC, except that an additional LFNST kernel is introduced to improve the energy compaction of residual samples with large block size. Strictly speaking, if the width or height of the transform block is not smaller than 16, the new LFNST transform is introduced in the top-left region of the low-frequency transform coefficients generated from the primary transform. In the current ECM, as shown in FIG. 7, the low-frequency region includes the six 4×4 sub-blocks (e.g., the six 4×4 sub-blocks shown in gray in FIG. 7A) in the top-left corner of the primary transform coefficients. In this case, the number of coefficient inputs to the forward LFNST 604 is 96. Furthermore, to control the worst-case computational complexity, the number of coefficient outputs of the forward LFNST 604 is set to 32.

[0083] Strictly speaking, for a W×H transform block, where W≧16 and H≧16, a 32×96 forward LFNST is applied, taking the transform coefficients of six 4×4 sub-blocks 96 in the top-left region as input, and outputting 32 transform coefficients. On the other hand, the 8×8 LFNST in ECM takes the transform coefficients in all four 4×4 sub-blocks as input, and outputs 32 transform coefficients (i.e., a 32×64 matrix for forward LFNST 604 and a 64×32 matrix for inverse LFNST 608). This differs from VVC, where the 8×8 LFNST is only applied to three 4×4 sub-blocks in the top-left region, producing only 16 transform coefficients (i.e., a 16×48 matrix for forward LFNST 604 and a 48×16 matrix for inverse LFNST 608). Furthermore, the total number of LFNST sets increases from 4 in VVC to 35 in ECM. Similar to VVC, the selection of an LFNST set depends on the intra prediction mode of the current coding unit, and each LFNST set contains three different transform kernels.

[0084] In some examples, in addition to the DCT2 transform used in HEVC, a multiple transform selection (MTS) scheme is applied to transform the residuals of both inter-coded and intra-coded blocks. The MTS scheme uses multiple transforms selected from the DCT8 and DST7 transforms.

[0085] For example, two control flags are specified at the sequence level to enable the MTS scheme for intra and inter modes separately. When the MTS scheme is enabled at the sequence level, another CU level flag is further signaled to indicate whether the MTS scheme is applied or not. In some implementations, the MTS scheme is only applied to the luma component. Furthermore, the MTS scheme is only signaled when the following conditions are met: (a) both the width and height are less than or equal to 32, and (b) the coded block flag (CBF) is equal to 1. If the MTS CU flag is equal to 0, DCT2 is applied in both the horizontal and vertical directions. If the MTS CU flag is equal to 1, two other flags are additionally signaled to indicate the transform scheme for the horizontal and vertical directions, respectively. The mapping between the MTS horizontal control flag and the MTS vertical control flag and the applied transform is shown in Table 2 below. [Table 2]

[0086] Regarding the precision of the transform matrix, all MTS transform coefficients are 6-bit precision, which is the same as the DCT2 core transform. Since VVC supports all transform sizes used in HEVC, all transform cores used in HEVC, including 4-point, 8-point, 16-point and 32-point DCT-2 transform and 4-point DST-7 transform, are kept the same as VVC. Meanwhile, in the VVC transform design, other transform cores are additionally supported, including 64-point DCT-2, 4-point DCT-8, 8-point, 16-point, 32-point DST-7 and DCT-8. Furthermore, in order to reduce the complexity of DST-7 and DCT-8, which have large sizes, in DST-7 and DCT-8 transform blocks, when the width or height is equal to 32, the high-frequency transform coefficients located outside the 16×16 low-frequency region are set to 0 (also known as zero-out).

[0087] In VVC, other than DCT2, only DST7 and DCT8 transform kernels are used for intra-coding and inter-coding. For intra-coding, the statistical properties of the residual signal usually depend on the intra-prediction mode. An additional linear transform may be beneficial to handle the diversity of residual properties.

[0088] In ECM, additional primary transforms including DCT5, DST4, DST1 and identity transform (IDT) are adopted. Furthermore, an MTS set is created according to TU size and intra-mode information. There are 16 different TU sizes, and for each TU size, there are 5 different classes according to intra-mode information. For each class, there are 4 different transform pairs (same as in VVC). There are a total of 80 different classes, but some of these different classes often share the same transform set. Therefore, there are 58 (less than 80) unique entries in the look-up table (LUT).

[0089] For angular modes, joint symmetry with respect to TU shape and intra prediction is considered. Thus, mode i (i>34) with TU shape A×B may be mapped to the same class corresponding to mode j=(68-i) with TU shape B×A. However, for each transform pair, the orders of the horizontal and vertical transform kernels are swapped. For example, a 16×4 block with mode 18 (horizontal prediction) and a 4×16 block with mode 50 (vertical prediction) are mapped to the same class with swapped vertical and horizontal transform kernels. For wide-angle modes, the closest conventional angular mode is used to determine the transform set. For example, mode 2 is used for all modes between -2 and -14. Similarly, mode 66 is used for modes 67 to 80.

[0090] Intra template matching prediction is an example of an intra prediction mode that copies a prediction block from the reconstructed part of the current frame where the L-shaped template matches the current template. For a given search range, the video encoder 20 searches for the template that is most similar to the current template (e.g., based on SAD cost) in the reconstructed part of the current frame and uses the corresponding block as the prediction block. Then, the video encoder 20 signals the use of this mode, and the same prediction operation is performed at the decoder side. The prediction signal is generated by matching the L-shaped temporary neighbor of the current block with another block in a given search area, as shown in FIG. 8, which includes (a) the current CTU (R1), (b) the top-left CTU (R2), (c) the top CTU (R3), and (d) the left CTU (R4). Intra template matching is enabled for CUs with a size of width and height equal to or less than 64. Meanwhile, the intra template matching prediction mode is indicated by signaling a flag at the CU level. If intra template matching is applied to a coding block with width or height between 4 and 16 (inclusive), the temporary transform applied to the corresponding dimension is set to DCT-VII. Otherwise (i.e., if the width or height is smaller than 4 or larger than 16), DCT-II is applied to said dimension.

[0091] FIG. 9 is a diagram illustrating an exemplary process of code prediction according to some examples. In some implementations, code prediction may be performed to estimate the code of a transform coefficient in a transform block from samples of neighboring blocks. The correctness of the estimated code may be coded according to a context model to indicate whether the code prediction is correct. For example, in one context model, the difference between each estimated code may be coded, and a true code with a corresponding "0" (or "1") indicates that the estimated code is the same (or not the same) as the true code. If the codes can be accurately estimated a high percentage of the time (e.g., 90% or 95% of the codes are correctly estimated), the difference between the estimated code and the true code tends to be 0, and such a difference may be efficiently entropy coded by CABAC compared to the bypass coded code for transform coefficients in VVC. According to the present disclosure, the correctness of the code prediction may be entropy coded using other context models to further improve coding efficiency. The above other exemplary context models are described in more detail below.

[0092] In general, there is a high correlation between samples at the boundary between the current block and the neighboring blocks, which can be exploited by a sign prediction scheme to predict the signs of the transform coefficients of the current block. As shown in Figure 9, assume that there are M non-zero transform coefficients (where the M signs are + or - respectively) in the current block. Then, the total number of possible code combinations is 2 M The code prediction scheme uses each code combination to generate a corresponding hypothesis (e.g., reconstructed samples at the top and left boundaries of the current block), and compares the reconstructed samples in the corresponding hypothesis with extrapolated samples from adjacent blocks to obtain a sample difference (e.g., SSD or SAD) between the reconstructed and extrapolated samples. (There are two possible M The code combination that minimizes the sample difference (among the code combinations) is selected as the predictive code in the current block.

[0093] 9, to generate a corresponding hypothesis for each of the M code combinations, the corresponding M transform coefficients may be processed by an inverse quantization operation and an inverse transform to obtain residual samples, which may be added with the prediction samples to obtain reconstructed samples, including reconstructed samples on the top and left boundaries of the current block (shown in the L-shaped gray area 902).

[0094] In some implementations, a cost function that measures the spatial discontinuity between samples at the boundary between the current block and the neighboring block is used for the code combination selection. Instead of using the L2 norm (SSD), the cost function may be based on the L1 norm (SAD) shown in Equation (5) below.

number

[0095] In the above formula (5), B i,n (where i=-2,-1) represents the neighboring samples of the current block from the upper neighboring block. C m,j (where j=-2,-1) represents the neighboring samples of the current block from the left neighboring block. P n,0 and P m,0 Let N denote the reconstructed corresponding samples on the top and left boundaries of the current block, respectively. N and M denote the width and height of the current block, respectively. Figure 10 shows the corresponding samples P n,0 and P m,0 And the corresponding sample B of the adjacent block i,n and C m,j Shows.

[0096] In some implementations, a template-based hypothesis reconstruction method can be applied to the code prediction scheme to avoid the complexity of performing multiple inverse transforms. Each template can be a set of reconstructed samples on the upper and left boundaries of the current block, and can be obtained by applying an inverse transform to a coefficient matrix in which certain coefficients are set to 1 but all other coefficients are equal to 0. Since the inverse transform (e.g., DCT, DST) is linear, the corresponding hypothesis can be generated by a linear combination of a set of pre-computed templates.

[0097] In some implementations, the predictive codes are grouped into two sets, each set coded by a single CABAC context, for example, the first set includes predictive codes for transform coefficients in the upper left corner of a transform block, and the second set includes predictive codes for transform coefficients in all other transform block locations.

[0098] Similar to HEVC, scalar quantization is also used in VVC. In some implementations, scalar quantization in VVC may be implemented as dependent scalar quantization. Dependent scalar quantization refers to an approach in which the set of allowable reconstructed values ​​of a transform coefficient depends on the value of the transform coefficient level preceding the current transform coefficient level in the reconstruction order. The main effect of this approach is that allowable reconstructed vectors are packed more densely in an N-dimensional vector space (N represents the number of transform coefficients in a transform block) compared to the conventional dependent scalar quantization used in HEVC. That is, given the average number of allowable reconstructed vectors per N-dimensional unit volume, the average distortion between an input vector and the nearest reconstructed vector is reduced.

[0099] Dependent scalar quantization may be implemented by (a) defining two scalar quantizers with different reconstruction levels and (b) defining a process for switching between the two scalar quantizers. FIG. 11 shows two example scalar quantizers used in dependent scalar quantization of VVC according to some implementations of this disclosure. As shown in FIG. 11, in the quantization design of VVC, two scalar quantizers represented by Q0 and Q1 are applied. The location of the unavailable reconstruction level is uniquely specified by the quantization step size Δ. In this implementation, the selection between the two scalar quantizers Q0 and Q1 is not explicitly signaled with the bitstream. Instead, the quantizer used for a current transform coefficient is determined by the parity of the transform coefficient level preceding the current transform coefficient in the encoding order by video encoder 20 or the reconstruction order by video decoder 30.

[0100] In some implementations, the switching between the two scalar quantizers is performed by a state machine. For example, Figure 12A is a diagram showing state transitions using a state machine in which four states are used in dependent scalar quantization according to some examples. As shown in Figure 12, the states can take four different values: 0, 1, 2, and 3. The states are uniquely determined by the parity of the transform coefficient level that precedes the current transform coefficient in the encoding / reconstruction order.

[0101] In some implementations, at the start of dequantization of a transform block, the state is set equal to 0. The transform coefficients are reconstructed in scan order (i.e., entropy decode the transform coefficients in the same order).

[0102] After the current transform coefficient is reconstructed, the state is updated according to the state machine. For example, in FIG. 12A, k represents the value of the transform coefficient level. In each state, the next state is determined based on the parity of the transform coefficient level k, i.e., (k&1). The next state when (k&1)==1 is different from the next state when (k&1)==0. As shown in FIG. 12A, the state machine includes two arrows pointing from each of the four states to two different states. FIG. 12B is a table showing the selection of an exemplary quantizer according to the state transition of FIG. 12A according to some examples. For example, according to FIG. 12A and FIG. 12B, in state 1, the next state is 2 when (k&1)==0, and 0 when (k&1)==1.

[0103] Correspondingly, at the decoder, the reconstructed quantization index of one transform coefficient can be calculated according to equation (6).

number

number

[0104] Herein, some exemplary shortcomings present in current designs of sign prediction schemes are clarified. In a first example, sign prediction in current ECM is only applicable to predict signs for transform coefficients in transform blocks where only a linear transform (e.g., DCT and DST transform) is applied. As mentioned above, LFNST may be applied to transform coefficients from a linear transform to achieve better energy compaction of residual samples of intra-coded blocks. However, in current ECM designs, sign prediction is bypassed for transform blocks where LFNST is applied.

[0105] In a second example, to control the complexity of the code prediction, a predetermined maximum number of prediction codes ("L max In current ECM, video encoders determine the maximum number of bits (e.g., L max = 8) and transmit the value to the video decoder. Furthermore, for each transform block, the video encoder or decoder may scan all transform coefficients in raster scan order, and the first L max The non-zero transform coefficients are selected as candidate transform coefficients for sign prediction. Such equal treatment of different transform coefficients in a transform block may not be optimal in terms of the accuracy of sign prediction. For example, for transform coefficients with relatively large magnitude, predicting the signs of these transform coefficients may increase the possibility of achieving correct prediction. The reason is that using the wrong sign for these transform coefficients tends to cause a larger effect on the reconstructed samples on the block boundary than that caused by using transform coefficients with relatively small magnitude.

[0106] In a third example, instead of directly encoding an explicit code value, a video encoder or decoder can encode the correctness of the prediction code. For example, in the case of a transform coefficient with a positive sign, when the predicted code of this transform coefficient is also positive, a bin "0" can be included in the bitstream from the video encoder to the video decoder to indicate only that. In this case, the predicted code is the same as the true code (or original code) of the transform coefficient, which indicates that the code prediction for this transform coefficient is correct. Otherwise (e.g., when the predicted code is negative but the true code is positive), a bin "1" can be included in the bitstream from the video encoder to the video decoder. If all codes are predicted correctly, the corresponding bins indicated in the bitstream are 0 and can be efficiently entropy coded by CABAC. If some of the codes are predicted incorrectly, the corresponding bins indicated in the bitstream are 1. Arithmetic coding + appropriate context model can be efficient to code the bins according to their corresponding probabilities, but there are still non-negligible bits generated in the bitstream to indicate the code values.

[0107] In the fourth example, the spatial discontinuity between samples at the boundary between the current block and the neighboring block is used to select the best code prediction combination in the current design of code prediction in ECM. The L1 norm of gradient differences along the vertical and horizontal directions is utilized to capture the spatial discontinuity. However, since the distribution of image signals is usually non-uniform, using only the vertical and horizontal directions may not be able to capture the spatial discontinuity accurately.

[0108] According to the present disclosure, a video processing method and system for sign prediction in block-based video coding is provided herein to address one or more of the above exemplary shortcomings. The method and system disclosed herein can improve the coding efficiency of sign prediction while taking into account the ease of implementation of a hardware codec. The method and system disclosed herein can improve the coding efficiency of a transform block that applies sign prediction techniques to the transform coefficients of the block.

[0109] For example, as mentioned above, the sign prediction can predict the sign of a transform coefficient in a transform block based on the correlation between boundary samples (also called border samples) located at or near the boundary between the transform block and a spatial neighboring block. Since the existence of the correlation is independent of which transform is applied, the two coding tools (i.e., LFNST and sign prediction) do not interfere with each other and can be jointly applied. Furthermore, since LFNST further compresses the energy of the transform coefficients of the primary transform, the sign prediction for the transform coefficients of LFNST may be more accurate than that for the primary transform. This is because an erroneous sign prediction of a transform coefficient from LFNST may bring more discrepancy in the smoothness of the boundary samples. Therefore, according to the present disclosure, a collaboration scheme is disclosed herein to enable the combination of LFNST and sign prediction to improve the coding efficiency of transform coefficient coding. Furthermore, a template-based hypothesis generation scheme is also disclosed herein to reconstruct the border samples for different combinations of predicted codes to reduce the number of inverse transforms.

[0110] In another example, instead of giving equal treatment to different transform coefficients in a transform block for selecting candidate transform coefficients for sign prediction as described above, transform coefficients that may lead to discrepancies between boundary samples of adjacent blocks can be given a greater weight, considering that the signs of these transform coefficients are more easily predicted. In accordance with the present disclosure, the method and system disclosed herein can select candidate transform coefficients for sign prediction (e.g., transform coefficients whose signs should be predicted for a transform block) based on one or more selection criteria for improving the accuracy of sign prediction. For example, transform coefficients that have a large influence on reconstructed border samples (rather than transform coefficients that have a small influence on reconstructed border samples) can be selected as candidate transform coefficients for sign prediction, and as a result, the accuracy of sign prediction can be improved.

[0111] In yet another example, when the sign of a transform coefficient in a transform block is predicted with a high accuracy rate (e.g., the correctness of the predicted code is higher than a threshold such as 80% or 90%), there is a strong correlation between the boundary samples of the transform block and the adjacent block. In this case, it generally happens that there may be consecutive transform coefficients (e.g., some non-zero transform coefficients at the beginning of the transform block) that can be correctly predicted in most scenarios. In such a scenario, a single bin (instead of multiple bins) is used to indicate whether the signs of the consecutive transform coefficients are correctly predicted, thereby saving the signaling overhead of the code prediction. According to the present disclosure, a vector-based code prediction scheme for reducing the signaling overhead of the code prediction is disclosed herein. Unlike the existing code prediction that predicts the sign of each non-zero transform coefficient separately, the vector-based code prediction scheme of the present disclosure groups a set of consecutive non-zero candidate transform coefficients and predicts the corresponding signs together, so that the average number of bins (or bits) used to indicate the correctness of the predicted code can be efficiently reduced.

[0112] In yet another example, using only vertical and horizontal directions may not accurately capture the spatial discontinuities between samples at the boundary of the current block and the neighboring block. Therefore, more directions may be introduced to more accurately capture the spatial discontinuities. According to the present disclosure, an improved cost function is disclosed herein that takes into account both vertical and horizontal gradients and diagonal gradients to more accurately capture the spatial discontinuities.

[0113] 13 is a block diagram illustrating an example sign prediction process 1100 in block-based video coding according to some implementations of the present disclosure. In some implementations, the sign prediction process 1300 may be performed by transform processing unit 52. In some implementations, the sign prediction process 1300 may be performed by one or more processors (e.g., one or more video processors) of video encoder 20 or decoder 30. Throughout this disclosure, LFNST is used as an example of a secondary transform without loss of generality. It is contemplated herein that other examples of secondary transforms may also be applied.

[0114] In the existing design of ECM, sign prediction is disabled for transform blocks to which LFNST is applied. However, the principle of sign prediction is to predict the sign of transform coefficients based on the correlation between border samples of transform blocks and spatially adjacent blocks, which is independent of the specific transform scheme (e.g., primary transform or secondary transform) or transform core (e.g., DCT or DST) applied to the transform block. Therefore, in this specification, sign prediction and LFNST can be applied together to further improve the efficiency of transform coding. According to the present disclosure, the sign prediction process 1300 can be applied to predict the sign of transform coefficients in a transform block to which a primary transform and a secondary transform are jointly applied.

[0115] An exemplary overview of the code prediction process 1300 is provided herein. First, the code prediction process 1300 may perform a coefficient generation operation 1302 by applying a primary transform and a secondary transform to a transform block of a video frame of a video to generate transform coefficients for the transform block. Next, the code prediction process 1300 may perform a coefficient selection operation 1304 by selecting a set of candidate transform coefficients from the transform coefficients for code prediction. Subsequently, the code prediction process 1300 may perform a hypothesis generation operation 1306 by applying a template-based hypothesis generation scheme to select a hypothesis from a plurality of candidate hypotheses for the set of candidate transform coefficients. Furthermore, the code prediction process 1300 may perform a code generation operation 1108 by determining that a combination of code candidates associated with the selected hypothesis is a set of predicted codes for the set of candidate transform coefficients. The operations 1302, 1304, 1306, and 1308 are each described in more detail below.

[0116] For example, transform processing unit 52 of video encoder 20 may transform the residual video data into transform coefficients of a transform block by jointly applying a primary transform and a secondary transform (e.g., as shown in FIG. 6 in which forward primary transform 603 and forward LFNST 604 are applied together). A predetermined number (e.g., L) of non-zero transform coefficients from the transform coefficients of the transform block may be selected as candidate transform coefficients based on one or more selection criteria described below, where 1≦L≦the maximum number of codes that can be predicted. Then, by applying a template-based hypothesis generation scheme, multiple candidate hypotheses may be generated, each using a different combination of code candidates for the L candidate transform coefficients, resulting in a total of 2 LCandidate hypotheses may result. Each candidate hypothesis may include reconstructed samples on the top and left boundaries of the transform block. A cost function incorporating a complex gradient along the horizontal, vertical and diagonal directions may then be used to calculate a cost for the reconstruction of each candidate hypothesis. From the multiple candidate hypotheses, a candidate hypothesis associated with a minimum cost may be determined as a hypothesis for predicting signs of the L candidate transform coefficients. For example, a combination of code candidates used to generate the candidate hypothesis associated with the minimum cost is used as a predicted code for the L candidate transform coefficients.

[0117] Initially, the symbol prediction process 1300 may perform a coefficient generation operation 1302, in which a primary transform (e.g., DCT, DST, etc.) and a secondary transform (e.g., LFNST) may be jointly applied to a transform block to generate transform coefficients for the transform block. For example, a primary transform may be applied to the transform block to generate primary transform coefficients for the transform block. An LFNST may then be applied to the transform block to generate LFNST transform coefficients based on the primary transform coefficients.

[0118] The sign prediction process 1300 may continue with a coefficient selection operation 1304, in which a set of candidate transform coefficients for sign prediction may be selected from the transform coefficients of the transform block based on one or more selection criteria. The selection of the candidate transform coefficients may maximize the number of candidate transform coefficients that may be correctly predicted and may improve the accuracy of the sign prediction.

[0119] In some implementations, the set of candidate transform coefficients can be selected from the transform coefficients of the transform block based on the strength of the transform coefficients. For example, the set of candidate transform coefficients can include one or more transform coefficients having a strength greater than the strength of the remaining transform coefficients in the transform block.

[0120] Generally, for transform coefficients with larger strength, the prediction code of these transform coefficients is more likely to be correct.The reason is that these transform coefficients with larger strength tend to have a larger impact on the quality of reconstructed samples, and using wrong codes for these transform coefficients increases the possibility of generating discontinuity between boundary samples of transform block and spatially adjacent blocks.Based on this basic principle, a set of candidate transform coefficients for code prediction can be selected from the transform coefficients of a transform block based on the strength of non-zero transform coefficients in the transform block.

[0121] There may be multiple ways to implement the transform coefficient intensity-based sorting scheme for sign prediction. In a first implementation form, the scheme can be used directly for sorting the reconstructed transform coefficients after inverse quantization (i.e., the inverse quantized transform coefficients) such that the inverse quantized transform coefficients with larger intensities are placed before the inverse quantized transform coefficients with smaller intensities for sign prediction. For example, all non-zero transform coefficients in a transform block can be scanned and sorted according to descending order of intensity to form a coefficient list. The transform coefficient with the largest intensity can be selected from the coefficient list and placed as the first candidate transform coefficient in the set of candidate transform coefficients, the transform coefficient with the second largest intensity can be selected from the coefficient list and placed as the second candidate transform coefficient in the set of candidate transform coefficients, and so on until the number of selected candidate transform coefficients reaches a predetermined number L.

[0122] In the second implementation, instead of directly using the dequantized transform coefficients, the quantization index (e.g., quantIdx obtained according to equation (6)) of each transform coefficient can be used to represent the intensity of the transform coefficient for such sorting process. As shown in equation (7), the value of one dequantized transform coefficient is equal to the product of the quantization index quantIdx of the transform coefficient and the corresponding step size Δ, and the step size is the same for the dequantization of all transform coefficients in one transform block, so the two implementations are actually mathematically identical. However, since the quantization index quantIdx can be obtained at the parsing stage (earlier than obtaining the dequantized transform coefficients), the second implementation can provide certain benefits when implemented by some specific hardware.

[0123] In some implementations, a set of candidate transform coefficients can be selected from transform coefficients of a transform block based on a coefficient scan order for entropy coding applied in video coding. Because unprocessed video content may have a large amount of low-frequency information, the strength of non-zero transform coefficients obtained from processing of the video content tends to be larger at low-frequency positions and smaller toward high-frequency positions. Therefore, a coefficient scan order (such as zigzag scan, top-left scan, horizontal scan or vertical scan) can be used in modern video codecs to scan transform coefficients in a transform block for entropy coding. By using this coefficient scan order, transform coefficients with larger strength (usually corresponding to lower frequencies) are scanned before transform coefficients with smaller strength (usually corresponding to higher frequencies). Based on this basic principle, a set of candidate transform coefficients for code prediction disclosed herein can be selected from transform coefficients of a transform block based on a coefficient scan order for entropy coding. For example, a coefficient list can be obtained by scanning all transform coefficients in a transform block using the coefficient scan order. The first L non-zero transform coefficients in the coefficient list may then be automatically selected as a set of candidate transform coefficients for symbol prediction.

[0124] In some implementations, for an intra-coded block, a set of candidate transform coefficients for code prediction can be selected from the transform coefficients of the block based on the intra-prediction direction of the block. For example, multiple scan orders that are consistent with the intra-prediction direction (e.g., 67 intra-prediction directions in VVC and ECM) can be determined and stored as look-up tables in both the video encoder 20 and the video decoder 30. When encoding the transform coefficients of the intra block, the video encoder 20 or the video decoder 30 can identify a scan order that is closest to the intra-prediction of the intra block from the scan order. The video encoder 20 or the video decoder 30 can use the identified scan order to scan all non-zero transform coefficients of the intra block, thereby obtaining a coefficient list, and select the first L non-zero transform coefficients from the coefficient list as the set of candidate transform coefficients.

[0125] In some implementations, video encoder 20 may determine a scan order of transform coefficients of a transform block and signal the determined scan order to video decoder 30. One or more new syntax elements indicating the determined scan order may be signaled via a bitstream. For example, multiple fixed scan orders (e.g., for different transform block sizes and coding modes) may be pre-determined by video encoder 20 and pre-shared with video decoder 30. Then, after selecting a scan order from the fixed scan orders, video encoder 20 may only signal a single index to indicate the selected scan order to video decoder 30. In another example, one or more new syntax elements may be used to enable signaling of the scan order of any selected transform coefficients. In some implementations, one or more syntax elements may be signaled at various coding levels, e.g., sequence parameter set (SPS), picture parameter set (PPS), picture (or slice) level, CTU (or CU) level, etc.

[0126] In some implementations, a set of candidate transform coefficients can be selected from transform coefficients of a transform block based on the influence scores of the transform coefficients on the border samples of the reconstructed transform block. Specifically, as shown in the above formula (5), the selection of the code combination (i.e., the predicted code or the code predictor) is based on a cost function for minimizing the discontinuity of the gradient of samples between the current transform block and the spatially adjacent blocks. Therefore, the signs of transform coefficients with relatively large influences on the reconstructed samples on the top and left borders of the current transform block are more likely to be predicted correctly. The reason is that the inversion of these codes may cause large variations in the smoothness between the boundary samples calculated in (5). In order to maximize the percentage of correct code prediction, the signs of these transform coefficients (i.e., the transform coefficients with larger influences on the reconstructed border samples) can be predicted before other transform coefficients (i.e., the transform coefficients with smaller influences on the reconstructed border samples). Based on this basic principle, a set of candidate transform coefficients for code prediction disclosed herein can be selected based on the influence scores on the reconstructed samples on the top and left borders of the current transform block.

[0127] For example, the video encoder 20 or the decoder 30 may sort all transform coefficients based on a measure of their corresponding influence scores to the reconstructed border samples of the transform block. If a transform coefficient has a larger influence score to the reconstructed border sample, it is easier to predict correctly and therefore may be assigned the smallest index in the code prediction candidate list. The set of candidate transform coefficients disclosed herein may be the L transform coefficients having the smallest L indices in the code prediction candidate list.

[0128] In some implementations, different criteria can be applied to quantify the influence score of a transform coefficient on a reconstructed border sample. For example, a value measuring the energy of the variation of the reconstructed border sample due to the transform coefficient can be used as the influence score, which can be obtained (in the L1 norm) as follows:

number

[0129] In the above formula (6), C i,j represents the transform coefficient at position (i,j) in the transform block. T i,j (l,k) is the conversion coefficient C i,j Let N and M denote the width and height of the transformed block, respectively. V represents the influence score of the transformed coefficient at position (i,j).

[0130] In another example, the L1 norm in equation (8) above can be replaced by the L2 norm, and thus the influence score (e.g., a measure of the energy of the variation of the reconstructed border samples due to the transform coefficients) can be calculated using the L2 norm:

number

[0131] According to the present disclosure, (e.g., T i,j (0,n) and T i,j Although only the upper boundary and left boundary samples (as indicated by (m,0)) are used for the calculations in equations (8) and (9) above, the transform coefficient selection scheme disclosed in this specification can also be applied to any symbol prediction scheme by changing the reconstructed samples of the current transform block used in the corresponding cost function.

[0132] Similar to the transform coefficient intensity-based scheme, there may be various ways to implement the influence score based scheme. In a first implementation, the scheme is to calculate the influence score based on the inverse quantized transform coefficients C i,j In a second implementation, the quantization index value quantIdx can be applied instead to obtain the inverse quantized transform coefficients C i,j and thus the corresponding cost measure can be calculated. More precisely, when the quantization index value quantIdx is applied, equations (8) and (9) become equations (10) and (11) below.

number

number

[0133] Since the value of one dequantized transform coefficient is equal to the product of the quantization index quantIdx of that transform coefficient and the corresponding step size Δ, which is the same for the dequantization of all transform coefficients in one transform block, the two methods are indeed mathematically identical.

[0134] The code prediction process 1300 may continue to perform a hypothesis generation operation 1106, in which a template-based hypothesis generation scheme may be applied to select a hypothesis for the set of candidate transform coefficients from a plurality of candidate hypotheses. Initially, a plurality of combinations of code candidates may be determined based on a total number of coefficients included in the set of candidate transform coefficients. For example, if there are a total of L candidate transform coefficients, the plurality of combinations of code candidates for the set of candidate transform coefficients may include 2 combinations of code candidates. LEach code candidate can be either a negative sign (-) or a positive sign (+). Each code candidate combination can include a total of L negative or positive signs. For example, if L=2, the code candidate combinations can be 2 combinations consisting of code candidates that are (+,+), (+,-), (-,-), and (-,-), respectively. 2 = 4 combinations may be included.

[0135] A template-based hypothesis generation scheme can then be applied to generate multiple candidate hypotheses for multiple combinations of code candidates, respectively. In order to reduce the complexity of the inverse primary and secondary transforms that need to be performed, the template-based hypothesis generation scheme disclosed herein can be used to optimize the generation of border samples of the reconstructed transform block. Two exemplary approaches for performing the template-based hypothesis generation scheme are disclosed herein. It is contemplated that other exemplary approaches for implementing the template-based hypothesis generation scheme are also possible, and such approaches are not limited herein.

[0136] In a first exemplary approach, a corresponding candidate hypothesis for each combination of code candidates can be generated based on a linear combination of templates, and thus multiple candidate hypotheses can be generated for each of multiple combinations of code candidates. Each template can correspond to a candidate transform coefficient from a set of candidate transform coefficients. Each template can represent a group of reconstructed samples on the upper and left boundaries of a transform block. Each template can be generated by applying an inverse secondary transform and an inverse primary transform to the transform block, where each of the set of candidate transform coefficients is set to 0 except for the candidate transform coefficient corresponding to the template that is set to 1 (e.g., the candidate transform coefficient corresponding to the template is set to 1, but each of the remaining candidate transform coefficients is set to 0).

[0137] For example, the corresponding candidate hypothesis for each of the combinations of code candidates may be set to a linear combination of templates. For the templates corresponding to each of the candidate transform coefficients, each of the template weights may be set to be the magnitude of the dequantized transform coefficient corresponding to each of the candidate transform coefficients. An example of hypothesis generation based on a linear combination of templates is shown in FIG. 14, which will be described in more detail below.

[0138] To predict the sign of a candidate transform coefficient, the video encoder 20 or the decoder 30 may go through all the candidate hypotheses before identifying a hypothesis associated with a combination of code candidates that can minimize a cost value calculated from a cost function. In the first exemplary approach above, each candidate hypothesis may be generated based on a combination of multiple templates, which is relatively complex considering the computations (e.g., additions, multiplications, and shifts) per sample involved in such a combination. To reduce the computational complexity associated with identifying a hypothesis that minimizes a cost value calculated from a cost function, a second exemplary approach is introduced herein.

[0139] In a second exemplary approach, multiple combinations of code candidates associated with multiple candidate hypotheses may be treated as multiple hypothesis indexes for the multiple candidate hypotheses, respectively. For example, digital 0 and 1 may be configured to represent a positive sign (+) and a negative sign (-), respectively. A combination of code candidates corresponding to a candidate hypothesis may be used as a unique representation (i.e., a hypothesis index) for the candidate hypothesis. A hypothesis index of 000 may represent a candidate hypothesis generated by setting all three code candidates to positive (e.g., the three code candidates are (+,+,+)). Similarly, a hypothesis index of 010 may represent a candidate hypothesis generated by setting the first and third code candidates to positive while setting the second code candidate to negative (e.g., the three code candidates are (+,-,+)).

[0140] Then, multiple candidate hypotheses can be generated based on the Gary code order of the multiple hypothesis indexes, and as a result, a current candidate hypothesis with a current hypothesis index can be generated using reconstructed samples of past candidate hypotheses with past hypothesis indexes. The current hypothesis index of the current candidate hypothesis can be immediately after the past hypothesis index of the past candidate hypothesis in the Gary code order of the multiple hypothesis indexes. The current hypothesis index can be generated by changing the code candidate associated with the past hypothesis index from positive (or negative) to negative (or positive). For example, the current hypothesis index can be obtained by changing a single "0" (or "1") in the past hypothesis index to "1" (or "0").

[0141] For example, the multiple hypothesis indexes may be permuted based on the Gary-like code order of the multiple hypothesis indexes to generate a sequence of permuted hypothesis indexes. For a first hypothesis index in the sequence of permuted hypothesis indexes, a first candidate hypothesis corresponding to the first hypothesis index may be generated by applying an inverse secondary transform and an inverse primary transform to a transform block with each of a set of candidate transform coefficients set to 1. For a second hypothesis index in the sequence of permuted hypothesis indexes immediately following the first hypothesis index, a second candidate hypothesis corresponding to the second hypothesis index may be generated based on (a) the first candidate hypothesis corresponding to the first hypothesis index and (b) an adjustment term for the second candidate hypothesis. Table 3 below illustrates an example process for generating all candidate hypotheses for LFNST when the number of candidate transform coefficients is three (e.g., L=3). [Table 3]

[0142] In Table 3 above, the first column is the set of two code candidates. 3Column 1 shows 000, 001, 011, 010, 110, 111, 101, 100 combinations, respectively. Column 2 shows hypothesis indexes corresponding to candidate code combinations, respectively, by using digital 0 and 1 to represent positive sign (+) and negative sign (-), respectively. The hypothesis indexes in column 2 are ordered according to the Gary code order (e.g., in the order 000, 001, 011, 010, 110, 111, 101, 100). Column 3 shows candidate hypotheses corresponding to candidate code combinations and hypothesis indexes, respectively. Column 4 shows the calculation of each candidate hypothesis.

[0143] In Table 3, TXYZ in the fourth column represents corresponding templates (i.e., reconstructed samples on the upper and left boundaries of a transform block) that may be generated by applying an inverse transform to a coefficient matrix of a transform block in which certain transform coefficients are set to 1 but all other transform coefficients are equal to 0. For example, T100 represents a corresponding template that is generated by applying an inverse transform to a coefficient matrix in which only the transform coefficient corresponding to a first code candidate is set to 1 but all transform coefficients in the coefficient matrix are set to 0. C0, C1, and C2 represent absolute values ​​of dequantized transform coefficients associated with the first code candidate, the second code candidate, and the third code candidate, respectively.

[0144] With reference to Table 3, for a first hypothesis index 000, a first candidate hypothesis H000 may be generated by applying an inverse secondary transform and an inverse linear transform to a coefficient matrix associated with a transform block with each of the candidate transform coefficients set to 1. For a second hypothesis index 001, which immediately follows the first hypothesis index 000, the second candidate hypothesis H001 may be generated by applying (a) the first candidate hypothesis H000 and (b) an adjustment term for the second candidate hypothesis (e.g., −C2 * Similarly, for a third hypothesis index 011 immediately following a second hypothesis index 001, a third candidate hypothesis H011 may be generated based on (a) the second candidate hypothesis H001 and (b) an adjustment term for the third candidate hypothesis (e.g., −C1 *For a fourth hypothesis index 010 immediately following a third hypothesis index 011, a fourth candidate hypothesis H010 may be generated based on (a) the third candidate hypothesis H011 and (b) an adjustment term for the fourth candidate hypothesis (e.g., C2 * T001).

[0145] The hypothesis associated with the minimum cost may then be determined from multiple candidate hypotheses based on a cost function incorporating combined gradients along horizontal, vertical and diagonal directions. As mentioned above, if the cost function utilizes only horizontal and vertical gradients (e.g., as shown in equation (5) above), the cost function may not work well for highly non-uniform image signals. According to the present disclosure, gradients along one or more diagonal directions are also utilized to improve the accuracy of the cost function. For example, two diagonal directions, including a left diagonal direction and a right diagonal direction, may also be incorporated into the cost function. For example, the cost function for the two diagonal directions may be expressed according to the following equations (12) and (13).

number

number

[0146] In the above formula (8) or (9), B -1,n-1 , B -2,n-2 , B -1,n+1 and B. -2,n+2 represents the neighboring samples of the transform block from the upper neighboring block of the transform block. m-1,-1 , C m-2,-2 , C m+1,-1 and C m+2,-2 represents the neighboring samples of the transform block from its left neighboring block. P 0,n and P m,0represent the reconstructed samples on the top and left boundaries of the transform block, respectively. N and M represent the width and height of the transform block, respectively. costD1 and costD1 represent the left-diagonal and right-diagonal cost functions for the left-diagonal and right-diagonal directions, respectively.

[0147] The two diagonal cost functions (e.g., costD1 and costD2) may be used jointly with the horizontal and vertical cost functions (e.g., costHV shown in equation (5) above). A cost function for sign prediction may then be determined based on the horizontal and vertical cost functions incorporating gradients along the horizontal and vertical directions, the left diagonal cost function incorporating gradients along the left diagonal direction, and the right diagonal cost function incorporating gradients along the right diagonal direction. For example, the cost function may be a weighted sum of the horizontal and vertical cost functions, the left diagonal cost function, and the right diagonal cost function described in equation (14).

number

[0148] In the above equation (14), ω represents the weights for the left diagonal cost function and the right diagonal cost function.

[0149] In another example, the cost function may be the minimum of the horizontal and vertical cost functions, the left-diagonal cost function and the right-diagonal cost function set forth in equation (15).

number

[0150] Compared to equation (5) shown above, the cost functions in equations (14) or (15) disclosed in this specification may require more neighboring pixels to support the cost functions costD1, costD2 along the diagonal directions, which are described in more detail below with reference to Figures 16A and 16B.

[0151] In some implementations, a corresponding cost for each candidate hypothesis may be determined using equation (14) or (15) above. A plurality of costs may then be calculated for each of the plurality of candidate hypotheses. A minimum cost among the plurality of costs may be determined. A candidate hypothesis associated with the minimum cost may be determined from the plurality of candidate hypotheses and selected to be the hypothesis for code prediction.

[0152] The code prediction process 1300 may continue to perform a code generation operation 1108, in which it is determined that the combination of code candidates associated with the selected hypothesis is a set of predictive codes for the set of candidate transform coefficients. For example, the combination of code candidates (e.g., L code candidates) used to generate the selected hypothesis may be used as a predictive code for the L candidate transform coefficients.

[0153] In some implementations, the code generation operation 1308 may further include applying a vector-based code prediction scheme to the set of predictive codes to generate a sequence of code signaling bits for the set of candidate transform coefficients. A bitstream including the sequence of code signaling bits may be generated by the video encoder 20 and stored in the storage device 32 of FIG. 1. Alternatively, or in addition, the bitstream may be transmitted to the video decoder 30 via the link 16 of FIG. 1.

[0154] As mentioned above, when the sign of a transform coefficient in a transform block is predicted successfully, it is highly likely that the signs of multiple consecutive transform coefficients can be predicted correctly.In this case, the signaling scheme of the existing code prediction design is obviously inefficient in terms of overhead for signaling the code value of the transform block, since it needs to signal multiple bins of "0" to separately indicate that the corresponding signs of each of the transform coefficients can be predicted correctly.An exemplary implementation of the existing code prediction scheme will be described in more detail below with reference to Figure 15A.

[0155] According to the present disclosure, the efficiency of code signaling may be improved by applying the vector-based code prediction scheme disclosed herein. Specifically, the candidate transform coefficients for a transform block may be divided into multiple groups, and the codes of the candidate transform coefficients in each group may be predicted together. In this case, when the original codes (or true codes) of the candidate transform coefficients in the group are the same as the predicted codes, respectively, only a bin with a value of "0" may be sent in the bitstream to indicate that all codes in the group are correctly predicted. Otherwise (i.e., when there is at least one candidate transform coefficient in the group whose original code is different from the predicted code), a bin with a value of "1" may be signaled in the bitstream first to indicate that all codes for the candidate transform coefficients in the group are not correctly predicted. Then, additional bins may be signaled in the bitstream from the video encoder 20 to the video decoder 30 to separately inform the corresponding correctness of each of the predicted codes in the group. An exemplary implementation of the vector-based code prediction scheme disclosed herein is described in more detail below with reference to FIG. 15B.

[0156] In some implementations, the set of candidate transform coefficients can be divided into multiple groups of candidate transform coefficients, for each of which one or more code signaling bits can be generated for the group of candidate transform coefficients to indicate the correctness of the prediction code.

[0157] In one example, a sign signaling bit may be generated based on whether an original sign of the group of candidate transform coefficients is identical to a predicted sign of the group of candidate transform coefficients. In response to the original sign of the group of candidate transform coefficients being identical to the predicted sign of the group of candidate transform coefficients, a bin having a value of zero ("0") may be generated and added to the bitstream as a sign signaling bit. For example, the bitstream may include a "0" indicating that the predicted sign of the group of candidate transform coefficients was correctly predicted.

[0158] On the other hand, a bin having a value of one ("1") may be generated in response to the original code of the group of candidate transform coefficients not being identical to the predicted code of the group of candidate transform coefficients. A set of additional bins may also be generated to signal the corresponding correctness of the predicted code of the group of candidate transform coefficients. The bin having a value of one and the set of additional bins may then be added to the bitstream as code signaling bits. For example, the set of additional bins may be an XOR result of the original code and the predicted code of the group of candidate transform coefficients. An additional bin having a value of "0" may indicate that the predicted code of the candidate transform coefficient corresponding to the additional bin was correctly predicted, while an additional bin having a value of "1" may indicate that the predicted code of the candidate transform coefficient corresponding to the additional bin was incorrectly predicted. The bitstream may include (a) a "1" indicating that the predicted code of the group of candidate transform coefficients is not correctly predicted, and (b) a set of additional bins indicating which predicted codes were correctly predicted and which predicted codes were incorrectly predicted.

[0159] The code signaling bits can be generated using other context models as well. For example, the code signaling bits can include bins with values ​​of "0" to indicate that the predicted code of the group of candidate transform coefficients is correctly predicted and "1" to indicate that the predicted code is incorrect. An additional set of bins can also be generated to signal the corresponding correctness of the predicted code of the group of candidate transform coefficients whose code prediction is incorrect.

[0160] In some implementations, the size of each of the groups of candidate transform coefficients may be adaptively changed based on one or more predetermined criteria. The one or more predetermined criteria may include the width or height of the transform block, the coding mode of the transform block (e.g., intra-coded or inter-coded), the number of non-zero transform coefficients in the transform block, etc. In some implementations, the size of each of the groups of candidate transform coefficients may be signaled in the bitstream at various coding levels, such as SPS, PPS, slice or picture level, CTU or CU level, or transform block level.

[0161] In some implementations, one or more constraints may be applied to limit the application scenario of the vector-based code prediction scheme disclosed herein. For example, the vector-based code prediction scheme disclosed herein may be applied to process the code of a first portion of the transform coefficients in a transform block, while the code of a second portion of the transform coefficients in the transform block may be processed using an existing code prediction scheme. In a further example, the vector-based code prediction scheme disclosed herein may be applicable to the first N (e.g., N=2, 3, 4, 5, 6, 7, or 8, etc.) non-zero candidate transform coefficients from a transform block, while the code of other candidate transform coefficients of the transform block may be processed using an existing code prediction scheme shown in FIG. 15A, which will be described later in this disclosure.

[0162] According to the present disclosure, the symbol prediction process 1100 disclosed herein may be disabled in some scenarios. For example, when LFNST is applied to a coding block coded by intra template matching mode, the primary transform may be DST-VII. Since the LFNST core transform in ECM is mainly learned when the primary transform is DCT-II, the corresponding LFNST transform coefficients of an intra template matching block may exhibit different characteristics compared to those of other LFNST blocks. Based on this basic principle, the symbol prediction process 1300 may be disabled when the current coding block is an intra template matching block and coded using LFNST.

[0163] According to the present disclosure, the maximum number of predictive codes for LFNST blocks and the maximum number of predictive codes for non-LFNST blocks may be difficult to control the computational complexity of code prediction. For example, the maximum number of predictive codes for LFNST blocks may be set to 6 (or 4), while the maximum number of predictive codes for non-LFNST blocks may have a value different from 6 (or 4). Furthermore, different values ​​of the maximum number of predictive codes may be applied to video blocks that apply LFNST and video blocks that do not apply LFNST. In some implementations, video encoder 20 may determine and signal to video decoder 30 the maximum number of predictive codes for LFNST blocks based on a corresponding complexity or encoder performance priority. If the maximum number of predictive codes for LFNST blocks is signaled to video decoder 30, the maximum number of predictive codes may be signaled at various coding levels, such as at the sequence parameter set (SPS), picture parameter set (PPS), picture or slice level, or CTU or CU level. In some implementations, video encoder 20 may determine different values ​​for the maximum number of predictive codes for video blocks that apply LFNST and video blocks that do not apply LFNST, and signal the values ​​of the maximum number from video encoder 20 to video decoder 30.

[0164] According to the present disclosure, since the transform coefficients of both the primary transform and the secondary transform are fixed, the video encoder 20 or the video decoder 30 can pre-compute templates (e.g., template samples) for different transform block sizes and different combinations of the primary transform and the secondary transform. The video encoder 20 or the video decoder 30 can store the templates (e.g., template samples) in an internal memory or an external memory to avoid the complexity of generating the template samples on-the-fly for an optimized implementation. The template samples can be stored with different fractional precisions to achieve different trade-offs between storage size and sample precision. For example, the video encoder 20 or the video decoder 30 can scale the floating template samples with a fixed factor (e.g., 64, 128, or 256) and round the scaled samples to the nearest integer. The rounded samples can be stored in the memory. Then, when the template is used to reconstruct a candidate hypothesis, the corresponding samples of the template can first be unscaled to the original precision to ensure that the generated samples in the candidate hypothesis fall within the correct dynamic range.

[0165] FIG. 14 is a diagram illustrating an example hypothesis generation based on a linear combination of templates according to some implementations of the present disclosure. In FIG. 14, four patterned blocks 0-3 represent candidate transform coefficients whose signs are to be predicted. Coefficients C0, C1, C2, and C3 represent corresponding values ​​of dequantized transform coefficients of the four candidate transform coefficients. Templates 0-3 may correspond to four candidate transform coefficients 0-3, respectively. For example, template 0 corresponding to candidate transform coefficient 0 may be generated by applying an inverse secondary transform and an inverse primary transform to the transform block, where candidate transform coefficient 0 is set to 1 and the remaining candidate transform coefficients in the transform block are set to 0. Similarly, each of templates 1-3 may be generated. Candidate hypotheses may be generated by adding templates 0-1 and weights C0-C3, respectively.

[0166] Fig. 15A is a diagram showing an example implementation of an existing code prediction scheme according to some examples. Fig. 15B is a diagram showing an example implementation of a vector-based code prediction scheme according to some implementations of the present disclosure. An example comparison between the existing code prediction scheme and the vector-based code prediction scheme disclosed herein is described herein with reference to Figs. 15A and 15B.

[0167] In Figures 15A and 15B, there are six non-zero transform coefficients in a transform block that are selected as candidate transform coefficients for sign prediction. The candidate transform coefficients are scanned from the coefficient matrix of the transform block using a raster scan order. The original and predicted codes of the candidate transform coefficients are also shown in Figures 15A and 155B. For example, the original and predicted codes of a first candidate transform coefficient having a value of "-2" are both "-" (represented as "1" in Figures 15A and 155B). The original and predicted codes of a second candidate transform coefficient having a value of "3" are both "+" (represented as "0" in Figures 13A and 13B). The original and predicted codes of a third candidate transform coefficient having a value of "1" are "+" and "-", respectively (represented as "0" and "1" in Figures 13A and 13B). The original code of the third candidate transform coefficient is predicted incorrectly. As shown in FIGS. 15A and 15B, except for the third transform coefficient, the original signs of all other candidate transform coefficients are the same as the corresponding predicted signs (ie, are correctly predicted).

[0168] Referring to FIG. 15A, a total of six bins (i.e., 0, 0, 1, 0, 0, and 0) are generated, each bin corresponding to a candidate transform coefficient. The six bins may be generated by performing an XOR operation between the original codes and the predictive codes of the six candidate transform coefficients. The six bins may be used to indicate the correctness of the corresponding six predictive codes. For example, the first bin and the second bin, each having a value of "0", mean that the predictive codes for the first and second candidate transform coefficients are correct. The third bin, having a value of "1", indicates that the predictive code for the third transform coefficient is incorrect. The six bins may be sent to CABAC for entropy coding.

[0169] Referring to FIG. 15B, the vector-based code prediction scheme disclosed herein divides six candidate transform coefficients into three groups, each group containing two consecutive candidate transform coefficients. Since the signs of the candidate transform coefficients in groups #0 and #2 can be correctly predicted, only two bins, each with a value of "0", are generated for the two groups. For group #1, since group #1 contains a third candidate transform coefficient whose sign cannot be correctly predicted, a bin with a value of "1" (underlined in FIG. 15B) is generated and signaled in the bitstream to indicate that the group contains at least a candidate transform coefficient whose original code is different from the predicted code. Then, for the third and fourth coefficients in group #1, two additional bins with values ​​of "1" and "0" are generated to indicate whether the sign can be correctly predicted. Correspondingly, when the vector-based code prediction scheme disclosed herein is applied, there are a total of five bins generated for CABAC, which have fewer bits than the bins generated by the existing code prediction scheme shown in FIG. 15A. Therefore, by applying the vector-based code prediction scheme disclosed herein, the signaling overhead can be reduced and the coding efficiency of transform blocks can be improved.

[0170] According to the present disclosure, the raster scan order is used to obtain candidate transform coefficients from the coefficient matrix of the transform block as shown in Figure 15B, but any other scan order may be used to select candidate transform coefficients for sign prediction. For example, the candidate transform coefficients may be selected based on one or more selection criteria above. Similar descriptions are not repeated in this specification.

[0171] FIG. 16A is a diagram illustrating an exemplary calculation of a left diagonal cost function along the left diagonal direction according to some implementations of the present disclosure. FIG. 16B is a diagram illustrating an exemplary calculation of a right diagonal cost function along the right diagonal direction according to some implementations of the present disclosure. Compared to the above formula (8) for the calculation of costHV, the left diagonal cost function costD1 or the right diagonal cost function costD2 shown in the above formula (14) or (15) may require more neighboring pixels (shown as the marked pixels in areas 1602, 1604, and 1606 in FIG. 16A and FIG. 16B ) to support the calculation of the cost function costD2 along the diagonal direction. If these pixels are not available in areas 1602, 1604, and 1606, a nearest neighbor padding method may be adopted to fill these unavailable positions. For example, B in area 1606 may be used to calculate the left diagonal cost function costD1 or the right diagonal cost function costD2. -1,4 If is not available, B -1,4 B, the closest unavailable pixel to -1,3 But, B -1,4 used to fill the positions of -1,4 =B -1,3 ). B in Area 1602 -1,-1 (C -1,-1 (also expressed as -1,-2 (C -1,-1 ), B -2,-1 (C -1,-1 ) and B -2,-2 (C -1,-1 ) is unavailable, several exemplary methods are disclosed herein for filling in the unavailable positions.

[0172] In a first exemplary method, each unavailable location may be filled by weighting the nearest unavailable pixel as shown in equations (16)-(19) below.

number

number

number

number

[0173] In a second exemplary method, some of the unavailable locations may be filled by the nearest unavailable pixel. -1,-2 If is not available, B -1,-2 is C 0,-2 Filled in by. B -2,-1 If is not available, B -2,-1 is B -2,0 However, B -2,-2 and B. -1,-1 If is not available, B -2,-2 and B. -1,-1 can be filled by the average of the two nearest neighboring pixels calculated according to equations (16) and (17) above.

[0174] In a third exemplary method, the cost function is calculated using only unavailable reconstructed adjacent samples. If the cost calculation of one boundary sample along the top / left boundary of the current block includes any unavailable reconstructed samples, these unavailable reconstructed samples are not used in the calculation of the cost in the corresponding direction. For example, in FIG. 16B, boundary sample P 0,0 , P 0,1 and P 1,0 Only the cost function value in the upper right direction is used to calculate the cost function value in the upper right direction, while P 0,2 , P 0,3 , P2,0 and P 3,0 is not used because it refers to at least one reference sample for which no cost calculations are available.

[0175] In accordance with the present disclosure, the left and right diagonals (i.e., 135° and 45° shown in FIGS. 16A and 16B ) are used for illustrative purposes in calculating the cost functions shown in equations (14) or (15) above, but it is contemplated that any other measurement components (e.g., continuity measurements along any direction or directions) may be introduced into the calculation of the cost function for code prediction.

[0176] In a fourth implementation form, a sample extrapolation method based on gradient analysis of texture information between adjacent samples of one current block can be implemented to improve the accuracy of the cost function for code prediction. Instead of always using a fixed extrapolation direction (e.g., vertical extrapolation for the adjacent samples above and horizontal extrapolation for the horizontal adjacent samples), texture analysis of the upper and left adjacent samples of the reconstructed current block can be performed at both the encoder and the decoder, and the most dominant direction of the gradient of the adjacent samples can be selected to extrapolate boundary samples along the upper and left boundaries of the current block.

[0177] For example, Figure 17 is a flow diagram of a method 1700 for capturing dominant gradient directions in neighboring samples of a reconstructed current block according to some implementations of the present disclosure. The method 1700 may be implemented by a video processor associated with the video encoder 20 or the video decoder 30 and may include steps 1702-1712, described below. Some of the steps may be optional for implementing the present disclosure provided herein. Furthermore, some of the steps may be performed simultaneously or in a different order than shown in Figure 17.

[0178] In step 1702, a reference sample is selected for the current block for gradient derivation. In some implementations, the reference sample forms a template. For example, FIG. 18A is a diagram illustrating an example template sample and gradient filter window in gradient-based selection of sample extrapolation direction of a cost function according to some implementations of the present disclosure. As shown in FIG. 18A, a template of N rows and columns of reconstructed neighboring samples above and to the left of the current block are used as reference samples for gradient derivation. In the example of FIG. 18A, the template size is equal to 3.

[0179] In step 1704, a histogram of gradients (HoG) is initialized. For example, the HoG may be generated with several components, where each component of the histogram of gradients corresponds to the cumulative strength of gradients in a predefined angular direction. Each component may be initialized as 0. For example, FIG. 18B is a diagram showing an exemplary histogram of gradients (HoG) in gradient-based selection of sample extrapolation directions of a cost function according to some implementations of the present disclosure. In fact, different predefined directions can be used in the gradient analysis scheme of the present disclosure. In one implementation, the same directions as those defined for the 65 angular directions of common intra prediction in VVC / ECM are used.

[0180] In step 1706, a gradient filter window is applied to each of the reference samples to calculate the gradients. As shown in FIG. 18A, one N×N gradient filter window is applied to each template sample located in the center row / column of the template (i.e., the filter window is centered on the sample position) to calculate the corresponding horizontal gradient G h and the vertical gradient G v Calculate each of the following.

[0181] In step 1708, the angle (Angle) and the amplitude (Amp) of the gradient of the reference sample are calculated. For example, the gradient of the sample can be calculated according to equations (20) and (21).

number

number

[0182] In step 1710, the angle of the gradient can be transformed into one of the predefined directions, and the corresponding component in the HoG is updated. For example, as shown in Figure 18, the Amplitude in the HoG for each Angle is updated by adding the magnitude (Amp) of the sample gradient of that Angle. As a result, Amplitude is the cumulative magnitude.

[0183] In step 1712, the component of the HoG with the maximum accumulated strength is selected as the direction used to extrapolate neighboring samples for the cost function of the current block. For example, as shown in Figure 18, the maximum component is circled.

[0184] In the above method, the direction with the maximum strength is selected as the direction for sample extrapolation. Such a method may not always be reliable in the presence of some noise (e.g., coding noise caused by quantization errors and / or other coding modules). To solve this problem, certain conditions can be applied before the dominant gradient direction is adopted as the extrapolation direction.

[0185] For example, in one implementation, the selected dominant gradient direction may be enabled for sample extrapolation of the cost function calculation only if there are enough template samples belonging to the selected gradient direction (e.g., if the percentage of samples belonging to the selected direction is high enough, such as above a predefined threshold). Otherwise (e.g., the number of template samples belonging to the selected direction is not high enough), the default extrapolation (e.g., vertical extrapolation for the upper neighbor and horizontal extrapolation for the left neighbor) is still applied.

[0186] In another implementation, the selected dominant gradient direction may be enabled for sample extrapolation of the cost function calculation only if the gradient magnitude associated with the dominant gradient direction is sufficiently large (e.g., if the ratio of the magnitude of the selected gradient direction to the sum of the magnitudes of all gradient directions is greater than another predefined threshold). Otherwise (e.g., if the gradient magnitude of the selected direction is not significant), the default extrapolation is still applied.

[0187] In yet another implementation, the above constraints are applied together: the selected direction is only enabled for sample extrapolation of the current block if the number of template samples associated with the selected direction is sufficiently large and the gradient strength is sufficiently significant; otherwise, the default extrapolation is still applied.

[0188] In yet another implementation, when the selected dominant gradient direction is enabled, the direction perpendicular to the selected direction is used for sample extrapolation in the calculation of the cost function when predicting the code in one block.For example, when the selected direction is 45 degrees, 135 degrees is used as the direction for extrapolating samples along the top and left boundaries of the current block.Similarly, when the selected direction is 135 degrees, 45 degrees is used as the direction for extrapolating samples along the top and left boundaries of the current block.

[0189] In the above disclosed implementation, sign prediction is only applicable to predict the sign of coefficients located in the top-left 4×4 sub-block of one transform block (e.g., as shown in FIG. 7). In general, such a method is reasonable because most of the energy of a general transform block is usually concentrated along some transform coefficients at low frequencies. Correspondingly, the sign of transform coefficients in the top-left corner is statistically simpler than those located elsewhere. However, this assumption may not always be true. For example, in the case of inter-blocks with complex motion fields (e.g., sub-block inter-mode, where one inter-block is divided into multiple sub-blocks and each sub-block may have its own MV), there may be a large amount of edges generated along the boundaries between different motions in the predicted signal. In such a case, after applying the DCT / DST transform, non-negligible high-frequency transform coefficients will be generated, but these coefficients may protrude from the top-left 4×4 corner. The sign of the aforementioned high-frequency coefficients cannot be predicted according to the above disclosed sign prediction design.

[0190] In some alternative implementations, the area of ​​transform coefficients input to the forward LFNST and therefore later used for sign prediction may be expanded from some top-left 4×4 sub-blocks (e.g., as shown in FIG. 7) to further improve coding performance. For example, FIG. 19 is a diagram illustrating a sign prediction area for predicting the signs of transform coefficients according to some examples.

[0191] Specifically, the sign of the top-left A×B area of ​​the current transform block can be selected for prediction, where M and N are calculated according to (22).

number

[0192] In some implementations, different methods may be used for determining the value of TH. In one implementation, a fixed value (e.g., 8, 16, and 32, etc.) may be used for TH for all sequences and encoding scenarios. If the area size threshold TH is fixed, the encoder and decoder use the same value (i.e., not signaled) to determine the corresponding area when locating transform coefficients for code prediction. In another implementation, the encoder may be given the flexibility to determine the optimal area size threshold depending on the specific characteristics of the video sequence and the desired performance-complexity tradeoff, and signal the corresponding value from the encoder to the decoder.

[0193] In one exemplary method, the area size threshold may be selected from a set of fixed numbers such that only a fixed number of bits need to be included in the bitstream to signal to the decoder which size was selected. For example, assuming there are four allowed area size threshold values ​​{4, 8, 16, 32}, only two bits need to be signaled to indicate the particular value selected from the group. In another exemplary method, the area size threshold may be adaptively determined for a transform block at the encoder side. Thus, the value of the area size threshold may be any number. In such a case, a fixed length codeword cannot be used since the value of the area size threshold is an unknown value. Instead, some variable length codeword (e.g., exponential-Golomb and unary codes, etc.) may be applied to indicate the determined area size threshold value in the bitstream.

[0194] Furthermore, if the value of TH is transmitted in the bitstream, the value of TH can be signaled at different levels, such as video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), slice header and coding block level. If the value of TH is signaled at the sequence level (e.g., VPS or SPS), this means that one and the same area size threshold is shared for all transform blocks in a video sequence. If the value of TH is signaled at the picture / slice level (i.e., PPS or slice header), the area size threshold can be changed from picture to picture or slice to slice, respectively. Similarly, if the value is signaled at the coding block, the adaptability of the code prediction region is maximized, but this consumes more coding bits, since the value must be signaled separately for each individual coding block.

[0195] At the decoder side, the decoder can determine the code prediction area based on the size of the transform block and the area size threshold TH. If TH is a fixed value, TH may be pre-programmed in the decoder instead of being signaled in the bitstream. The decoder can use this pre-programmed fixed value for all sequences and scenarios. Otherwise, when TH is not a fixed value but is a value determined by the encoder, TH is signaled in the bitstream to the decoder. Thus, the decoder determines the code prediction area based on the size of the transform block and the signaled area size threshold TH.

[0196] In some implementations, the decoder may first determine at which level the area size threshold is signaled. As mentioned above, the TH may be signaled at different levels, such as the VPS, SPS, PPS, slice header and coded block levels. Based on the level at which the TH is signaled, the decoder may determine the extent to which the signaled TH should be applied. For example, if the TH is signaled at the VPS or SPS level, the decoder applies the TH to all transform blocks in the video sequence. If the TH is signaled at the PPS or slice header level, the decoder applies the TH to all transform blocks in the current picture / slice and reads a different TH for each different picture / slice. If the TH is signaled at the coded block level, the decoder applies a different TH read from the bitstream to each different coded block.

[0197] If the area size threshold is an adaptively determined value for the transform block, the decoder can determine the value of TH based on the codeword signaled in the bitstream. As mentioned above, TH can be signaled using a fixed length codeword if selected from a group of predefined values, or a variable length codeword if it is an arbitrary number adaptively determined for the transform block.

[0198] In some implementations, after determining what value of TH to apply to the current transform block, the decoder may determine a code prediction area based on the size of the transform block and the area size threshold TH, for example according to equation (22). For example, as shown in Figure 19, the width of the code prediction area A is determined to be the smaller of the width of the transform block and the area size threshold TH, and the height of the code prediction area B is determined to be the smaller of the height of the transform block and the area size threshold TH.

[0199] The extended code prediction area scheme is intended not to interfere with any of the code prediction techniques disclosed above and can be easily adapted and combined with the extended code prediction area to provide improved coding performance. As just one specific example, the extended code prediction area can be combined with code prediction reordering and LFNST code prediction.

[0200] In the above description, one context model is described as an example of coding the correctness of the predicted code in the code signaling bit. To be precise, the difference between each predicted code can be coded, and the true code with the corresponding "0" (or "1") indicates that the estimated code is the same (or not the same) as the true code. According to some implementations of the present disclosure, other context models can be used to entropy code the correctness of the code prediction to further improve the coding efficiency.

[0201] In the first exemplary method, the context of the level value (i.e., intensity) of the transform coefficient can be used to entropy code the correctness of the sign prediction. The reason is that the larger the intensity, the more likely it is to make a correct prediction. For example, when such a method is applied, the range of possible intensity values ​​can be divided into several segments, and different contexts can be assigned to the sign prediction entropy coding of the coefficients in different segments.

[0202] In some implementations, the range of intensities of the transform coefficients may be divided into a plurality of intensity segments, and a context may be assigned to each of the intensity segments for entropy coding sign signaling bits for the transform coefficients belonging to the intensity segment. Every two consecutive intensity segments among the plurality of intensity segments may be separated by a threshold value such that the intensity segments do not overlap.

[0203] In one embodiment, a threshold thres can be used to divide the range of transform coefficient magnitudes into two segments, namely (1,thres) and [thres,+∞]. With such a division, if a transform coefficient belongs to the first segment, one first context is assigned to code the sign of the transform coefficient. Otherwise, if the transform coefficient is included in the second segment, one second context is assigned to code the sign of the transform coefficient.

[0204] In various implementations, the threshold value (or values) can be determined and specified in various ways. In one exemplary method, the value can be fixed (e.g., 2, 3, ..., etc.) and can be pre-programmed into both the encoder and decoder sides. Thus, a fixed value is used on both the encoder and decoder sides, eliminating the need to signal a fixed value. In another exemplary method, the encoder can be given the freedom to choose an optimal threshold value and signal a corresponding value to the decoder.

[0205] As mentioned above, the strength of each of the transform coefficients is used to determine the context for encoding the code value of the transform coefficient at the encoder side. Therefore, at the decoder side, the strength of each of the transform coefficients is used accordingly to determine the context for decoding the code value of the transform coefficient. Since the transform coefficients are only obtained after the inverse quantization is performed at the decoder side, such a scheme may significantly increase the complexity of parsing the bitstream, because the inverse quantization needs to be performed at the parsing stage. To solve such a complexity problem, in one implementation, the decoder can directly use the level k of the transform coefficient (i.e., the quantized value of the transform coefficient parsed directly from the bitstream without applying the inverse quantization) to determine the context for encoding the code of one transform coefficient.

[0206] In another implementation, instead of directly using the level k parsed from the bitstream, the decoder can use the quantization index (i.e., quantIdx) to determine the context for coding the code of one transform coefficient. As described, in VVC / ECM, two scalar quantizers can be applied for quantization / dequantization. The apparent quantizer used for one transform coefficient is determined by the parity of the transform coefficient preceding the current transform coefficient. Thus, the quantization index for the transform coefficient can be used to determine the context for coding the code. As mentioned before, the quantization index can be calculated from the value of level k based on the transition state (i.e., state) of the current transform coefficient, for example according to equation (6).

[0207] In various implementations, all the above intensity / level-based context modeling methods can be combined with the transform coefficient selection scheme of the present disclosure described with respect to FIG. 13. For example, such a combination can be implemented in two different ways. In one way, the transform coefficients can be reordered, and the intensities / levels of the reordered transform coefficients (i.e., the intensities / levels after the transform coefficients are reordered) determine the corresponding contexts applied to code the signs of the transform coefficients in one transform block. In another way, the transform coefficients are not reordered, and the intensities / levels of the transform coefficients without reordering (i.e., the intensities / levels of the transform coefficients before the transform coefficients are reordered) are used to determine the contexts applied to code the signs of the transform coefficients in the transform block.

[0208] Figures 20A and 20B show two examples of context modeling for transform coefficient code prediction, respectively implementing the above two schemes. As shown in Figure 20A, when the first scheme is applied, the transform coefficients are sorted according to their intensities / levels, for example in the order of 6, 3, 2, 2, 1, 1, 1, and 1. The intensities / levels of the sorted transform coefficients are used to select the context of the code signaling bits included in the bitstream. The benefit of this first scheme is that the corresponding intensities / levels used for context modeling are matched with the transform coefficients whose codes are coded. When this first scheme is applied, the encoder / decoder needs to sort the transform coefficients before the codes are coded / decoded, which may increase the complexity of the bitstream parsing process and thus reduce the parsing capacity. Figure 20B shows an implementation of a second scheme that can avoid this parsing problem. In this second scheme, which is the second method, the intensities / levels of the unsorted transform coefficients are used to determine the context for coding the codes. Therefore, no reordering needs to be applied at the parsing stage, i.e. the strength / level used for context modeling may not be consistent with the code.

[0209] In the second method, the context of the scan position of the transform coefficient may be used to entropy code the sign prediction. For example, a single context may be applied to code the transform coefficients located at the first L positions of a transform block, while another context may be applied to code the signs of the coefficients at other positions. In one embodiment, the value of L may be set equal to 1. Thus, one context is assigned to code the sign of the first transform coefficient (i.e., DC coefficient) of a transform coefficient, and another context is assigned to code the signs of all other transform coefficients (i.e., AC coefficients). Alternatively, all the sign prediction positions in a transform block may be classified into different groups according to their importance (or probability of correct prediction), and each of the groups may be assigned a different context separately.

[0210] In a third method, information related to coding, such as coding mode context, block size, and component channel information, may be used for coding for code prediction. For example, different contexts may be used for inter and intra modes. In another example, different context models may be used for different blocks. In yet another example, different contexts may be used for luma and chroma components.

[0211] In the fourth method, the transform scheme for determining the transform coefficients can be used as a context for sign prediction.As mentioned above, there are multiple transform cores, such as MTS and LFNST, that are applied to compress the energy of the coefficients in one transform block.If the transform coefficients obtained from different transform cores can provide different statistical properties, different contexts can be used to entropy code the signs of the transform coefficients of different transforms.

[0212] Although the above context modeling schemes have been described separately, it is contemplated that any of the above context modeling schemes may be used together, and in fact each method may be freely combined to achieve different context designs.

[0213] FIG. 21 is a flow diagram of an example method 2100 for code prediction in block-based video coding according to some implementations of the present disclosure. The method 2100 may be implemented by a video processor associated with the video encoder 20 or the video decoder 30 and may include steps 2102-2108, which are described below. Some of the steps for carrying out the present disclosure provided herein may be optional. Furthermore, some of the steps may be performed simultaneously or in a different order than that shown in FIG. 21.

[0214] In step 2102, the video processor may apply a primary transform and a secondary transform to a transform block of a video frame of video to generate transform coefficients for the transform block.

[0215] In step 2104, the video processor may select a set of candidate transform coefficients from the transform coefficients for symbol prediction.

[0216] In step 2106, the video processor may apply a template-based hypothesis generation scheme to select a hypothesis from a plurality of candidate hypotheses for the set of candidate transform coefficients.

[0217] In step 2108, the video processor may determine that the combination of code candidates associated with the selected hypothesis is a set of predictive codes for the set of candidate transform coefficients.

[0218] According to the present disclosure, the method 2100 and FIG. 21 may be performed on a video encoder side or a video decoder side. When the method 2100 is performed on a video encoder side, the method 2100 can be considered as an encoding method for transform coefficient sign prediction on a video encoder side. Then, a sign signaling bit indicating the correctness of the sign prediction is generated and coded to be included in a bitstream transmitted to a decoder. When the method 2100 is performed on a video decoder side, the method 2100 can be considered as a decoding method for transform coefficient sign prediction on a video decoder side. The sign signaling bit is signaled to a decoder in a bitstream further including data of the quantization level of the coded transform coefficient. The decoder can correct the sign prediction using the sign signaling bit to estimate the original sign of the received transform coefficient. An exemplary encoding method and an exemplary decoding method for transform coefficient sign prediction on a video decoder side are provided below with reference to FIG. 22 and FIG. 23, respectively.

[0219] FIG. 22 is a flow diagram of an example video encoding method 2200 for transform coefficient sign prediction performed by a video encoder according to some implementations of the present disclosure. The method 2200 may be implemented by a video processor associated with the video encoder 20 and may include steps 2202-2122, described below. Some of the steps for performing the present disclosure provided herein may be optional. Furthermore, some of the steps may be performed simultaneously or in a different order than shown in FIG. 22.

[0220] In step 2202, the video processor may apply a linear transform to a transform block of a video frame of the video to generate coefficients for the transform block.

[0221] In step 2104, the video processor may apply a secondary transform to the sub-blocks in the transform block to generate transform coefficients for the transform block. In some implementations, the secondary transform may be a forward LFNST. In some implementations, the video processor may determine a sign prediction area for performing transform coefficient sign prediction.

[0222] In step 2206, the video processor may select a set of candidate transform coefficients from the transform coefficients for sign prediction. In some implementations, the candidate transform coefficients may be selected from the transform coefficients of the transform block sorted based on strength. For example, the transform coefficients may be sorted from highest strength to lowest strength, and the transform coefficient with the highest strength is selected to perform sign prediction.

[0223] At step 2208, the video processor may determine a plurality of combinations of code candidates for the set of candidate transform coefficients based on a total number of candidate transform coefficients in the set of candidate transform coefficients.

[0224] In step 2210, the video processor may apply a template-based hypothesis generation scheme to generate a number of candidate hypotheses for a number of combinations of code candidates, respectively.

[0225] In step 2212, the video processor may select a hypothesis associated with a minimum cost from a plurality of candidate hypotheses based on a cost function. In some implementations, the cost function may be calculated by extrapolating neighboring samples based on a dominant gradient direction. In some implementations, as described above, the dominant gradient direction must satisfy certain conditions before being adopted as an extrapolation direction for the purposes of calculating the cost function. The video processor may determine whether the aforementioned conditions are satisfied. If so, neighboring sample extrapolation is performed along the dominant gradient direction in the calculation of the cost function. Otherwise, a default extrapolation direction (e.g., vertical extrapolation for the upper neighbor and horizontal extrapolation for the left neighbor) may be used.

[0226] In step 2214, the video processor may determine that the combination of code candidates associated with the selected hypothesis is a set of predictive codes for the set of candidate transform coefficients.

[0227] In step 2216, the video processor may determine one or more contexts for entropy coding the sequence of code signaling bits for the set of candidate transform coefficients. In some implementations, one context model may be determined for the transform block. In some other implementations, different context models may be determined for different transform coefficients of the transform block. Different contexts may entropy code the sequence of code signaling bits based on different features of the transform coefficients. In a first example, the context is determined based on the strength of the set of candidate transform coefficients corresponding to the code signaling bits. In a second example, the context is determined based on the scan position of the candidate transform coefficients. In a third example, the context is determined based on the coding mode, block size, or component channel information of each of the candidate transform coefficients. In a fourth example, the context is determined based on the transform core applied to generate the candidate transform coefficients.

[0228] In step 2218, the video processor may generate a sequence of code signaling bits for the set of candidate transform coefficients according to one or more contexts. As described above, various context models and combinations of context models may be used to encode the correctness of the prediction code. In some implementations, the sequence of code signaling bits may be generated by applying a vector-based code prediction scheme.

[0229] In step 2220, the video processor may quantize the candidate transform coefficients to obtain quantization levels of the candidate transform coefficients.

[0230] In step 2222, the video processor may generate a bitstream including the sequence of sign signaling bits and coded data for the quantization levels of the candidate transform coefficients.

[0231] 23 is a flow diagram of an example video decoding method 2300 for transform coefficient sign prediction performed by a video decoder according to some implementations of the present disclosure. The method 2300 may be implemented by a video processor associated with the video decoder 30 and may include steps 2302-2318, described below. Some of the steps for performing the present disclosure provided herein may be optional. Furthermore, some of the steps may be performed simultaneously or in a different order than shown in FIG. 23.

[0232] In step 2302, the video processor may dequantize the set of candidate transform coefficients. In some implementations, the video processor may receive a bitstream including the sequence of code signaling bits and the quantized transform coefficients associated with the transform block. The video processor may generate dequantized transform coefficients from the quantized transform coefficients by the dequantization unit 86 of FIG. 3.

[0233] The set of candidate transform coefficients is used for transform coefficient sign prediction. The dequantized transform coefficients are associated with the transform block. The dequantized transform coefficients of the transform block in the video decoder 30 may be equivalent to the transform coefficients of the transform block in the video encoder 20. In some implementations, if the set of candidate transform coefficients is selected from the transform coefficients of the transform block sorted according to strength at the encoder side, the video processor of the decoder can sort the set of candidate transform coefficients parsed from the bitstream.

[0234] At step 2304, the video processor may determine a plurality of combinations of code candidates for the set of candidate transform coefficients based on a total number of candidate transform coefficients in the set of candidate transform coefficients.

[0235] In step 2306, the video processor may apply a template-based hypothesis generation scheme to generate a plurality of candidate hypotheses for a plurality of combinations of code candidates, respectively.

[0236] In step 2308, the video processor may select a hypothesis associated with a minimum cost from the multiple candidate hypotheses based on a cost function. In some implementations, the cost function may be calculated by extrapolating neighboring samples based on a dominant gradient direction, as described above.

[0237] At step 2310, the video processor may determine that the combination of code candidates associated with the selected hypothesis is a set of predictive codes for the set of candidate transform coefficients.

[0238] In step 2312, the video processor may determine one or more contexts to be used to entropy code a sequence of code signaling bits received from the encoder. The sequence of code signaling bits is included in a bitstream to be transmitted to the decoder. As described above, the code signaling bits may be entropy coded by the encoder using a single context model or multiple context models. The decoder may determine such contexts in order to decode the code signaling bits to obtain an indication of the correctness of the code prediction for the candidate transform coefficients.

[0239] In a first example, the context is determined based on the intensity of a set of candidate transform coefficients corresponding to the code signaling bit. For example, the intensities of the transform coefficients are included in a plurality of intensity segments, and a context is assigned to entropy code the code signaling bit for the transform coefficients belonging to each of the intensity segments. The video processor can determine the intensity segment to which the intensity of each of the candidate transform coefficients belongs, and can determine the context assigned to the intensity segment as the context used to entropy code the code signaling bit. Every two consecutive intensity segments among the plurality of intensity segments are separated by a threshold value, which may be a fixed value preprogrammed in the decoder, or a value determined by the encoder and signaled to the decoder. In some implementations, the intensity of the candidate transform coefficient is a quantization level of the candidate transform coefficient parsed directly from the bitstream without inverse quantization. In some implementations, the intensity of the candidate transform coefficient is a quantization index of the candidate transform coefficient.

[0240] In a second example, the context is determined based on the scan position of the candidate transform coefficient. For example, the scan positions of the transform coefficient are classified into a plurality of groups, and a context is assigned to entropy code the code signaling bit for the transform coefficient belonging to each of the groups. The video processor can determine a group to which the scan position of the candidate transform coefficient corresponding to the code signaling bit belongs from among the plurality of groups, and can determine a context to be assigned to the group as a context used to entropy code the code signaling bit.

[0241] In a third example, the context is determined based on the coding mode, block size, or component channel information of each of the candidate transform coefficients. In a fourth example, the context is determined based on the transform core applied to generate the candidate transform coefficients.

[0242] In step 2314, the video processor may decode the sequence of code signaling bits based on the one or more contexts.

[0243] In step 2316, the video processor may estimate original signs of the set of candidate transform coefficients based on the set of predictive signs and the sequence of decoded sign signaling bits received from the video encoder.

[0244] For example, referring to FIG. 15B, a set of predicted codes may include group #0 with value (1,0), group #2 with value (1,0), and group #3 with value (1,0), where 1 indicates a negative sign and 0 indicates a positive sign. A sequence of code signaling bits may include bit "0" of group #0, bit "1,1,0" of group #2, and bit "0" of group #3. It is determined that the estimated original code of group #0 is (1,0) because the bit of group #0 has a value of "0", which indicates that the predicted code for this group with a value of (1,0) is correct (e.g., the predicted code is the same as the original code). Since the first bit in the group #1 bits has a value of "1", which indicates that the predicted code for this group (1,0) is incorrect (e.g., the predicted code is not the same as the original code), it is determined that the estimated original code for (1,0) of group #1 is the XOR result of the predicted code for this group (1,0) and the second and third bits of group #1, "1,0" (e.g., estimated original code = XOR ((1,0), (1,0)) = (0,0)). Since the bit in group #2 has a value of "0", which indicates that the predicted code for this group having a value of (1,0) is correct (e.g., the predicted code is the same as the original code), it is determined that the estimated original code for group #2 is (1,0). The original code of the set of estimated candidate transform coefficients is then formed by concatenating each of the original codes of estimated groups #0, #1 and #2, which includes (1,0,0,0,1,0). As mentioned above, a video encoder can code the correctness of a predictive code using different context models, and the correction of the predictive code is adapted depending on these context models.

[0245] In step 2318, the video processor may update the dequantized transform coefficients based on the estimated original signs of the set of candidate transform coefficients. For example, the video processor may use the estimated original signs as the true signs of the dequantized transform coefficients in the transform block corresponding to the set of candidate transform coefficients.

[0246] In some implementations, after the dequantized transform coefficients are updated, the video processor may further apply an inverse primary transform and an inverse secondary transform to the dequantized transform coefficients to generate residual samples in a residual block corresponding to the transform block. The inverse secondary transform corresponds to a secondary transform including LFNST. The inverse primary transform corresponds to a primary transform including DCT-II, DCT-V, DCT-VIII, DST-I, DST-IV, DST-VII, or / and an identity transform.

[0247] In some implementations, the sequence of code signaling bits for the set of candidate transform coefficients is generated by the video encoder by applying, by the video encoder, a vector-based code prediction scheme to another set of predictive codes for another set of candidate transform coefficients selected at the video encoder side, the other set of candidate transform coefficients being transform coefficients at the video encoder side that correspond to the set of candidate transform coefficients at the video decoder side.

[0248] In some implementations, applying the vector-based code prediction scheme to other sets of predictive codes for other sets of candidate transform coefficients further includes dividing the other sets of candidate transform coefficients into multiple groups of candidate transform coefficients, and for each of the groups of candidate transform coefficients, generating one or more code signaling bits for the group of candidate transform coefficients based on whether an original code for the group of candidate transform coefficients is identical to a predictive code for the group of candidate transform coefficients.

[0249] In some implementations, generating one or more sign signaling bits for the group of candidate transform coefficients includes generating a bin having a value of 0 in response to an original sign of the group of candidate transform coefficients being identical to a predicted sign of the group of candidate transform coefficients, and adding the bin to the bitstream as a sign signaling bit. In some implementations, generating one or more sign signaling bits for the group of candidate transform coefficients includes generating a bin having a value of 1 in response to an original sign of the group of candidate transform coefficients not being identical to a predicted sign of the group of candidate transform coefficients, generating a set of additional bins to signal a corresponding correctness of the predicted sign of the group of candidate transform coefficients, and adding the bin and the set of additional bins to the bitstream as sign signaling bits.

[0250] 24 illustrates a computing environment 2410 coupled with a user interface 2450 according to some implementations of the present disclosure. The computing environment 2410 may be part of a data processing server. For example, a video processor in the video encoder 20 or the video decoder 30 disclosed above may be implemented using the computing environment 2410. The computing environment 2410 includes a processor 2420, a memory 2430, and an input / output (I / O) interface 2440.

[0251] The processor 2420 generally controls the overall operation of the computing environment 2410, such as operations associated with display, data acquisition, data communication, and image processing. The processor 2420 may comprise one or more processors for executing instructions to perform all or a portion of the steps of the methods described above. Additionally, the processor 2420 may comprise one or more modules that facilitate cooperation between the processor 2420 and other components. The processor 2420 may be a central processing unit (CPU), a microprocessor, a single chip machine, or a graphical processing unit (GPU), etc.

[0252] The memory 2430 is configured to store various types of data to support the operation of the computing environment 2410. The memory 2430 may include predefined software 2432. Examples of such data include instructions for any application or method operated on the computing environment 2410, video data, image data, etc. The memory 2430 may be implemented by using any type of volatile or non-volatile memory device, such as static random access memory (SRAM), electronically erasable programmable read-only memory (EEPROM), erasable and programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks, or a combination thereof.

[0253] The I / O interface 2440 provides an interface between the processor 2420 and a peripheral interface module, such as a keyboard, a click wheel, or buttons. The buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. The I / O interface 2440 may be coupled to an encoder and a decoder.

[0254] In some implementations, a non-transitory computer-readable storage medium including a plurality of programs executable on the processor 2420 of the computing environment 2410 to perform the above-described method, e.g., a plurality of programs in the memory 2430, is also provided. In one example, the plurality of programs may be executed by the processor 2420 of the computing environment 2410 to receive a bitstream or data stream including encoded video information (e.g., video blocks representing encoded video frames and / or associated one or more syntax elements, etc.) (e.g., from the video encoder 20 of FIG. 2), and further, the plurality of programs may be executed by the processor 2420 in the computing environment 2410 to perform the above-described decoding method in response to the received bitstream or data stream. In another example, a number of programs may be executed by the processor 2420 in the computing environment 2410 to perform the encoding method described above to encode video information (e.g., video blocks representing video frames and / or associated one or more syntax elements, etc.) for inclusion in a bitstream or datastream, and further, a number of programs may be executed by the processor 2420 in the computing environment 2410 to transmit the bitstream or datastream (e.g., to the video decoder 30 of FIG. 3). Alternatively, a non-transitory computer-readable storage medium may store a bitstream or datastream including encoded video information (e.g., video blocks representing encoded video frames and / or associated one or more syntax elements, etc.) generated by an encoder (e.g., the video encoder 20 of FIG. 2) using the encoding method described above for use by a decoder (e.g., the video decoder 30 of FIG. 3) in decoding video data. The non-transitory computer-readable storage medium may be, for example, a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, or an optical data storage device, etc.

[0255] In some implementations, a computing device is also provided that includes one or more processors (e.g., processor 2420) and a non-transitory computer-readable storage medium or memory 2430 storing a plurality of programs executable by the one or more processors, wherein the one or more processors are configured to perform the above method when execution of the plurality of programs is performed.

[0256] In some implementations, a computer program product is also provided that includes a number of programs executable by the processor 2420 in the computing environment 2410 to perform the above-described methods, e.g., a number of programs in the memory 2430. For example, the computer program product may comprise a non-transitory computer-readable storage medium.

[0257] In some implementations, the computing environment 2410 may be implemented by one or more ASICs, DSPs, digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs, GPUs, controllers, microcontrollers, microprocessors, or other electronic components for performing the methods described above.

[0258] The description of the present disclosure has been provided for purposes of illustration and is not intended to be exhaustive or to limit the present disclosure. Numerous modifications, changes and alternative implementations will be apparent to those skilled in the art having the benefit of the foregoing description and accompanying drawings provided.

[0259] Unless expressly stated otherwise, the order of steps of the method according to the present disclosure is only intended as an example, and the steps of the method according to the present disclosure are not limited to the order specifically described above, but can be changed according to actual conditions. Moreover, at least one of the steps of the method according to the present disclosure can be adjusted, combined, or deleted according to actual requirements.

[0260] The above examples have been chosen and described to explain the principles of the present disclosure and to enable those skilled in the art to understand the present disclosure in various implementations and to best utilize the underlying principles and various implementations with various modifications as appropriate for the particular use contemplated. Therefore, it should be understood that the scope of the present disclosure is not limited to the specific implementations disclosed, and modifications and other implementations are intended to be included within the scope of the present disclosure.

Claims

1. A video decoding method comprising: receiving a bitstream including a sequence of code signaling bits for a set of candidate transform coefficients; generating a set of predictive codes for the set of candidate transform coefficients associated with a transform block of a video frame; decoding the sequence of code signaling bits based on one or more contexts used to entropy code the sequence of code signaling bits to obtain an indication of correctness of the predicted code of each of the candidate transform coefficients; estimating original codes of the set of candidate transform coefficients based on the set of predictive codes and the sequence of decoded code signaling bits; A method comprising:

2. 2. The video decoding method of claim 1, comprising: estimating the original codes of the set of candidate transform coefficients based on the set of predictive codes and the sequence of code signaling bits; updating the predicted signs of the candidate transform coefficients in response to the correctness indicated by each of the sign signaling bits to determine the original signs of the candidate transform coefficients.

3. 2. The video decoding method of claim 1, comprising: decoding the sequence of code signaling bits; and determining, for each of the code signaling bits of the sequence of code signaling bits, a context to be used for entropy coding the code signaling bit based on a strength of the candidate transform coefficient corresponding to the code signaling bit.

4. 4. A video decoding method according to claim 3, comprising: Intensities of the candidate transform coefficients are included in a plurality of intensity segments, and a plurality of contexts are assigned for entropy coding sign signaling bits for the transform coefficients belonging to each of the intensity segments; determining the context to be used for entropy coding the code signaling bits; determining, from among the plurality of intensity segments, an intensity segment to which the intensity of the candidate transform coefficient corresponding to the code signaling bit belongs; determining the context to be assigned to the intensity segment as the context used to entropy code the code signaling bits; Including, method.

5. 5. A video decoding method according to claim 4, comprising: every two consecutive intensity segments among the plurality of intensity segments are separated by a threshold value; method.

6. 4. A video decoding method according to claim 3, comprising: the bitstream further comprises coded data of quantization levels of the set of candidate transform coefficients; determining the magnitudes of the candidate transform coefficients by directly parsing the quantization levels of the candidate transform coefficients from the bitstream without inverse quantization; or parsing quantization levels of the candidate transform coefficients from the bitstream; determining a quantization index for the candidate transform coefficient based on the quantization level of the candidate transform coefficient and a transition state of the candidate transform coefficient; determining the strengths of the candidate transform coefficients based on the quantization indexes of the candidate transform coefficients; A method comprising:

7. 2. The video decoding method of claim 1, comprising: the set of candidate transform coefficients is selected from transform coefficients of the transform block sorted according to intensity; Sorting the set of candidate transform coefficients parsed from the bitstream. The method further comprises:

8. 2. The video decoding method of claim 1, comprising: decoding the sequence of code signaling bits; for each of the code signaling bits of the sequence of code signaling bits, determining a context to be used for entropy coding the code signaling bit based on a scan position of the candidate transform coefficient corresponding to the code signaling bit. A method comprising:

9. 9. A video decoding method according to claim 8, comprising: the scan positions of the transform coefficients are classified into a plurality of groups, and a plurality of contexts are assigned for entropy coding sign signaling bits for the transform coefficients belonging to each of the groups; determining the context to be used for entropy coding the code signaling bits; determining a group to which the scan position of the candidate transform coefficient corresponding to the code signaling bit belongs from among the plurality of groups; determining the context assigned to the group as the context to be used for entropy coding the code signaling bits; Including, method.

10. 2. The video decoding method of claim 1, comprising: decoding the sequence of code signaling bits; for each of the code signaling bits of the sequence of code signaling bits, determining a context to be used for entropy coding the code signaling bit based on a coding mode, a block size, or component channel information of the candidate transform coefficients corresponding to the code signaling bit. Including, method.

11. 2. The video decoding method of claim 1, comprising: the set of transform coefficients in the bitstream are generated by applying a plurality of different transform cores; decoding the sequence of code signaling bits; for each of the code signaling bits of the sequence of code signaling bits, determining a context to be used for entropy coding the code signaling bit based on the transform core applied to generate the candidate transform coefficients corresponding to the code signaling bit. Including, method.

12. 2. The video decoding method of claim 1, comprising: generating the set of predictive codes for the set of candidate transform coefficients; generating a plurality of candidate hypotheses for the set of candidate transform coefficients; selecting a hypothesis from the plurality of candidate hypotheses as the set of predictive codes for the set of candidate transform coefficients; A method comprising:

13. A video encoding method comprising: obtaining a set of predictive codes for a set of candidate transform coefficients associated with a transform block of a video frame; determining one or more contexts for entropy coding a sequence of code signaling bits for the set of candidate transform coefficients; entropy coding a sequence of code signaling bits according to the one or more contexts, the code signaling bits being used to indicate correctness of the predicted code of each of the candidate transform coefficients compared to an original code of the set of candidate transform coefficients; storing the coded data of quantization levels of the candidate transform coefficients and the sequence of coded code signaling bits for the candidate transform coefficients in a bitstream; A method comprising:

14. 14. A video encoding method according to claim 13, comprising: the one or more contexts for entropy coding the sequence of code signaling bits are determined based on strengths of the set of candidate transform coefficients corresponding to the code signaling bits. method.

15. 15. A video encoding method according to claim 14, comprising: determining the one or more contexts for entropy coding the sequence of code signaling bits for the set of candidate transform coefficients; Dividing the range of intensities of the transform coefficients into a plurality of intensity segments; assigning a context to each of the intensity segments for entropy coding the sign signaling bits for the transform coefficients belonging to the intensity segments; Including, method.

16. 16. A video encoding method according to claim 15, comprising: every two consecutive intensity segments among the plurality of intensity segments are separated by a threshold value; method.

17. 1. A video encoding device, comprising: Memory and a processor coupled to the memory and configured to perform the video decoding method of any one of claims 1 to 12 or the video encoding method of any one of claims 13 to 16; A video encoding device comprising:

18. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the video decoding method of any one of claims 1 to 12 or the video encoding method of any one of claims 13 to 16.

19. A computer program having instructions for storing a bitstream, the bitstream comprising: Encoded video data decoded by a video decoding method according to any one of claims 1 to 12, or 17. A computer program comprising encoded video data produced by a video encoding method according to any one of claims 13 to 16.

20. A method for storing a bitstream, comprising: Executing a video encoding method according to any one of claims 13 to 16 to generate a bitstream; storing the bitstream.

Images