Symbol Prediction for Block-Based Video Coding

Abstract

According to an implementation of the present disclosure, a video decoding apparatus and method for transform coefficient sign prediction at a video decoder side are provided. The method may include receiving a bitstream including encoded data of transform coefficients of a transform block of a video frame from a video. The method may further include determining, by the decoder, a plurality of regions in the transform block, the plurality of regions including a code prediction area for performing code prediction and at least one other region. The method may further include parsing, by the decoder, the bitstream to obtain signs of transform coefficients associated with the plurality of regions of the transform block according to a region-based order used to signal the signs of the transform coefficients. The method may also include estimating, by the decoder, original signs for a set of candidate transform coefficients associated with the code prediction area of ​​the transform block, and updating the transform coefficients associated with the code prediction area based on the estimated original signs.

Description

Related Applications

[0001] This application is based on and claims the benefit of U.S. Provisional Application No. 63 / 300,187, filed January 17, 2022. This application further claims the benefit of PCT Application No. PCT / US22 / 53150, filed December 16, 2022, which claims the benefit of U.S. Provisional Application No. 63 / 290,307, filed December 16, 2021. This application further claims the benefit of PCT Application No. PCT / US22 / 49264, filed November 8, 2022, which claims the benefit of U.S. Provisional Application No. 63 / 277,705, filed November 10, 2021. This application is based on and claims the benefit of PCT Application No. PCT / US22 / 43607, filed September 15, 2022, which 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 based on and claims the benefit of PCT Application No. PCT / US22 / 40442, filed August 16, 2022, which 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. [Technical field]

[0002] This application relates to video coding and compression, and more particularly, to video processing systems and methods for symbol prediction in block-based video coding. [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 teleconferencing devices, video streaming devices, etc. The electronic devices transmit, receive, or exchange digital video data over communication networks and / or store the digital video data in storage devices. Due to the limited bandwidth capacity of communication networks and the limited memory resources of storage devices, video coding may be used to compress the video data according to one or more video coding standards before the video data is exchanged or stored. For example, video coding standards include Versatile Video Coding (VVC), Joint Exploration test Model (JEM), High-Efficiency Video Coding (HEVC / H.265), Advanced Video Coding (AVC / H.264), Moving Picture Expert Group (MPEG) coding, etc. Video coding typically employs prediction methods (e.g., inter-prediction, intra-prediction, etc.) that exploit redundancy inherent in video data. Video coding aims to compress video data into a format that uses a lower bit rate while avoiding or minimizing degradation of video quality. Summary of the Invention

[0004] According to an implementation of the present disclosure, a video decoding method for sign prediction of transform coefficients is provided. The method may include receiving a bitstream including encoded data of transform coefficients of a transform block of a video frame from a video. The method may further include determining, by a decoder, a plurality of regions in the transform block, the plurality of regions including a code prediction area for performing code prediction and at least one other region. The method may further include parsing, by the decoder, the bitstream to obtain encoded data of transform coefficients associated with the plurality of regions of the transform block according to a region-based order used to signal the encoded data of the transform coefficients. The method may also include estimating, by the decoder, original codes for a set of candidate transform coefficients associated with the code prediction area of ​​the transform block, and updating the transform coefficients associated with the code prediction area based on the estimated original codes.

[0005] According to implementations of the present disclosure, a video decoder apparatus is also provided, which may include a memory configured to implement a video decoding method for sign prediction of transform coefficients, as summarized above.

[0006] Implementations of the present disclosure also provide a non-transitory computer-readable storage medium having stored therein instructions that, when executed by a processor, cause the processor to perform a video decoding method for sign prediction of transform coefficients as summarized above. Implementations of the present disclosure also provide a non-transitory computer-readable storage medium having stored therein a bitstream including encoded data of transform coefficients of a transform block. The bitstream is decodable by the video decoding method for sign prediction of transform coefficients as summarized above.

[0007] According to implementations of the present disclosure, a video encoding method for sign prediction of transform coefficients is also provided. The video encoding method may include generating, by an encoder, transform coefficients of a transform block of a video frame from a video. The method may further include determining, by the encoder, a plurality of regions in the transform block, the plurality of regions including a sign prediction area in which sign prediction is performed and at least one other region. The method may also include predicting, by the encoder, signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block, and generating, by the encoder, a bitstream to signal signs of the transform coefficients associated with the plurality of regions of the transform block according to a region-based order.

[0008] According to implementations of the present disclosure, a video encoding device is also provided, which may include a memory configured to implement a video encoding method for sign prediction of transform coefficients as summarized above.

[0009] Implementations of the present disclosure also provide a non-transitory computer-readable storage medium having stored therein instructions that, when executed by a processor, cause the processor to perform a video encoding method for sign prediction of transform coefficients as summarized above. Implementations of the present disclosure further provide a non-transitory computer-readable storage medium having stored therein a bitstream generated by the video encoding method for sign prediction of transform coefficients as summarized above.

[0010] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory 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 consistent 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]1 is a block diagram illustrating an example system for encoding and decoding video blocks in accordance with some implementations of the present disclosure. [Diagram 2] 1 is a block diagram illustrating an example video encoder, in accordance with some implementations of the present disclosure. [Diagram 3] 1 is a block diagram illustrating an example video decoder, in accordance with some implementations of the present disclosure. [Figure 4A] 1 is a graphical representation showing 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 graphical representation showing 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 graphical representation showing 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 graphical representation showing 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 graphical representation showing 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 graphical representation illustrating a top-left scan order of transform coefficients in a coefficient group, according to some examples. [Figure 6] 1 is a graphical representation illustrating a low-frequency non-separable transform (LFNST) process, according to some examples. [Figure 7] 1 is a graphical representation showing a top left region of primary transform coefficients input to a forward LFNST, according to some examples. [Figure 8]1 is a graphical representation illustrating search areas for intra-template matching, according to some examples. [Figure 9] 1 is a graphical representation illustrating an example process of code prediction, according to some examples. [Figure 10] 1 is a graphical representation illustrating the computation of a cost function for symbol prediction, according to some examples. [Figure 11] 1 is a graphical representation illustrating two example scalar quantizers used in dependent scalar quantization, according to some examples. [Figure 12A] 1 is a graphical representation illustrating state transitions using a state machine having four states used in dependent scalar quantization, according to some examples. [Figure 12B] 12B is a table illustrating example quantizer selections for the state transitions of FIG. 12A, according to some examples. [Figure 13] 1 is a block diagram illustrating an example code prediction process in block-based video coding, in accordance with some implementations of the present disclosure. [Figure 14] 1 is a graphical representation illustrating an example of hypothesis generation based on a linear combination of templates, according to some implementations of the present disclosure. [Figure 15A] 1 is a graphical representation illustrating an implementation of an existing code prediction scheme, along with some examples. [Figure 15B] 1 is a graphical representation illustrating an example implementation of a vector-based code prediction scheme in accordance with some implementations of the present disclosure. [Figure 16A] 11 is a graphical representation illustrating an example of a left-diagonal cost function calculation along a left-diagonal direction, according to some implementations of the present disclosure. [Figure 16B] 11 is a graphical representation illustrating an example of a right-diagonal cost function calculation along a right-diagonal direction, according to some implementations of the present disclosure. [Figure 17] 1 is a flowchart of a method for capturing dominant gradient directions in neighboring reconstructed samples of a current block according to some implementations of the present disclosure. [Figure 18A]11 is a graphical representation showing example template samples and gradient filter windows in gradient-based selection of sample extrapolation direction for a cost function, according to some implementations of the present disclosure. [Figure 18B] 1 is a graphical representation illustrating an example histogram of gradients (HoG) for gradient-based selection of sample extrapolation directions for a cost function, according to some implementations of the present disclosure. [Figure 19] 1 is a graphical representation illustrating a sign prediction area for predicting signs of transform coefficients, according to some examples. [Figure 20] 1 is a graphical representation illustrating a partitioning of a transform block implementing an example order for signaling signs of transform coefficients from an encoder to a decoder, in accordance with some examples. [Figure 21] 1 is a graphical representation illustrating various scan orders for scanning signs of transform coefficients, according to some examples. [Figure 22] 21 is a graphical representation illustrating implementations of various scan orders for transform blocks partitioned according to FIG. 20, according to some examples. [Diagram 23] 1 is a graphical representation illustrating a partitioning of a transform block implementing another example order for signaling signs of transform coefficients from an encoder to a decoder, in accordance with some examples. [Figure 24] 21 is a graphical representation illustrating implementations of various scan orders for transform blocks partitioned according to FIG. 20, according to some examples. [Figure 25A] 1 is a graphical representation illustrating an example context modeling for transform coefficient sign prediction, according to some implementations of the present disclosure. [Figure 25B] 1 is a graphical representation illustrating another example of context modeling for transform coefficient sign prediction, according to some implementations of the present disclosure. [Figure 26] 1 is a flowchart of an example method for symbol prediction in block-based video coding in accordance with some implementations of this disclosure. [Figure 27] 4 is a flowchart of an example video encoding method for transform coefficient sign prediction performed by a video encoder, in accordance with some implementations of this disclosure. [Figure 28] 4 is a flowchart of an example video decoding method for transform coefficient sign prediction performed by a video decoder in accordance with some implementations of this disclosure. [Figure 29] FIG. 1 is a block diagram illustrating a computing environment in conjunction with a user interface, in accordance with some implementations of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] A specific implementation, an example of which is shown in the accompanying drawings, is described in detail below. In the following detailed description, numerous non-limiting specific details are set forth to aid in the understanding of the subject matter presented herein. However, it will be apparent to one skilled in the art that various alternatives may be used and the subject matter may be practiced without these specific details without departing from the scope of the claims. For example, it will be apparent to one skilled in the art that the subject matter presented herein may be implemented in a variety of electronic devices having digital imaging capabilities.

[0014] It should be explained that the terms "first", "second", etc. used in the specification, claims, and accompanying drawings of the present disclosure are used to distinguish objects, and not to describe a particular order or sequence. It will be understood that data used in the methods may be substituted under appropriate conditions so that the embodiments of the present disclosure described herein are implemented in the order and in the order shown in the accompanying drawings or in the order described in the present disclosure.

[0015] 1 is a block diagram illustrating an example system 10 for encoding and decoding video blocks in parallel in accordance with some implementations of the present disclosure. As shown in FIG. 1, system 10 includes a source device 12 that generates and encodes video data that is subsequently decoded by a destination device 14. Source device 12 and 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, video streaming devices, and the like. In some implementations, source device 12 and destination device 14 include wireless communication capabilities.

[0016] In some implementations, destination device 14 may receive the encoded video data to be decoded via link 16. Link 16 may include any type of communication medium or device capable of transferring encoded video data from source device 12 to destination device 14. In one example, link 16 may include a communication medium to enable source device 12 to transmit encoded video data directly to destination device 14 in real time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to destination device 14. The communication medium may include any wireless or wired communication medium, such as the Radio Frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may help facilitate communication from source device 12 to destination device 14.

[0017] In some other implementations, the encoded video data may be transmitted from output interface 22 to storage device 32. The encoded video data in storage device 32 may then be accessed by destination device 14 via input interface 28. Storage device 32 may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, Blu-ray disc, Digital Versatile Disk (DVD), Compact Disc Read-Only Memory (CD-ROM), flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In a further example, storage device 32 may correspond to a file server or another intermediate storage device capable of storing the encoded video data generated by source device 12. Destination device 14 may access the stored video data from storage device 32 by streaming or downloading. The file server may be any type of computer capable of storing the encoded video data and transmitting the encoded video data to destination device 14. A file server may include, for example, a web server (e.g., for a website), a File Transfer Protocol (FTP) server, a Network Attached Storage (NAS) device, or a local disk drive. Destination device 14 may access the encoded video data through any standard data connection suitable for accessing the encoded video data stored on a file server, 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. Transmission of the encoded video data from storage device 32 may be a streaming transmission, a download transmission, or a combination of both.

[0018] As shown in Figure 1, source device 12 comprises a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources such as video capture devices, e.g., video cameras, video archives containing pre-captured video, video supply interfaces receiving video data from video content providers, and / or computer graphics systems generating computer graphics data such as source video, or a combination of such sources. As an example, if video source 18 is a video camera in a security surveillance system, source device 12 and destination device 14 may comprise camera phones or video phones. However, implementations described in this disclosure may be applicable to video coding generally 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. The encoded video data may also (or alternatively) be stored in storage 32 for later access by destination device 14 or other devices for decoding and / or playback. 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 exchanged 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 within the encoded video data transmitted on a communications medium, stored on a storage medium, or stored on a file server.

[0021] In some implementations, destination device 14 may include a display device 34. Display device 34 may be an integrated 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 to such standards. It will be appreciated that this disclosure is not limited to a particular video encoding / decoding standard and may be applicable to other video encoding / decoding standards. It is contemplated that video encoder 20 of source device 12 is typically configured to encode video data according to any of these current or future standards. Similarly, it is contemplated that video decoder 30 of destination device 14 is typically configured to decode video data according to any of these current or future standards.

[0023] Video encoder 20 and video decoder 30 may each be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When implemented partially in software, an electronic device may store instructions for the software on a suitable, non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the video encoding / decoding operations illustrated in this disclosure. Each of video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, either of which may be integrated 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 herein. Video encoder 20 may perform intra- and inter-predictive coding of video blocks within video frames. 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 synonymously with the terms "image" or "picture" in the field of video coding.

[0025] As shown in FIG. 2, video encoder 20 includes video data memory 40, prediction processing unit 41, decoded picture buffer (DPB) 64, analog summer 50, transform processing unit 52, quantization unit 54, and entropy coding unit 56. Prediction processing unit 41 further includes motion estimation unit 42, motion compensation unit 44, partition unit 45, intra prediction processing unit 46, and intra block copy (BC) unit 48. In some implementations, video encoder 20 also includes inverse quantization unit 58, inverse transform processing unit 60, and analog summer 62 for video block reconstruction. An in-loop filter 63, such as a deblocking filter, may be located between analog summer 62 and DPB 64 to filter block boundaries and remove block artifacts from the reconstructed video data. Another in-loop filter, such as an SAO filter and / or an adaptive in-loop filter (ALF), may be used in addition to the deblocking filter to filter the output of analog summer 62. In some examples, the in-loop filter may be omitted and the decoded video blocks may be provided directly to DPB 64 by analog summer 62. Video encoder 20 may take the form of a non-programmable or programmable hardware unit, or may be divided among 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) used in encoding the video data by video encoder 20 (e.g., in intra- or inter-predictive coding 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 those components.

[0027] As shown in FIG. 2, after receiving the video data, a division unit 45 in the prediction processing unit 41 divides the video data into video blocks. This division may include dividing the video frame into slices, tiles (e.g., a set of video blocks), or other larger coding units (CUs) according to a predefined split structure, such as a Quad-Tree (QT) structure associated with the video data. A video frame may be viewed or considered as a two-dimensional array or matrix of samples having sample values. The samples in the array may be referred to as pixels or pels. A number of samples in the horizontal and vertical directions (or axes) of the array or picture defines a size and / or resolution of the video frame. A video frame may be partitioned into multiple video blocks, for example, using QT partitioning. Furthermore, a video block may be viewed or considered as a two-dimensional array or matrix of samples having sample values, although with smaller dimensions than a video frame. A number of samples in the horizontal and vertical directions (or axes) of a video block defines a size of a video block. A video block may be further divided into one or more block partitions or sub-blocks (which may further form blocks), e.g., using QT partitioning, Binary-Tree (BT) partitioning, Triple-Tree (TT) partitioning, or any combination thereof repeatedly. It should be noted that the term "block" or "video block" as used herein may refer to a portion of a frame or picture, in particular a rectangular (square or non-square) portion.For example, with reference to HEVC and VVC, a block or video block may be or may correspond to a Coding Tree Unit (CTU), a CU, a Prediction Unit (PU), or a Transform Unit (TU), and / or may be or may correspond to a corresponding block, such as a Coding Tree Block (CTB), a Coding Block (CB), a Prediction Block (PB), or a Transform Block (TB). Alternatively or additionally, a block or video block may be or may correspond to a sub-block, such as a CTB, CB, PB, TB, etc.

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

[0029] To select an appropriate intra-predictive coding mode for a current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-predictive coding of the current video block relative to one or more neighboring blocks in the same frame as the current block to be coded, resulting in spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 may perform inter-predictive coding of the current video block relative to one or more predictive blocks in one or more reference frames, resulting in temporal prediction. Video encoder 20 may perform multiple coding passes, e.g., select an appropriate 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. A motion vector indicates the displacement of a video block in a current video frame relative to a predictive block in a reference frame according to a predetermined pattern in a sequence of video frames. Motion estimation performed by motion estimation unit 42 may be a process of generating motion vectors that may estimate the motion of 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 vectors, e.g., block vectors, for intra BC coding in a manner similar to the determination of motion vectors by motion estimation unit 42 for inter prediction, or may utilize motion estimation unit 42 to determine block vectors.

[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 deemed to closely match the video block being coded in terms of pixel differences, which may be determined by Sum of Absolute Difference (SAD), Sum of Square Difference (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 full-pixel 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 the first reference frame list (List 0) or the second reference frame list (List 1). The first reference frame list (List 0) and the second reference frame list (List 1) each identify 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 encoding 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 a motion vector for a current video block, motion compensation unit 44 may locate the predictive block pointed to by the motion vector in one of the reference frame lists, retrieve the predictive block from DPB 64, and forward the predictive block to analog summer 50. Analog 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 generate syntax elements associated with the video block of the video frame for use by video decoder 30 in decoding the video block of the video frame. The syntax elements may include, for example, syntax elements defining the motion vector used to identify the predictive block, any flags indicating a prediction mode, or any other syntax information described herein. It is noted that motion estimation unit 42 and motion compensation unit 44, which are shown separately for conceptual purposes in FIG. 2, may be integrated into one.

[0034] In some implementations, the intra BC unit 48 may generate vectors and fetch predictive blocks in a manner similar to that described above in connection with the motion estimation unit 42 and the motion compensation unit 44, except that the predictive block is in the same frame as the current block being coded, and the vectors are referred to as block vectors as opposed to motion vectors. In particular, the intra BC unit 48 may determine an intra prediction mode to use 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 another coding pass, and test their performance through rate-distortion analysis. The intra BC unit 48 may then select an appropriate intra prediction mode to use from 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 from the tested modes as the appropriate intra prediction mode to use. The rate-distortion analysis typically determines the amount of distortion (or error) between a coded block and the original, uncoded block that was coded to create the coded block, and the bitrate (i.e., number of bits) used to create the coded block. Intra BC unit 48 may calculate ratios from the distortions and rates for the various coded blocks and determine which intra prediction mode exhibits the best rate-distortion value for the block.

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

[0036] Whether the predictive block is from the same frame according to intra prediction or from 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 coded, i.e., forming pixel difference values. The pixel difference values ​​forming 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 different 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 indicating the selected intra-prediction mode for the block to entropy coding unit 56. Entropy coding unit 56 may encode the information indicating the selected intra-prediction mode into the bitstream.

[0038] After prediction processing unit 41 determines a prediction block for a current video block using either inter- or intra-prediction, analog summer 50 subtracts the prediction block from the current video block to form a residual 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] Following quantization, entropy encoding 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 methodology or technique. The encoded bitstream may then be transmitted to video decoder 30 as shown in FIG. 1 or archived in storage device 32 as shown in FIG. 1 for later transmission to or retrieval by video decoder 30. Entropy encoding unit 56 may use entropy coding techniques to encode motion vectors and other syntax elements for the current video frame being coded.

[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 from which the 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 apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values ​​for use in motion estimation.

[0042] Analog summer 62 adds the reconstructed residual block to the motion compensated prediction block produced by motion compensation unit 44 to create 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 prediction 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 analog summer 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 generally perform a decoding process that is reciprocal to the encoding process described above for the video encoder 20 in conjunction 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 indicator received from the entropy decoding unit 80.

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

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

[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 may use entropy decoding techniques to decode the bitstream to obtain quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Entropy decoding unit 80 then forwards the motion vectors or intra-prediction mode indicators, and other syntax elements to prediction processing unit 81.

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

[0048] When a video frame is coded as an inter-predictive coded (i.e., B or P) frame, motion compensation unit 82 of prediction processing unit 81 creates one or more prediction blocks for 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 created 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 coded according to the intra BC mode described herein, intra BC unit 85 of prediction processing unit 81 creates 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 processed by video encoder 20.

[0050] Motion compensation unit 82 and / or intra BC unit 85 determine prediction information for video blocks of the current video frame by parsing the motion vectors and other syntax elements, and then use the prediction information to create 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 the prediction mode (e.g., intra or inter prediction) used to code the video blocks of the video frame, the inter prediction frame type (e.g., B or P), configuration information for one or more of the reference frame lists for the frame, the motion vector for each inter predictive coded video block of the frame, the inter prediction status for each inter predictive coded video block of the frame, and other information for decoding video blocks in the current video frame.

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

[0052] Motion compensation unit 82 may perform interpolation using an interpolation filter as used by video encoder 20 during encoding of the video block to calculate interpolated values ​​for sub-integer pixels of the reference block. In this case, motion compensation unit 82 may determine from the received syntax elements the interpolation filter used by video encoder 20 and use that interpolation filter to create 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, e.g., 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 prediction block for the current video block based on the vectors and other syntax elements, analog 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 prediction block generated by motion compensation unit 82 and intra BC unit 85. The decoded video block may be referred to as a reconstructed block for the current video block. An in-loop filter 91, such as a deblocking filter, SAO filter, and / or ALF, may be positioned between analog 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 analog summer 90. The decoded video blocks in a given frame are then stored in DPB 92. DPB 92 stores reference frames used for motion compensation of subsequent, next video blocks. DPB 92, or a memory device separate from DPB 92, may store the decoded video for later presentation on a display device, such as display device 34 of FIG.

[0055] In a typical video coding process (including, for example, video encoding and decoding processes), a video sequence typically includes an ordered set of frames or pictures. Each frame may include three sample arrays, denoted 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 another example, the frame is monochrome and therefore includes only one two-dimensional array of luma samples.

[0056] As shown in FIG. 4A, video encoder 20 (or, more specifically, splitting unit 45) generates an encoded representation of a frame by first splitting the frame into a series of CTUs. A video frame may include an integer number of CTUs arranged consecutively from left to right and from top to bottom in raster scan order. Each CTU is the largest logical coding unit, and the width and height of the CTUs are signaled by video encoder 20 in a sequence parameter set such that the CTUs in a video sequence all have the same size, which is one of 128×128, 64×64, 32×32, and 16×16. However, it should be noted that the CTUs in this disclosure are not necessarily limited to a particular size. As shown in FIG. 4B, each CTU may include one CTB of luma samples, two corresponding coding tree blocks of chroma samples, and syntax elements used to code the samples of the coding tree blocks. The syntax elements describe the nature of various types of units of coding blocks of pixels and how the video sequence may be reconstructed at video decoder 30, and include inter or intra prediction, intra prediction modes, motion vectors, and other parameters. In a monochrome picture or a picture with three separate color planes, a CTU may include a single coding tree block and syntax elements used to code samples of the coding tree block. A coding tree block may be an N by 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 block 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. Of 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 as shown in FIG. 4C, where each leaf node of the quad tree corresponds to one CU of a respective size ranging from 32×32 to 8×8. As in the CTU shown in FIG. 4B, each CU may include one CB of luma samples and two corresponding coding blocks of chroma samples of the same size frame, as well as syntax elements used to code the samples of the coding blocks. In a monochrome picture or a picture with three separate color planes, a CU may include a single coding block and syntax structures used to code the samples of the coding block. It should be noted that the quad-tree partitioning shown in FIG. 4C and FIG. 4D is for illustrative purposes only, and one CTU can be divided into multiple CUs to meet various local characteristics based on 4 / 3 / 2-tree partitioning. In a multi-type tree structure, one CTU is divided by a quad-tree structure, and the CUs that are the leaves of each quad-tree can be further divided by 2- and 3-ary tree structures.As shown in FIG. 4E, for a coding block having width W and height H, there are multiple possible partitioning types, namely, quaternary partitioning, vertical binary partitioning, horizontal binary partitioning, vertical ternary partitioning, vertical extended ternary partitioning, horizontal ternary partitioning, and horizontal extended ternary partitioning.

[0058] In some implementations, video encoder 20 may further divide a coding block of a CU into one or more M×N PBs. A PB may include a rectangular (square or non-square) block of samples to which the same prediction, inter or intra, is applied. A PU of a CU may include a PB of luma samples and two corresponding PBs of chroma samples, and syntax elements used to predict the PB. In a monochrome picture or a picture with three separate 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 use intra prediction or inter prediction to generate predictive blocks for a PU. If video encoder 20 uses intra prediction to generate predictive blocks for a PU, video encoder 20 may generate the predictive blocks for the PU based on decoded samples of a frame associated with the PU. If video encoder 20 uses inter prediction to generate predictive blocks for a PU, video encoder 20 may generate the 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 for the CU by subtracting the predictive luma block of the CU from its original luma coding block, such that each sample in the luma residual block of the CU indicates a difference between a luma sample in one of the predictive luma blocks of the CU and a corresponding sample in the original luma coding block of the CU. Similarly, video encoder 20 may generate Cb and Cr residual blocks for 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 indicates 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 corresponding transform blocks of 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), video encoder 20 may quantize the coefficient block. Quantization generally refers to a process in which transform coefficients are quantized to possibly reduce the amount of data used to represent the transform coefficients, resulting in further compression. After video encoder 20 quantizes the coefficient block, video encoder 20 may apply an entropy coding technique to encode syntax elements indicating the quantized transform coefficients. For example, video encoder 20 may perform CABAC on the syntax elements indicating the quantized transform coefficients. Finally, video encoder 20 may output a bitstream including a series of bits forming a representation of the coded frame and associated data, which may be stored in storage device 32 or transmitted to destination device 14.

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

[0065] As mentioned above, video coding compresses video using two main modes: intra-frame prediction (or intra-prediction) and inter-frame prediction (or inter-prediction). Note that intra block copy (IBC) may be considered either intra-frame prediction or a third mode. Between the two modes, inter-frame prediction has better coding efficiency than intra-frame prediction because it uses motion vectors to predict a current video block from a reference video block.

[0066] However, as video data capture technology improves day by day, and video block sizes to preserve details of video data are also refined, the amount of data required to represent motion vectors for a current frame is also increasing significantly. One way to overcome this challenge is to benefit from the fact that a group of neighboring CUs in both spatial and temporal domains not only have similar video data for prediction purposes, but also the motion vectors between these neighboring CUs are similar. Therefore, by investigating the spatial and temporal correlations, also called the "Motion Vector Predictor (MVP)" of the current CU, 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.

[0067] Instead of encoding the actual motion vector of the current CU into the video bitstream (e.g., the actual motion vector determined by motion estimation unit 42 as described above in connection with FIG. 2), a motion vector predictor for the current CU is subtracted from the actual motion vector of the current CU to create a Motion Vector Difference (MVD) for the current CU. In this way, the motion vector determined by motion estimation unit 42 for each CU of a frame does not need to be encoded into the video bitstream, significantly reducing the amount of data used to represent motion information in the video bitstream.

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

[0069] A brief description is given herein of transform coefficient coding in a block-based video coding process (e.g., in Enhanced Compression Model (ECM)). Specifically, each transform block is first partitioned into multiple coefficient groups (CG), each of which includes transform coefficients of a 4×4 sub-block for luma components and a 2×2 sub-block for chroma components. The coding of transform coefficients in a transform block is performed on a coefficient group basis. For example, the coefficient groups inside the 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 based on a second predetermined scanning order within each sub-block. In ECM, the same top-left scanning order is applied to scan the coefficient groups inside the transform block and the different transform coefficients in each coefficient group (e.g., both the first and second predetermined scanning orders are top-left scanning orders). FIG. 5 is a graphical representation illustrating a top-left scanning order of transform coefficients in a coefficient group according to some examples. The numbers 0 through 15 in FIG. 5 indicate the corresponding scan order of each transform coefficient in the coefficient group.

[0070] According to the transform coefficient coding scheme in ECM, first, a flag is signaled for each transform block to indicate whether the transform block includes any non-zero transform coefficient. If there is at least one non-zero transform coefficient 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 video encoder 20 to video decoder 30. Due to the position of the last non-zero transform coefficient being signaled, flags are further signaled for all coefficient groups that are coded before the last coefficient group (i.e., the coefficient group that includes the last non-zero coefficient). Accordingly, the flags indicate whether the respective coefficient groups include non-zero transform coefficients. If the flag of a coefficient group is equal to zero (indicating that the transform coefficients in the coefficient group are all zero), no further information needs to be transmitted for the coefficient group. Otherwise (e.g., if the flag of a coefficient group is equal to one), the absolute value and sign of each transform coefficient in the coefficient group are signaled in the bitstream according to the scanning order. However, in the existing design, the sign of the transform coefficient is bypass coded (e.g., the context model is not applied), leading to inefficient transform coding in the current design. Consistent with this disclosure, an improved LFNST process involving sign prediction of transform coefficients is described in more detail below to improve transform coding efficiency.

[0071] FIG. 6 is a graphical representation 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 video encoder 20, and a backward LFNST 608 is applied between an inverse quantization 607 and a backward primary transform 609 in video decoder 30. For example, an LFNST process may include both a forward LFNST 604 and a backward LFNST 608. As some examples, for a 4×4 forward LFNST 604, there are 16 input coefficients, for an 8×8 forward LFNST 604, there are 64 input coefficients, for a 4×4 backward LFNST 608, there are 8 input coefficients, and for an 8×8 backward LFNST 608, there are 16 input coefficients.

[0072] In the forward LFNST 604, a non-separable transform with different transform sizes is applied based on the size of the coding block, which 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 a matrix X as shown in Equation (1) below.

number

[0073] JPEG2025501981000003.jpg9166

number

[0074] In the above equation (1) or (2), X denotes the coefficient matrix obtained through the forward linear transform 603, and X ij Let X denote the linear transform coefficients in the matrix X. Then, according to equation (3), a forward LFNST 604 is applied as follows:

number

[0075] JPEG2025501981000006.jpg45166

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

[0077] In the above formula (4), T R×N The R-based vectors in are generated by selecting the first R bases of the original N-dimensional transform kernel (i.e., N×N). Additionally, assuming that T R×N is orthogonal, the inverse transform matrix for the inverse LFNST 608 is the transpose matrix of the forward transform matrix T R×N .

[0078] For an 8×8 LFNST, when coefficients N / R=4 are applied, the 64×64 transform matrix is ​​reduced to a 16×48 transform matrix for the forward LFNST 604, and the 64×64 inverse transform matrix is ​​reduced to a 48×16 inverse transform matrix for the inverse LFNST 608. This is achieved by applying the LFNST process to an 8×8 sub-block in the top-left region of the primary transform coefficients. Specifically, when a 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 4×4 sub-block to its bottom right) are taken as input. In some examples, the LFNST process is restricted to be applicable only when the transform coefficients outside the top-left 4×4 sub-block are all zero, which implies that when applied with LFNST, all primary-only transform coefficients must be zero. Furthermore, to control worst-case complexity (in terms of per-pixel multiplications), the LFNST matrices for 4×4 and 8×8 coding blocks are constrained to be 8×16 and 8×48 transforms, respectively. For 4×M and M×4 coding blocks (M>4), the non-separable transform matrix for LFNST is 16×16.

[0079] In signaling the LFNST transform, there are four transform sets in total, and two non-separable transform kernels are available per transform set 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 predefined 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, LFNST is restricted to be applied to intra blocks when all transform coefficients outside the first 16x16 sub-block are zero, so the signaling of the LFNST index depends on the location of the last significant (i.e., non-zero) transform coefficient. For example, for 4x4 and 8x8 coding blocks, the LFNST index is signaled only when the location of the last significant transform coefficient is less than 8. For other coding block sizes, the LFNST index is signaled only when the location of the last significant transform coefficient is less than 16. Otherwise (i.e., when the LFNST index is not signaled), the LFNST index is presumed to be zero, i.e., LFNST does not work.

[0081] Furthermore, to reduce the size of the buffer for caching transform coefficients, LFNST is rejected when either the width or height of the current coding block is larger than the maximum transform size (i.e., 64) as signaled in the sequence parameter set (SPS). Meanwhile, LFNST is only applied when the primary transform is DCT2. LFNST is also applied to intra-coded blocks in both intra and inter slices and for both luma and chroma components. When a dual tree or local tree is available (where the splits of luma and chroma components are misaligned), LFNST indices are signaled separately for luma and chroma components (i.e., luma and chroma components can apply different LFNST transforms). Otherwise, when a single tree is applied (where the splits of luma and chroma components are aligned), LFSNT is only applied to the luma component with a single LFNST index signaled.

[0082] The LFNST design in ECM is similar to that in VVC, except that an additional LFNST kernel is introduced to provide better energy compaction for residual samples with large block sizes. Specifically, when the width or height of a transform block is 16 or more, a 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. Additionally, to control the worst-case computational complexity, the number of coefficient outputs of the forward LFNST 604 is set to 32.

[0083] Specifically, for a W×H transform block, where W≧16 and H≧16, a 32×96 forward LFNST is applied, taking as input 96 transform coefficients from the six 4×4 sub-blocks in the top-left region, and outputting 32 transform coefficients. On the other hand, an 8×8 LFNST in ECM utilizes 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 backward LFNST 608). This differs from VVC, where the 8×8 LFNST is only applied to the three 4×4 sub-blocks in the top-left region, and generates only 16 transform coefficients (i.e., a 16×48 matrix for forward LFNST 604, and a 48×16 matrix for backward LFNST 608). Additionally, the total number of LFNST sets is increased from four 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- and intra-coded blocks. The MTS scheme uses multiple selected transforms from the DCT8 and DST7 transforms.

[0085] For example, at the sequence level, when two control flags are specified, the MTS scheme for intra and inter modes is enabled 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 signaled only 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 zero, DCT2 is applied in both horizontal and vertical directions. If the MTS CU flag is equal to 1, two other flags are additionally signaled to indicate the transform type for the horizontal and vertical directions, respectively. The mapping between the MTS horizontal and vertical control flags and the applied transform is shown in Table 2 below. [Table 2]

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

[0087] In VVC, in addition to DCT2, only DST7 and DCT8 transform kernels are used for intra- and inter-coding. For intra-coding, the statistical properties of the residual signal usually depend on the intra-prediction mode. Additional linear transforms can be beneficial to address the diversity of the residual properties.

[0088] Additional linear transforms including DCT5, DST4, DST1, and identity transform (IDT) are employed in ECM. Also, the MTS set is created by TU size and intra-mode information. 16 different TU sizes are considered, and 5 different classes per TU size are considered by intra-mode information. For each class, 4 different transform pairs are considered (same as in VVC). In total, 80 different classes are considered, but some of the different classes often share the same transform set. Thus, there are 58 (less than 80) unique entries in the resulting Lookup 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 order of the horizontal and vertical transform kernels is swapped. For example, a 16×4 block (horizontal prediction) of mode 18 and a 4×16 block (vertical prediction) of mode 50 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 from -2 to -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 a reconstructed portion of the current frame, whose L-shaped template matches the current template. For a given search range, video encoder 20 searches in the reconstructed portion of the current frame for a template that is most similar to the current template (e.g., based on SAD cost) and uses the corresponding block as the prediction block. Video encoder 20 then 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 causal neighboring blocks of the current block with other blocks in a given search area as shown in FIG. 8, including (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 available 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. When intra template matching is applied to a coding block with a width or height between 4 and 16 (inclusive), the linear transform applied to the corresponding dimension is set to DCT-VII. Otherwise (i.e., if the width or height is less than 4 or greater than 16), DCT-II is applied to the dimension.

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

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

[0093] In some implementations, for each of the M code combinations, the M corresponding transform coefficients may be processed through an inverse quantization operation and an inverse transform to generate a corresponding hypothesis to obtain residual samples, as shown in Figure 9. The residual samples may be added with the prediction samples to obtain reconstructed samples, including the reconstructed samples at the top and left boundaries of the current block (shown in the L-shaped grey area 902).

[0094] In some implementations, a cost function is used to select the code combination that measures the spatial discontinuity between the samples at the boundary of the current block and its adjacent blocks. Instead of using the L2 norm (SSD), the cost function can be based on the L1 norm (SAD) as shown below in equation (5).

number

[0095] In the above formula (5), B i,n (where i=-2,-1) represents the samples of the neighboring block above, adjacent to the current block. m,j (where j=-2,-1) represents the samples of the left adjacent block adjacent to the current block. P n,0 and P m,0 Let u denote the corresponding reconstructed 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 of the adjacent block B i,n and C m,j Shows.

[0096] In some implementations, a template-based hypothesis reconstruction method can be applied in a code prediction scheme to avoid the complexity of performing multiple inverse transforms. Each template can be a set of reconstructed samples on the top 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 while all other coefficients are equal to zero. Assuming that 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, and each set is coded with a single CABAC context, e.g., the first set includes predictive codes for transform coefficients in the top-left corner of the transform block, and the second set includes predictive codes for transform coefficients everywhere else in the transform block.

[0098] Like HEVC, scalar quantization is 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 ​​for a transform coefficient depends on the value of the transform coefficient level preceding the current transform coefficient level in the reconstruction order. The main effect of this approach is that allowable reconstructed vectors are packed more tightly in an N-dimensional vector space (N represents the number of transform coefficients in a transform block) compared to the traditional independent scalar quantization used in HEVC. This means that for a given average number of allowable reconstructed vectors per unit volume of N dimensions, the average distortion between an input vector and its nearest reconstructed vector is reduced.

[0099] Dependent scalar quantization can be implemented by (a) defining two scalar quantizers at different reconstruction levels, and (b) defining a process of switching between the two scalar quantizers. FIG. 11 illustrates an example of two scalar quantizers used in dependent scalar quantization of VVC according to some implementations of this disclosure. As illustrated in FIG. 11, two scalar quantizers, denoted as Q0 and Q1, are applied to the quantization design of VVC. The positions of the available reconstruction levels are uniquely specified by the quantization step size Δ. In this implementation, the selection between the two scalar quantizers Q0 and Q1 is not explicitly signaled in 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 coding order by video encoder 20 or in reconstruction order by video decoder 30.

[0100] In some implementations, the switching between the two scalar quantizers is performed using a state machine. For example, Figure 12A is a graphical representation showing state transitions using a state machine with four states 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 coding / reconstruction order.

[0101] In some implementations, at the start of inverse quantization for a transform block, the states are set equal to 0. The transform coefficients are reconstructed in scan order (i.e., the same order in which the transform coefficients are entropy decoded).

[0102] After the current transform coefficient is reconstructed, the state is updated according to the state machine. For example, in FIG. 12A, k indicates 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 quantizer selection examples for the state transitions of FIG. 12A according to some examples. For example, according to FIG. 12A and FIG. 12B, in state 1, the next state is 2 if (k&1)==0, and 0 if (k&1)==1.

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

number

number

[0104] Herein, several deficiencies present in current designs of sign prediction schemes are identified. In a first example, sign prediction in current ECMs is only applicable to predict signs for transform coefficients in transform blocks that are only applied with a primary transform (e.g., DCT and DST transforms). As mentioned above, LFNST can be applied to transform coefficients from a primary transform, resulting in better energy compaction of residual samples of intra-coded blocks. However, sign prediction is bypassed in transform blocks where LFNST is applied in current ECM designs.

[0105] In a second example, a predetermined maximum number of predictive codes ("L max In the current ECM, the video encoder determines the maximum number of bits (e.g., L max = 8) and transmits the value to the video decoder. Also, for each transform block, the video encoder or decoder may scan through the 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. Treating different transform coefficients in a transform block equally in this way may not be optimal in terms of the accuracy of the sign prediction. For example, for transform coefficients with relatively large magnitudes, prediction of their signs may be more likely to achieve accurate prediction. This is because using the wrong sign for those transform coefficients tends to have a larger effect on reconstructed samples on block boundaries than using transform coefficients with relatively small magnitudes.

[0106] In a third example, instead of directly coding explicit code values, a video encoder or decoder can code the accuracy of the predicted code. For example, for a transform coefficient with a positive sign, only bin "0" needs to be indicated in the bitstream from the video encoder to the video decoder if its predicted code is also positive. In this case, the predicted code is the same as the real (or original) code of the transform coefficient, indicating that the code prediction for this transform coefficient is accurate. Otherwise (e.g., the real code is positive while the predicted code is negative), a bin "1" may be included in the bitstream from the video encoder to the video decoder. If the codes are all predicted correctly, the corresponding bins indicated in the bitstream are zero 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. Although arithmetic coding, or even a suitable context model, can be efficient in coding the bins according to their corresponding probabilities, there are still non-negligible bits generated in the bitstream to indicate the code values.

[0107] In the fourth example, in the current design of code prediction in ECM, the spatial discontinuity between samples at the boundary between the current block and its adjacent blocks is used to select the best code prediction combination. The L1 norm of the gradient difference 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 capture the spatial discontinuity accurately.

[0108] Consistent with the present disclosure, video processing methods and systems for sign prediction in block-based video coding are provided herein to address one or more of the above-mentioned deficiencies. The methods and systems disclosed herein can improve the coding efficiency of sign prediction while considering the familiarity of hardware codec implementation. The methods and systems disclosed herein can improve the coding efficiency of transform blocks that apply sign prediction techniques to transform coefficients of the blocks.

[0109] For example, as described above, sign prediction may predict the signs of transform coefficients in a transform block based on the interrelationship between boundary samples (also called border samples) located at or near the boundary between the transform block and its spatially adjacent blocks. Assuming that the existence of the interrelationship does not depend on which particular transform is applied, the two coding tools (i.e., LFNST and sign prediction) do not interfere with each other and can be applied together. Additionally, since LFNST further compresses the energy of the transform coefficients of the linear transform, the sign prediction for the transform coefficients of LFNST may be more accurate than that for the linear transform. This is because an incorrect sign prediction of a transform coefficient from LFNST may cause more discrepancy to the smoothness of the boundary samples. Thus, consistent with the present disclosure, a harmonization scheme is disclosed herein to enable the combination of LFNST and sign prediction and increase the coding efficiency of transform coefficient coding. Additionally, a template-based hypothesis generation scheme is also disclosed herein to reconstruct border samples for different combinations of predicted codes and reduce the number of inverse transforms.

[0110] In another example, as described above, instead of treating different transform coefficients in a transform block equally, for selecting candidate transform coefficients for sign prediction, transform coefficients that may lead to discrepancies between boundary samples of adjacent blocks may be given a higher weight, assuming that the signs of those transform coefficients are more easily predicted. Consistent with the present disclosure, the method and system disclosed herein may 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, and improve the accuracy of sign prediction. For example, transform coefficients that have a greater influence on reconstructed border samples (rather than transform coefficients that have a smaller influence on reconstructed border samples) are selected as candidate transform coefficients for sign prediction, so that the accuracy of sign prediction is improved.

[0111] In yet another example, when the signs of transform coefficients in a transform block are predicted with a high accuracy rate (e.g., the accuracy 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 its adjacent blocks. In this case, it is common that there are consecutive transform coefficients (e.g., especially a few non-zero transform coefficients at the beginning of the transform block) that can be correctly predicted for most scenarios. In such a scenario, a single bin (instead of multiple bins) can be used to indicate whether all the signs of the consecutive transform coefficients are correctly predicted, saving the signaling overhead of the code prediction. Consistent with the present disclosure, a vector-based code prediction scheme is disclosed herein to reduce the signaling overhead of the code prediction. Unlike existing code predictions that predict the sign of each non-zero transform coefficient separately, the disclosed vector-based code prediction scheme groups a series of consecutive non-zero candidate transform coefficients and predicts their corresponding signs together, allowing the average number of bins (or bits) used to indicate the accuracy of the predicted code to be efficiently reduced.

[0112] In yet another example, using only vertical and horizontal directions may not accurately capture the spatial discontinuity between samples at the boundary between a current block and its adjacent blocks. Thus, more directions may be introduced to more accurately capture the spatial discontinuity. Consistent with the present disclosure, an improved cost function is disclosed herein that considers both vertical and horizontal gradients as well as diagonal gradients to more accurately capture the spatial discontinuity.

[0113] 13 is a block diagram illustrating an example sign prediction process 1100 in block-based video coding according to some implementations of this disclosure. In some implementations, sign prediction process 1300 may be performed by transform processing unit 52. In some implementations, 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. Other examples of secondary transforms are contemplated as applicable herein.

[0114] In the existing design of ECM, sign prediction does not work 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 a transform block and its spatially adjacent blocks, and is independent of the specific transform type (e.g., linear transform or secondary transform) or transform core (e.g., DCT or DST) applied to the transform block. Therefore, sign prediction and LFNST can be applied together to further improve the efficiency of transform coding herein. Consistent with 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 linear transform and a secondary transform are applied together.

[0115] A schematic example of the code prediction process 1300 is provided herein. Initially, 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 from 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. Additionally, the code prediction process 1300 may perform a code generation operation 1108 by determining a combination of the selected hypothesis and the associated code candidate as 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 applying a primary transform and a secondary transform together (e.g., forward primary transform 603 and forward LFNST 604 are applied together as shown in FIG. 6 ). 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 as described below, where 1≦L≦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 LL candidate hypotheses are obtained. Each candidate hypothesis may include a reconstructed sample on the top and left boundary of the transform block. A cost function incorporating a compound gradient along the horizontal, vertical, and diagonal directions may then be used to calculate a cost for each candidate hypothesis reconstruction. Among the multiple candidate hypotheses, a candidate hypothesis associated with a minimum cost may be determined as a hypothesis predicting signs of the L candidate transform coefficients. For example, the 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) are 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. Subsequently, an LFNST may be applied to the transform block to generate LFNST transform coefficients based on the primary transform coefficients.

[0118] The sign prediction process 1300 may then perform 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 can be correctly predicted, improving the accuracy of the sign prediction.

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

[0120] Generally, for transform coefficients with larger magnitudes, the predicted codes of these transform coefficients are more likely to be accurate. This is because these transform coefficients with larger magnitudes tend to have a greater impact on the quality of reconstructed samples, and using the wrong codes for these transform coefficients is more likely to generate discontinuities between boundary samples of the transform block and its spatially adjacent blocks. Based on this reasoning, a set of candidate transform coefficients for code prediction can be selected from the transform coefficients of a transform block based on the magnitudes of the non-zero transform coefficients in the transform block.

[0121] There are several possible ways to implement the sorting scheme based on the magnitude of transform coefficients for sign prediction. In a first implementation, the scheme can directly use the transform coefficients reconstructed after inverse quantization (i.e., the inverse quantized transform coefficients) for sorting such that the inverse quantized transform coefficients with larger magnitudes are placed before the inverse quantized transform coefficients with smaller magnitudes for sign prediction. For example, all the non-zero transform coefficients in a transform block can be scanned and sorted to form a coefficient list in the order of their magnitudes. The transform coefficient with the largest magnitude 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 magnitude 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 inverse quantized transform coefficients, the quantization index (e.g., quantIdx as obtained according to equation (6)) of each transform coefficient can be used to represent the magnitude of the transform coefficient and can be used for such sorting. As shown in equation (7), the value of one inverse quantized transform coefficient is equal to the product of its quantization index quantIdx and the corresponding step size Δ, and the step size is common to the inverse quantization of all transform coefficients in one transform block, so the two implementations are actually mathematically identical. However, assuming that the quantization index quantIdx can be obtained in the parsing stage (earlier than obtaining the inverse quantized transform coefficients), the second implementation can bring certain benefits when implemented by some specific hardware.

[0123] In some implementations, a set of candidate transform coefficients can be selected from the transform coefficients of a transform block based on a coefficient scan order for entropy coding applied to video coding. Because raw video content is rich in low-frequency information, the magnitudes of non-zero transform coefficients obtained from processing the video content tend to be larger at low-frequency positions and smaller toward high-frequency positions. Thus, 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 the transform coefficients in the transform block for entropy coding. By using this coefficient scan order, transform coefficients with larger magnitudes (usually corresponding to low frequencies) are scanned before transform coefficients with smaller magnitudes (usually corresponding to high frequencies). Based on this reasoning, a set of candidate transform coefficients for code prediction disclosed herein can be selected from the 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 the transform coefficients in the 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 may be selected from the transform coefficients of the block based on the intra-prediction direction of the block. For example, multiple scan orders consistent with the intra-prediction direction (e.g., 67 intra-prediction directions in VVC and ECM) may be determined and stored as look-up tables in both video encoder 20 and video decoder 30. When coding the transform coefficients of the intra block, video encoder 20 or video decoder 30 may identify a scan order among the scan orders that is closest to the intra-prediction of the intra block. Video encoder 20 or video decoder 30 may use the identified scan order to scan all non-zero transform coefficients of the intra block to obtain a coefficient list, and select the first L non-zero transform coefficients from the coefficient list as a set of candidate transform coefficients.

[0125] In some implementations, video encoder 20 may determine a scan order for 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 by the 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 to video decoder 30 a single index indicating the selected scan order. In another example, one or more new syntax elements may be used to enable signaling of any selected scan order of 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 may be selected from the transform coefficients of a transform block based on the influence scores of the transform coefficients on the reconstructed border samples of the transform block. Specifically, as shown in the above equation (5), the selection of the combination of codes (i.e., predicted codes, or code predictors) is based on a cost function that minimizes the discontinuity of the gradient of samples between the current transform block and its spatially adjacent blocks. Therefore, the signs of transform coefficients that have a relatively large influence on the reconstructed samples on the top and left borders of the current transform block are more likely to be predicted accurately because the flipping of these codes increases the smoothness of the transition between the boundary samples as calculated in (5). To maximize the proportion of accurate code predictions, the signs of these transform coefficients (i.e., transform coefficients that have a greater influence on the reconstructed border samples) may be predicted before other transform coefficients (i.e., transform coefficients that have a lesser influence on the reconstructed border samples). Based on this reasoning, a set of candidate transform coefficients for code prediction disclosed herein may be selected based on their influence scores on the reconstructed samples on the top and left borders of the current transform block.

[0127] For example, video encoder 20 or decoder 30 may sort all of the transform coefficients based on a measure of their corresponding influence scores on the reconstructed border samples of the transform block. If a transform coefficient has a large influence score on the reconstructed border samples, it may be assigned with a smaller index in the code prediction candidate list because it is more likely to be correctly predicted. The set of candidate transform coefficients disclosed herein may be the L transform coefficients with the L smallest 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 in the reconstructed border sample caused by 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) of the transform block. 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 denotes the influence score of the transform coefficient at position (i,j).

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

number

[0131] Consistent with this disclosure, the calculations in equations (8) and (9) above may include, for example, i,j (0,n) and T i,j Although we have used only the top and left boundary samples (as denoted by (m,0)), the transform coefficient selection scheme disclosed in this specification can be applied to any code prediction scheme by changing the reconstructed samples of the current transform block used in the corresponding cost function.

[0132] Similar to the scheme based on the magnitude of the transform coefficients, different ways of implementing the scheme based on the influence scores are also possible. In a first implementation, the scheme is to calculate the inverse quantization of the transform coefficients C i,j The magnitude of C i,j can be used directly. In a second implementation, the quantization index value quantIdx can be applied instead to replace the inverse quantized transform coefficients C i,j and calculate the corresponding cost measure. Specifically, when the quantization index value quantIdx is applied, equations (8) and (9) become the following equations (10) and (11):

number

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

[0134] The code prediction process 1300 may then perform a hypothesis generation operation 1106, which may apply a template-based hypothesis generation scheme 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 for the set of candidate transform coefficients based on the 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. L Each code candidate can be either a negative sign (-) or a positive sign (+). Each combination of code candidates may include a total of L negative or positive signs. For example, when L=2, the multiple combinations of code candidates may include 2 combinations of code candidates, which 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. 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 reconstructed border samples of the transform block. Two example approaches for implementing the template-based hypothesis generation scheme are disclosed herein. Other example approaches for implementing the template-based hypothesis generation scheme are believed to be possible and are not limited herein.

[0136] In a first example approach, a corresponding candidate hypothesis can be generated for each combination of code candidates based on a linear combination of templates, and multiple candidate hypotheses can be generated for multiple combinations of code candidates, respectively. 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 top 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 zero except for the candidate transform coefficient corresponding to the template, which is set to one (e.g., the candidate transform coefficient corresponding to the template is set to one, while each of the remaining candidate transform coefficients is set to zero).

[0137] For example, the candidate hypotheses corresponding to each combination of code candidates can be set to be linear combinations of templates. For the templates corresponding to each candidate transform coefficient, each weight for the template can be set to be the magnitude of the inverse quantized transform coefficient corresponding to each candidate transform coefficient. An example of hypothesis generation based on linear combinations of templates is shown in FIG. 14 and described in more detail below.

[0138] To predict the sign of a candidate transform coefficient, video encoder 20 or decoder 30 may consider all 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 example approach described above, each candidate hypothesis may be generated based on a combination of multiple templates, which may be relatively complex considering the sample-by-sample computations (e.g., additions, multiplications, and shifts) involved in such combinations. To reduce the computational complexity associated with identifying a hypothesis that minimizes a cost value calculated from a cost function, a second example approach is introduced herein.

[0139] In a second example approach, multiple combinations of multiple candidate hypotheses and associated code candidates can be treated as multiple hypothesis indexes for the multiple candidate hypotheses, respectively. For example, the numbers 0 and 1 can be configured to represent a positive sign (+) and a negative sign (-), respectively. The combination of code candidates corresponding to the candidate hypotheses can be used as a unique representation (i.e., hypothesis index) for the candidate hypotheses. For example, assume that there are three codes (e.g., L=3) to be predicted. 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 are generated based on the Gray code order of the multiple hypothesis indexes, and a reconstructed sample of the previous candidate hypothesis having a previous hypothesis index can be used to generate a current candidate hypothesis having a current hypothesis index. The current hypothesis index of the current candidate hypothesis can be immediately after the previous hypothesis index of the previous candidate hypothesis in the Gray code order of the multiple hypothesis indexes. The current hypothesis index can be generated by changing the sign candidate associated with the previous 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 previous hypothesis index to "1" (or "0").

[0141] For example, the multiple hypothesis indexes may be sorted based on a Gray code order of the multiple hypothesis indexes to generate a sorted set of hypothesis indexes. For a first hypothesis index in the sorted set of 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 in which each of the set of candidate transform coefficients is set to 1. For a second hypothesis index in the sorted set of 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 to the second candidate hypothesis. Table 3 below illustrates an example process for generating all candidate hypotheses for an LFNST when the number of candidate transform coefficients is three (e.g., L=3). [Table 3]

[0142] In Table 3 above, the first column represents two of the code candidates, 3=8 combinations. The second column indicates hypothesis indices, respectively, corresponding to the candidate code combinations, by using the numbers 0 and 1 to represent positive (+) and negative (-) signs, respectively. The hypothesis indices in the second column are ordered according to Gray code order (e.g., in the order 000, 001, 011, 010, 110, 111, 101, 100). The third column indicates candidate hypotheses, respectively, corresponding to the candidate code combinations and hypothesis indices. The fourth column indicates the computation of the candidate hypotheses, respectively.

[0143] In Table 3, TXYZ in the fourth column represent corresponding templates (i.e., reconstructed samples on the top and left boundaries of a transform block) that can be generated by applying an inverse transform to a coefficient matrix of a transform block in which certain transform coefficients are set to 1 while all other transform coefficients are equal to zero. For example, T100 represents a corresponding template 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 while all transform coefficients in the coefficient matrix are set to zero. C0, C1, and C2 represent absolute values ​​of the inverse quantized transform coefficients associated with the first, second, and third code candidates, 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 in which each of the candidate transform coefficients is set to 1. For a second hypothesis index 001 immediately following the first hypothesis index 000, a second candidate hypothesis H001 may be generated based on (a) the first candidate hypothesis H000, and (b) an adjustment term to the second candidate hypothesis (e.g., -C2*T001). Similarly, for a third hypothesis index 011 immediately following the 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 to the third candidate hypothesis (e.g., -C1*T010). For a fourth hypothesis index 010 immediately following the 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 (e.g., C2*T001) for the fourth candidate hypothesis.

[0145] A hypothesis associated with a minimum cost can then be determined from multiple candidate hypotheses based on a cost function incorporating composite gradients along horizontal, vertical, and diagonal directions. As mentioned above, if the cost function utilizes only horizontal and vertical gradients (e.g., as shown above in equation (5)), it may not work well for highly non-uniform image signals. Consistent with 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, can also be incorporated into the cost function. For example, the cost functions for the two diagonal directions can be described according to the following equations (12) and (13).

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 C represents the samples of the upper adjacent block adjacent to the transformed block. m-1,-1 , C m-2,-2 , C m+1,-1 and C m+2,-2 P represents the samples of the left neighboring block adjacent to the transformed block. 0,n and P m,0 denote the reconstructed samples on the top and left boundaries of the transform block, respectively. N and M denote the width and height of the transform block, respectively. costD1 and costD1 denote the left-diagonal cost function and the right-diagonal cost function for the left-diagonal and right-diagonal directions, respectively.

[0147] The two cost functions in the diagonal direction (e.g., costD1 and costD2) can be used together with the horizontal and vertical cost function (e.g., costHV shown in the above equation (5)). The cost function for the sign prediction can 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 as shown in equation (14).

number

[0148] In the above equation (14), ω denotes 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, as shown in equation (15).

number

[0150] Compared with equation (5) shown above, the cost function of equation (14) or (15) disclosed in this specification may require more neighboring pixels and support cost functions costD1, costD2 along diagonal directions, which will be described in more detail below with reference to Figures 16A-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. The candidate hypothesis associated with the minimum cost may be determined from the plurality of candidate hypotheses and selected to be the hypothesis for the code prediction.

[0152] The code prediction process 1300 may then perform a code generation operation 1108 that determines a combination of the code candidates associated with the selected hypothesis as a set of predicted 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 also include applying a vector-based code prediction scheme to the set of predicted codes to generate a set of code signaling bits for the set of candidate transform coefficients. A bitstream including the set of code signaling bits may be generated by the video encoder 20 and stored in storage device 32 of Figure 1. Alternatively or additionally, the bitstream may be transmitted to video decoder 30 over link 16 of Figure 1.

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

[0155] Consistent with the present disclosure, the efficiency of code signaling can be improved by applying the vector-based code prediction scheme disclosed herein. Specifically, the candidate transform coefficients for a transform block can be partitioned into multiple groups, and the codes of the candidate transform coefficients in each group can be jointly predicted. In this case, when the original codes (or true codes) of the candidate transform coefficients in a group are the same as their respective predicted codes, only a bin with a value of "0" needs to be transmitted in the bitstream to indicate that the codes in the group are all correctly predicted. Otherwise (i.e., when the group has at least one candidate transform coefficient whose original code is different from the predicted code), a bin with a value of "1" can be signaled in the bitstream first to indicate that not all the codes for the candidate transform coefficients in the group are correctly predicted. Subsequently, additional bins can be signaled in the bitstream from video encoder 20 to video decoder 30 to separately inform the corresponding accuracy of each predicted code in the group. An example 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 may be partitioned into a number of groups of candidate transform coefficients, and for each group of candidate transform coefficients, one or more code signaling bits may be generated for the group of candidate transform coefficients to indicate the accuracy of the predictive 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 zero ("0") value bin 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 is correctly predicted.

[0158] On the other hand, a bin with 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 series of additional bins signaling a corresponding correctness of the predicted code of the group of candidate transform coefficients may also be generated. The bin with a value of one and the series of additional bins may then be added to the bitstream as code signaling bits. For example, the series of additional bins may be an XOR result of the original code and the predicted code of the group of candidate transform coefficients. The additional bin with a value of "0" may indicate that the predicted code of the candidate transform coefficient corresponding to the additional bin is correctly predicted, whereas the additional bin with a value of "1" may indicate that the predicted code of the candidate transform coefficient corresponding to the additional bin is incorrectly predicted. The bitstream may include (a) a "1" indicating that the predicted code of the group of candidate transform coefficients is incorrectly predicted, and (b) a series of additional bins indicating which predicted codes are correctly predicted and which predicted codes are incorrectly predicted.

[0159] The code signaling bits may be generated using other context models as well. For example, the code signaling bits may include bins with values ​​of "0" to indicate that the predicted code of the group of candidate transform coefficients is correctly predicted, and one ("1") to indicate that the predicted code is inaccurate. A series of additional bins may also be generated to signal the corresponding accuracy of the predicted code of the group of candidate transform coefficients whose code prediction is incorrect.

[0160] In some implementations, the size of each group 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- or inter-coding), and the number of non-zero transform coefficients in the transform block, etc. In some implementations, the size of each group of candidate transform coefficients may be signaled in the bitstream at various coding levels, such as the SPS, PPS, slice or picture level, the CTU or CU level, or the transform block level.

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

[0162] Consistent with the present disclosure, the symbol prediction process 1100 disclosed herein may not work under 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. Assuming that the LFNST core transform in ECM is primarily trained when the primary transform is DCT-II, the corresponding LFNST transform coefficients of an intra template matching block may exhibit different characteristics compared to the corresponding LFNST transform coefficients of other LFNST blocks. Based on this reasoning, the symbol prediction process 1300 may not work when the current coding block is an intra template matching block and coded using LFNST.

[0163] Consistent with this disclosure, the maximum number of predictive codes for LFNST blocks and the maximum number of predictive codes for non-LFNST blocks may be different 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 be a value different from 6 (or 4). Additionally, 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 the maximum number of predictive codes for LFNST blocks based on the encoder's corresponding complexity or performance preferences and may signal the maximum number to video decoder 30. When the maximum number of predictive codes for LFNST blocks is signaled to video decoder 30, the maximum number may be signaled at various coding levels, e.g., 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 the maximum number of different values ​​of prediction codes for video blocks that apply LFNST and for video blocks that do not apply LFNST, and signal those maximum number values ​​from video encoder 20 to video decoder 30.

[0164] Consistent with this disclosure, assuming that the transform coefficients of both the primary and secondary transforms are fixed, the video encoder 20 or video decoder 30 may pre-compute templates (e.g., template samples) for different transform block sizes and different combinations of primary and secondary transform combinations. The video encoder 20 or video decoder 30 may store the templates (e.g., template samples) in an internal or external memory to avoid the complexity of creating template samples on-the-fly for optimized implementations. The template samples may be stored with different decimal precisions to achieve different trade-offs between storage size and sample precision. For example, the video encoder 20 or video decoder 30 may scale the floating samples of the template by a fixed factor (e.g., 64, 128, or 256) and round the scaled samples to their nearest integer. The rounded samples may be stored in memory. Subsequently, when using the template to reconstruct a candidate hypothesis, the corresponding samples may first be descaled to the original precision to ensure that the samples generated in the candidate hypothesis are within the correct dynamic range.

[0165] FIG. 14 is a graphical representation illustrating an example of 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 predicted. Coefficients C0, C1, C2, and C3 represent corresponding values ​​of inverse quantized 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 zero. Similarly, templates 1-3 may be generated, respectively. The candidate hypotheses may be generated by adding templates 0-1 and weights C0-C3, respectively.

[0166] 15A is a graphical representation illustrating an example implementation of an existing code prediction scheme, according to some examples. FIG. 15B is a graphical representation illustrating an example implementation of a vector-based code prediction scheme, according to some implementations of the present disclosure. A comparative example between the existing code prediction scheme and the vector-based code prediction scheme disclosed herein is described herein with reference to FIG. 15A-FIG. 15B.

[0167] In FIG. 15A-FIG. 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 FIG. 15A-FIG. 155B. For example, the original and predicted codes of the first candidate transform coefficient with a value of "-2" are both "-" (represented as "1" in FIG. 15A-FIG. 155B). The original and predicted codes of the second candidate transform coefficient with a value of "3" are both "+" (represented as "0" in FIG. 13A-FIG. 13B). The original and predicted codes of the third candidate transform coefficient with a value of "1" are "+" and "-", respectively (represented as "0" and "1" in FIG. 13A-FIG. 13B). The original code of the third candidate transform coefficient is predicted incorrectly. As shown in FIGS. 15A-15B, except for the third transform coefficient, the original codes of all the other candidate transform coefficients are the same as their corresponding predicted codes (ie, correctly predicted).

[0168] Referring to FIG. 15A, a total of six bins (i.e., 0, 0, 1, 0, 0, and 0) are generated, with each bin corresponding to a candidate transform coefficient. The six bins can be generated by performing an XOR operation between the original codes and the predictive codes of the six candidate transform coefficients. The six bins can be used to indicate the corresponding accuracy of the six predictive codes. For example, the first bin and the second bin have a value of "0" indicating that the predictive codes for the first and second candidate transform coefficients are accurate, respectively. The third bin has a value of "1" indicating that the predictive code for the third transform coefficient is not accurate. The six bins can 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 of which includes two consecutive candidate transform coefficients. Since the signs of the candidate transform coefficients in groups #0 and #2 are correctly predicted, only two bins each having a value of “0” are generated for the two groups. Since group #1 includes a third candidate transform coefficient whose sign is not 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 includes at least one candidate transform coefficient whose original code is different from its predicted code. Then, two additional bins with values ​​of “1” and “0” are generated for the third and fourth coefficients of group #1 to indicate whether their signs are correctly predicted. Thus, when the vector-based code prediction scheme disclosed herein is applied, a total of five bins are generated for CABAC, which is less bits than the bins generated by the existing code prediction scheme shown in FIG. 15A. Thus, by applying the vector-based symbol prediction scheme disclosed herein, the signaling overhead can be reduced and the coding efficiency of transform blocks is improved.

[0170] In accordance with the present disclosure, as shown in FIG. 15B, a raster scan order is used to obtain candidate transform coefficients from the coefficient matrix of the transform block, but any other scan order can be used to select candidate transform coefficients for sign prediction. For example, the candidate transform coefficients can be selected based on one or more selection criteria described above. In this specification, the same description is not repeated.

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

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

number

[0173] In a second example method, some of the unavailable locations can be filled with the available pixels closest to them. For example, B -1,-2 If is not available, C 0,-2 It is filled with B -2,-1 If is not available, B -2,0 However, B -2,-2 and B. -1,-1 If are not available, they can be filled with the average value of their two nearest neighboring pixels,,computed according to equations (16) and (17) above.

[0174] In the third example method, only available neighboring reconstructed samples are used to calculate the cost function. If the cost calculation of one boundary sample along the top / left boundary of the current block involves unavailable reconstructed samples, they are not used in calculating the cost in the corresponding direction. For example, in FIG. 16B, to calculate the value of the cost function in the top-right direction, the boundary sample P 0,0 , P 0,1 , and P 1,0 While only P is used 0,2 , P 0,3 , P 2,0 , and P 3,0 will not be used assuming that their cost calculations refer to at least one unavailable reference sample.

[0175] Consistent with the present disclosure, left and right diagonal directions (i.e., 135° and 45° as shown in FIGS. 16A-16B ) are used to illustrate the computation of the cost function shown in equations (14) or (15) above, although it is contemplated that any other measurement component (e.g., continuous measurements along one or more arbitrary directions) may be incorporated into the computation of the cost function for code prediction.

[0176] In a fourth implementation, 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 upper adjacent sample and horizontal extrapolation for the horizontal adjacent sample), texture analysis of the reconstructed samples adjacent to the top and left of the current block can be performed in both the encoder and the decoder, and the most dominant direction of the gradient of the adjacent samples can be selected to extrapolate the boundary samples along the top and left boundaries of the current block.

[0177] For example, Figure 17 is a flowchart of a method 1700 for capturing dominant gradient directions in neighboring reconstructed samples of a current block according to some implementations of the present disclosure. Method 1700 may be performed by a video processor associated with video encoder 20 or video decoder 30 and may include steps 1702-1712 as described below. Some of the steps may be optional for implementing the disclosure provided herein. Additionally, 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 graphical representation illustrating an example of a template sample and a gradient filter window in gradient-based selection of sample extrapolation direction for a cost function according to some implementations of the present disclosure. As shown in FIG. 18A, a template of adjacent reconstructed samples of N rows and N columns above and to the left of the current block is used as a reference sample 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 a number of entries, where each entry of the histogram of gradients corresponds to the accumulated magnitude of gradients in a predefined angular direction. Each entry may be initialized as zero. For example, FIG. 18B is a graphical representation illustrating an example of a histogram of gradients (HoG) in gradient-based selection of sample extrapolation directions for a cost function according to some implementations of the present disclosure. In practice, various predefined directions may be used in the disclosed gradient analysis scheme. In one implementation, the same directions as those defined for 65 angular directions of normal intra prediction in VVC / ECM are used.

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

[0181] The angle (Angle) and magnitude (Amp) of the gradient of each reference sample are calculated in step 1708. For example, the gradient of a sample may be calculated according to equations (20) and (21).

number

[0182] In step 1710, the gradient angle can be converted to one of the predefined directions and the corresponding entry 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 for that Angle. As a result, Amplitude is the accumulated magnitude.

[0183] In step 1712, the entry of the HoG with the largest accumulated magnitude will be 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 largest entry is circled.

[0184] In the above method, the direction with the largest magnitude is selected as the direction for sample extrapolation. Such a method may not always be reliable when there is some noise (e.g., quantization error and / or coding noise caused by other coding modules). To eliminate such problems, certain conditions may 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 available for sample extrapolation in the cost function calculation only when there are enough template samples belonging to the selected gradient direction (e.g., the percentage of samples belonging to the selected direction is sufficiently large, such as exceeding a predefined threshold), otherwise (e.g., when the number of template samples belonging to the selected direction is not large enough), the default extrapolation (e.g., vertical extrapolation for the top neighboring samples and horizontal extrapolation for the left neighboring samples) is still applied.

[0186] In another implementation, a selected dominant gradient direction may be used for sample extrapolation of the cost function calculation only if the gradient magnitude associated with the dominant gradient direction is sufficiently large (e.g., 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., when the gradient magnitude of the selected direction is not large), the default extrapolation is still applied.

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

[0188] In yet another implementation, when the selected dominant gradient direction is available, a direction orthogonal to the selected direction is used for sample extrapolation in the calculation of the cost function when predicting a code within a block. For example, when the selected direction is 45 degrees, 135 degrees will be 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 will be used as the direction for extrapolating samples along the top and left boundaries of the current block.

[0189] In the implementation disclosed above, 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). Generally, such a method is reasonable because most of the energy of a common transform block is usually concentrated among a few transform coefficients in low frequency. Therefore, the sign of transform coefficients in the top-left corner is statistically easier than that in other places. However, this assumption is not necessarily 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 can have its own MV), many edges may be generated along the boundaries between different motions in their predicted signals. In such a case, after applying DCT / DST transform, non-negligible high-frequency transform coefficients are generated, and those coefficients may protrude from the top-left 4×4 corner. The signs of those high-frequency coefficients cannot be predicted according to the sign prediction design disclosed above.

[0190] In some alternative implementations, the area of ​​transform coefficients input to the forward LFNST, and thus later used for sign prediction, may be expanded from the top-left 4×4 sub-block (e.g., as shown in FIG. 7) to further improve coding performance. For example, FIG. 19 is a graphical representation 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 A and B are calculated according to equation (22).

number

[0192] In some implementations, various methods can be used to determine the value of TH. In one implementation, a fixed value for TH (e.g., 8, 16, 32, etc.) may be used in all sequences and coding scenarios. Assuming that the area size threshold TH is fixed, the encoder and decoder will use the same value (i.e., not signaled) when positioning transform coefficients for code prediction to determine the corresponding area. In another implementation, the encoder may be given flexibility to determine the optimal area size threshold according to the specific characteristics of the video sequence and its preferred performance / complexity tradeoff, and the corresponding value may be signaled from the encoder to the decoder.

[0193] In one example method, the area size threshold may be selected from a set of constants such that only a constant number of bits need to be signaled in the bitstream to the decoder to indicate which size is selected. For example, assuming there are four allowed area size thresholds {4, 8, 16, 32}, only two bits need to be signaled to indicate the particular value selected from the group. In another example 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, due to its unknown value, a fixed length codeword cannot be used, instead, some variable length codeword (e.g., exponential-Golomb, unary code, etc.) may be applied in the bitstream to indicate the determined area size threshold value.

[0194] Additionally, when the value of TH is transmitted in the bitstream, it can be signaled at various levels, e.g., at the video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), slice header, and coding block level. When signaled at the sequence level (e.g., in the VPS or SPS), the value of TH means that one and the same area size threshold will be shared by all transform blocks in the video sequence. When signaled at the picture / slice level (i.e., in the PPS or slice header), the value of TH can vary the area size threshold from picture to picture or slice to slice, respectively. Similarly, when the value is signaled at the coding block, the value provides the maximum adaptability of the code prediction region, but more coding bits are consumed considering the need to signal the value separately for each individual coding block.

[0195] At the decoder side, the decoder may determine the code prediction area based on the size of the transform block and the area size threshold TH. When TH is a fixed value, TH may be pre-programmed into the decoder instead of being signaled in the bitstream. The decoder may 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 will be signaled to the decoder in the bitstream. 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 various levels, such as the VPS, SPS, PPS, slice header, and coding block levels. Based on the level at which the TH is signaled, the decoder can determine the extent to which the signaled TH should be applied. For example, when the TH is signaled at the VPS or SPS level, the decoder will apply the TH to all transform blocks in the video sequence. When the TH is signaled at the PPS or slice header level, the decoder will apply the TH to all transform blocks in the current picture / slice and read different THs for different pictures / slices. When the TH is signaled at the coding block level, the decoder will apply different THs read from the bitstream to different coding blocks, respectively.

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

[0198] In some implementations, after determining what value of TH applies 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 A of the code prediction area is determined to be less than the width of the transform block and the area size threshold TH, and the height B of the code prediction area is determined to be less than the height of the transform block and the area size threshold TH.

[0199] As mentioned above, to improve the efficiency of the code prediction, the code prediction area where the code prediction of the transform coefficients is applied may be signaled from the encoder to the decoder. To implement this extended code prediction area at the decoder side, the decoder must be able to handle all possible extended region sizes selected by the encoder, which may introduce ambiguity when the decoder parses the codes for blocks of various sizes. To facilitate the implementation of the extended code prediction area, a region-based method may be used to signal the codes of one transform block in a specific order.

[0200] There are N possible area size thresholds, TH0, TH1, . . . , TH, which are signaled from the encoder to the decoder and applied by the decoder to position the transform coefficients for code prediction. N-1 Consistent with the above discussion, these area size thresholds can be predefined values ​​or can be adaptively determined by the encoder. max is the largest area size threshold among these possible thresholds, i.e., TH max =max{TH0, TH1, . . ., TH N-1}TH cur is the value signaled to the decoder as being the selected threshold used to determine the code prediction area, where For simplicity, in the following description, the width and height of the current transformation block are both TH max That is, by applying equation (22), A=B=TH max It is.

[0201] In some implementations, to signal the code of a transform block in a particular order, the transform block is first partitioned into multiple regions, and then the codes of the transform coefficients associated with the multiple regions are signaled from one region to another.

[0202] For example, Figure 20 is a graphical representation illustrating partitioning of a transform block to implement an example order for signaling signs of transform coefficients from an encoder to a decoder, according to some examples. As shown in Figure 20, the entire domain of the transform block may be partitioned into three different regions: (1) The first area (area #1) is a signed code prediction area size TH cur The transform coefficients are included within the upper left region bounded by <TH cur and 0≦y <TH cur is; (2) The second region (region #2) includes transform coefficients that are between the region bounded by the signed symbol prediction region and the maximum symbol prediction region size, i.e., {TH cur ≦x <TH max and 0≦y <TH cur}, {0≦x <TH cur and T.H. cur ≦y <TH max}, {TH cur ≦x <TH max and T.H. cur ≦y <TH max} is; and (3) The third region (region #3) contains all other transform coefficients in the transform block, i.e., x>TH max or y>TH max That is, where x and y are the horizontal and vertical coordinates of the transform coefficient in the transform block.

[0203] Figure 20 shows the regions obtained after the above partitioning / partitioning scheme is applied to one transform block. Region #1 contains transform coefficients whose signs are either predictable or unpredictable, while the signs of transform coefficients in regions #2 and #3 are not purely predictable, i.e., they are directly signaled in the bitstream. In some implementations, under the partitioning structure of Figure 20, the signs of transform coefficients in region #3 are signaled first, followed by the signs of transform coefficients in region #1, and finally the signs of transform coefficients in region #2.

[0204] In some implementations, different scan orders may be applied by an encoder to code the signs of transform coefficients from different regions. For example, Figure 21 is a graphical representation showing various scan orders for scanning the signs of transform coefficients according to some examples. Part (a) of Figure 21 shows a diagonal scan, part (b) shows a horizontal scan, and part (c) shows a vertical scan.

[0205] In some implementations, different scan orders may be applied to partitioned regions of a transform block. For example, FIG. 22 is a graphical representation showing implementations of various scan orders for a transform block partitioned according to FIG. 20, according to some examples. As shown in FIG. 22, the signs of transform coefficients in regions #1 and #2 may be scanned by horizontal scanning, and the signs of transform coefficients in region #3 may be scanned by diagonal scanning.

[0206] As another example, Figure 23 is a graphical representation illustrating a partitioning of a transform block implementing another example order for signaling signs of transform coefficients from an encoder to a decoder, according to some examples. In this example, the transform block is divided into only two regions: (1) The first area (area #1) is a signed code prediction area size TH cur The transform coefficients are included within the upper left region bounded by <THcur and 0≦y <TH cur is; and (2) The second region (region #2) contains all other transform coefficients in the transform block, i.e., x>TH cur or y>TH cur That is, where x and y are the horizontal and vertical coordinates of the transform coefficient in the transform block.

[0207] Figure 22 shows the regions obtained after the above partitioning scheme is applied to one transform block. Region #1 contains transform coefficients whose signs are either predictable or unpredictable, while the signs of the transform coefficients in region #2 are not purely predictable, i.e., they are directly signaled in the bitstream. Under the partitioning structure of Figure 22, in some implementations, the signs of the transform coefficients in region #2 are signaled first, followed by the signs of the transform coefficients in region #1.

[0208] In some embodiments, different scan orders may be applied by the encoder to scan the signs of the transform coefficients belonging to the two regions. For example, FIG. 24 is a graphical representation illustrating implementation of different scan orders for a transform block partitioned according to FIG. 22, according to some examples. In one example, as shown in FIG. 24, the encoder may scan the signs of the transform coefficients in region #1 by horizontal scanning and scan the signs of the transform coefficients in region #2 by diagonal scanning.

[0209] Although in the examples of Figures 22 and 24, only horizontal and diagonal scans are applied to scan the signs of the transform coefficients, those familiar with modern video coding technology will readily accept that other combinations of scan orders are also applicable to the disclosed region-based signaling method for signaling the signs of one transform block.

[0210] At the encoder side, the signal is coded in the bitstream in a region-based order (e.g., region #3, region #1, followed by region #2 in the case of the partition shown in FIG. 20), so at the decoder side, the coded data is parsed according to the same order. The decoder first parses the signaled TH cur (and optionally TH max ) to determine the regions and read the data for each of those regions. Using the partitioning of Figure 20 as an example, the decoder may parse the bitstream and obtain the sign and coded transform coefficients first for region #3, then region #1, then region #2. The decoder may then perform code prediction on the transform coefficients in region #1 (the code prediction area for the transform block).

[0211] The extended code prediction area scheme is not believed to interfere with any of the code prediction techniques disclosed above, and these techniques can be easily adapted and combined with the extended code prediction area to improve coding performance. As one particular example, the extended code prediction area can be combined with code prediction reordering and LFNST code prediction.

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

[0213] In a first example method, the context of the level values ​​(i.e., magnitudes) of the transform coefficients can be used to entropy code the accuracy of the sign prediction, since a larger magnitude tends to have a higher probability of making an accurate prediction. For example, when such a method is applied, the range of possible magnitude values ​​can be partitioned into several segments, and different contexts can be assigned to the sign prediction entropy coding of coefficients in different segments.

[0214] In some implementations, the magnitude range of the transform coefficients may be partitioned into a plurality of magnitude segments, a context may be assigned to each magnitude segment, and code signaling bits for the transform coefficients belonging to that magnitude segment may be entropy coded. Of the plurality of magnitude segments, every two consecutive magnitude segments may be separated by a threshold value to prevent the magnitude segments from overlapping.

[0215] In one particular example, a threshold thres may be used to partition the magnitude range of transform coefficients into two segments, namely (1, thres) and [thres, +∞]. With such partitioning, if a transform coefficient belongs to the first segment, a first context is assigned to code the sign of the transform coefficient. Otherwise, if the transform coefficient falls into the second segment, a second context is assigned to code the sign of the transform coefficient.

[0216] In various implementations, the threshold value (or values ​​of the thresholds) can be determined and specified in different ways. In one example method, the value may be fixed (e.g., 2, 3, ..., etc.) and pre-programmed in both the encoder and the decoder. Thus, a fixed value is used on both the encoder and the decoder side without the need to signal it. In another example method, the encoder may be given the freedom to choose an optimal threshold value and signal a corresponding value to the decoder.

[0217] As mentioned above, the magnitude of each transform coefficient is used to determine the context for coding the sign value of the transform coefficient at the encoder side. Therefore, at the decoder side, the magnitude of each transform coefficient is used to determine the context for decoding the sign value of the transform coefficient accordingly. Assuming that the transform coefficients can be obtained only after inverse quantization at the decoder side, such a scheme may significantly increase the complexity of the parsing bitstream due to the fact that inverse quantization needs to be performed at the parsing stage. To solve this complexity problem, in one implementation, the decoder uses the level of the transform coefficient to determine the context for coding the sign of a transform coefficient. k (i.e., the quantized values ​​of the transform coefficients parsed directly from the bitstream, without inverse quantization being applied) may be used directly.

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

[0219] In various implementations, all of the above magnitude / level-based context modeling methods can be combined with the disclosed transform coefficient selection scheme, as described in connection with FIG. 13. For example, such combination may be implemented in two different ways. In one way, transform coefficients are reordered and the magnitude / level of the reordered transform coefficients (i.e., the magnitude / level after the transform coefficients are reordered) may determine the corresponding context applied to code the signs of the transform coefficients in one transform block. In another way, the transform coefficients are not reordered and the magnitude / level of the transform coefficients are used unreordered (i.e., the magnitude / level before the transform coefficients are reordered) to determine the context applied to code the signs of the transform coefficients in the transform block.

[0220] Figure 25A and Figure 25B respectively show two examples of context modeling for transform coefficient code prediction, which implement the two schemes mentioned above. As shown in Figure 25A, when the first scheme is applied, the transform coefficients are sorted according to their magnitude / level, for example, in the order 6, 3, 2, 2, 1, 1, 1, and 1. The magnitude / level of the sorted transform coefficients is used to select the context of the code signaling bits included in the bitstream. The advantage of this first scheme is that the corresponding magnitude / level used for context modeling matches the transform coefficients for which the code is coded. When this first scheme is applied, the encoder / decoder needs to sort the transform coefficients before the code is coded / decoded, which may increase the complexity of bitstream parsing and thus reduce the parsing throughput. Figure 25B shows the implementation of a second scheme that may avoid this parsing problem. In this second scheme, the magnitude / level of the unsorted transform coefficients is used for context determination for coding the code. Therefore, sorting does not need to be applied in the parsing stage. Therefore, the magnitudes / levels used for context modeling do not have to be aligned with the sign.

[0221] 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, one single context may be applied to coding the transform coefficients located at the first L positions of a transform block, while another context may be applied to coding the signs of the coefficients at other positions. In one particular example, 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., the DC coefficient) of a transform coefficient, and another context is assigned to code the signs of all the other transform coefficients (i.e., the AC coefficients). Alternatively, all the sign prediction positions in a transform block may be classified into different groups according to their respective importance (or likelihood of correct prediction), and different contexts may be assigned to each group separately.

[0222] In a third method, information about coding, such as coding mode context, block size, and component channel information, may be used for code predictive coding. 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.

[0223] In the fourth method, the transform type for determining the transform coefficients may be used as the 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.Assuming that the transform coefficients obtained from different transform cores may exhibit different statistical characteristics, different contexts may be used to entropy code the signs of the transform coefficients of different transforms.

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

[0225] 26 is a flowchart of an example method 2600 for symbol prediction in block-based video coding according to some implementations of the present disclosure. The method 2600 may be performed by a video processor associated with the video encoder 20 or the video decoder 30 and may include steps 2602-2608 as described below. Some of the steps may be optional for implementing the disclosure provided herein. Additionally, some of the steps may be performed simultaneously or in a different order than shown in FIG.

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

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

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

[0229] In step 2608, the video processor may determine that the combination of the selected hypotheses and associated code candidates is a set of predicted codes for the set of candidate transform coefficients.

[0230] Consistent with this disclosure, the method 2600 and FIG. 26 may be performed on a video encoder side or a video decoder side. When the method 2600 is performed on a video encoder side, it may be considered as an encoding method for transform coefficient sign prediction at a video encoder side. Then, a code signaling bit indicating the accuracy of the code prediction is generated and coded to be included in a bitstream transmitted to a decoder. When the method 2600 is performed on a video decoder side, it may be considered as a decoding method for transform coefficient sign prediction at a video decoder side. The code signaling bit is signaled to a decoder in a bitstream that also includes coded data of the quantized levels of the transform coefficients. The decoder may use the code signaling bit to modify its code prediction and estimate the original sign of the received transform coefficient. An example encoding method and an example decoding method for transform coefficient sign prediction at a video decoder side are provided below with reference to FIG. 27 and FIG. 28, respectively.

[0231] 27 is a flowchart of an example video encoding method 2700 for transform coefficient sign prediction performed by a video encoder in accordance with some implementations of the present disclosure. Method 2700 may be performed by a video processor associated with video encoder 20 and may include steps 2702-2716 as described below. Some of the steps may be optional for implementing the disclosure provided herein. Additionally, some of the steps may be performed simultaneously or in a different order than shown in FIG.

[0232] In step 2702, the video processor may apply a primary transform and a secondary transform to a transform block of a video frame from a video to generate transform coefficients for the transform block. In some implementations, the secondary transform may be a forward LFNST.

[0233] In step 2704, the video processor may determine a sign prediction area for performing transform coefficient sign prediction based on the area size threshold. In some implementations, the video processor may select the area size threshold and signal the area size threshold. In some implementations, the video processor may determine the sign prediction area at the upper left corner of the transform block according to equation (22).

[0234] In step 2706, the video processor may partition / split the transform block into a plurality of regions including a code prediction area and at least one other region. In some implementations, the transform block may be partitioned into three regions including a first region of the code prediction area, a second region encompassing a rectangular area having a width and height equal to the maximum area size threshold and outside the code prediction area, and a third region covering the remaining area of ​​the transform block outside the first and second regions. In some implementations, the transform block may be partitioned into two regions including a first region of the code prediction area and a second region covering the remaining area of ​​the transform block outside the first region.

[0235] In step 2708, the video processor may select a set of candidate transform coefficients from the transform coefficients in the symbol prediction area for symbol prediction.

[0236] At step 2710, the video processor may predict codes for the set of candidate transform coefficients. In some implementations, 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. The video processor may then apply a template-based hypothesis generation scheme to generate a plurality of candidate hypotheses for the plurality of combinations of code candidates, respectively. The video processor may select a hypothesis associated with a minimum cost from the plurality of candidate hypotheses based on a cost function. The video processor may determine the combination of code candidates associated with the selected hypothesis to be a set of predicted codes for the set of candidate transform coefficients.

[0237] In step 2712, the video processor may generate a set of code signaling bits for a set of candidate transform coefficients according to one or more contexts. Various context models and combinations thereof may be used to code the accuracy of the predictive code. In some implementations, the set of code signaling bits may be generated by applying a vector-based code prediction scheme.

[0238] In step 2714, the video processor may code the signs of the transform coefficients of the multiple regions using the respective scan orders. In some implementations, different scan orders are applied to the multiple regions. For example, when the transform block is partitioned into three regions in step 2706, the first and second regions may be scanned in a horizontal scan order, and the third region may be scanned in a diagonal scan order. As another example, when the transform block is partitioned into two regions in step 2706, the first region may be scanned in a horizontal scan order, and the second region may be scanned in a diagonal scan order.

[0239] In step 2716, the video processor may generate a bitstream to signal signs of the transform coefficients associated with the multiple regions according to the region-based order and the sequence of sign signaling bits. In some implementations, when the transform block is partitioned into three regions in step 2706, the signs of the transform coefficients of the third region are signaled in the bitstream first, followed by the signs of the transform coefficients of the first region, and finally the signs of the transform coefficients of the second region. In some implementations, when the transform block is partitioned into two regions in step 2706, the signs of the transform coefficients of the second region are signaled in the bitstream first, followed by the signs of the transform coefficients of the first region.

[0240] The bitstream generated in step 2716 may be sent to a decoder to reconstruct the transform blocks of the video frame. If an area size threshold was selected by the encoder (in step 2704), the area size threshold may also be included in the bitstream and signaled to the decoder.

[0241] 28 is a flowchart of an example video decoding method 2800 for transform coefficient sign prediction performed by a video decoder in accordance with some implementations of the present disclosure. Method 2800 may be performed by a video processor associated with video decoder 30 and may include steps 2802-2818, as described below. Some of the steps may be optional for implementing the disclosure provided herein. Additionally, some of the steps may be performed simultaneously or in a different order than shown in FIG.

[0242] At step 2802, a video processor may receive a bitstream including coded data for transform coefficients associated with multiple regions of a transform block and a series of code signaling bits. In some implementations, the bitstream may be generated using a video encoding method such as method 2700 of FIG.

[0243] In step 2804, the video processor may determine a code prediction area for performing transform coefficient code prediction based on an area size threshold. In some implementations, the area size threshold may be selected by an encoder and signaled to a decoder in a bitstream. In some implementations, the video processor may determine the code prediction area at the top left corner of the transform block according to equation (22).

[0244] In step 2806, the video processor may partition / split the transform block into a plurality of regions including a code prediction area and at least one other region. In some implementations, the transform block may be partitioned into three regions including a first region of the code prediction area, a second region encompassing a rectangular area having a width and height equal to the maximum area size threshold and outside the code prediction area, and a third region covering the remaining area of ​​the transform block outside the first and second regions. In some implementations, the transform block may be partitioned into two regions including a first region of the code prediction area and a second region covering the remaining area of ​​the transform block outside the first region.

[0245] In step 2808, the video processor may parse the bitstream to obtain coded data of transform coefficients associated with the multiple regions of the transform block according to the region-based order and the scan order applied to the multiple regions. In some implementations, when the transform block is partitioned into three regions in step 2806, the signs of the transform coefficients of the third region are read from the bitstream first, followed by the signs of the transform coefficients of the first region, and finally the signs of the transform coefficients of the second region are read from the bitstream. In some implementations, when the transform block is partitioned into two regions in step 2806, the signs of the transform coefficients of the second region are read from the bitstream first, followed by the signs of the transform coefficients of the first region.

[0246] Within each region, the data is parsed according to the respective scan order applied by the encoder, and the signs of the transform coefficients are coded. For example, when the transform block is partitioned into three regions in step 2806, the first and second regions may be scanned in a horizontal scan order, and the third region may be scanned in a diagonal scan order. As another example, when the transform block is partitioned into two regions in step 2806, the first region may be scanned in a horizontal scan order, and the second region may be scanned in a diagonal scan order.

[0247] At step 2810, the video processor may inverse quantize the transform coefficients of the transform block. The video processor may generate inverse quantized transform coefficients from the quantized transform coefficients via inverse quantization unit 86 of Figure 3. The inverse quantized transform coefficients of the transform block in video decoder 30 may correspond to the transform coefficients of the transform block in video encoder 20.

[0248] In step 2812, the video processor may select a set of candidate transform coefficients from the inverse quantized transform coefficients associated with the symbol prediction area for symbol prediction.

[0249] In step 2814, the video processor may predict codes for the set of candidate transform coefficients. In some implementations, 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. The video processor may then apply a template-based hypothesis generation scheme to generate a plurality of candidate hypotheses for the plurality of combinations of code candidates, respectively. The video processor may select a hypothesis associated with a minimum cost from the plurality of candidate hypotheses based on a cost function. The video processor may determine the combination of code candidates associated with the selected hypothesis to be a set of predicted codes for the set of candidate transform coefficients.

[0250] At step 2816 , the video processor may estimate original codes for the set of candidate transform coefficients based on the set of predicted codes and the set of decoded code signaling bits in the bitstream received at step 2802 .

[0251] For example, referring to FIG. 15B, the set of predicted codes may include group #0 with values ​​(1,0), group #2 with values ​​(1,0), and group #3 with values ​​(1,0), where 1 indicates a negative sign and 0 indicates a positive sign. The set of code signaling bits may include bit "0" for group #0, bits "1,1,0" for group #2, and bit "0" for group #3. Because the bit for group #0 has a value of "0", indicating that the predicted code for this group having a value of (1,0) is accurate (e.g., the predicted code is the same as the original code), the estimated original code for group #0 is determined to be (1,0). Because the first bit of the bits for group #1 has a value of “1”, it is indicated that the predicted code (1,0) for this group is not correct (e.g., the predicted code is not the same as the original code), and then the estimated original code (1,0) for group #1 is determined to be the XOR result of the predicted code (1,0) for this group and the second and third bits “1,0” for group #1 (e.g., estimated original code=XOR((1,0),(1,0))=(0,0)). Because the bits for group #2 have a value of “0”, it is indicated 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), and the estimated original code for group #2 is determined to be (1,0). Then, the estimated original code for the set of candidate transform coefficients is formed by concatenating the estimated original codes of groups #0, #1, and #2, each of which comprises (1,0,0,0,1,0). As mentioned above, a video encoder may use different context models to code the accuracy of the prediction codes, and modifications of the prediction codes are adapted according to those context models.

[0252] In step 2818, the video processor may update the inverse quantized transform coefficients based on the estimated original signs for the set of candidate transform coefficients. For example, the video processor may use the estimated original signs as true signs for the inverse quantized transform coefficients in the transform block that correspond to the set of candidate transform coefficients.

[0253] In some implementations, after the inverse quantized transform coefficients are updated, the video processor may further apply an inverse primary transform and an inverse secondary transform to the inverse quantized 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 an identity transform.

[0254] In some implementations, the set of code signaling bits for the set of candidate transform coefficients is generated by the video encoder by applying 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 to generate a bitstream including the set of code signaling bits, 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.

[0255] In some implementations, applying the vector-based code prediction scheme to the other series of predictive codes for the other series of candidate transform coefficients further includes partitioning the other series of candidate transform coefficients into a plurality of groups of candidate transform coefficients, and, for each group 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.

[0256] In some implementations, generating one or more code signaling bits for the group of candidate transform coefficients includes generating a zero-valued bin in response to an original code of the group of candidate transform coefficients being identical to a predicted code of the group of candidate transform coefficients, and adding the bin to the bitstream as a code signaling bit. In some implementations, generating one or more code signaling bits for the group of candidate transform coefficients includes generating a one-valued bin in response to an original code of the group of candidate transform coefficients not being identical to a predicted code of the group of candidate transform coefficients, generating a series of additional bins to signal a corresponding accuracy of the predicted code of the group of candidate transform coefficients, and adding the bin and the series of additional bins to the bitstream as code signaling bits.

[0257] 29 illustrates a computing environment 2910 coupled to a user interface 2950 according to some implementations of the disclosure. The computing environment 2910 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 2910. The computing environment 2910 includes a processor 2920, a memory 2930, and an input / output (I / O) interface 2940.

[0258] The processor 2920 typically controls the overall operation of the computing environment 2910, such as display, data acquisition, data communication, and image processing related operations. The processor 2920 may comprise one or more processors to execute instructions and perform all or some of the steps in the methods described above. The processor 2920 may also comprise one or more modules that facilitate interaction between the processor 2920 and other components. The processor 2920 may be a Central Processing Unit (CPU), a microprocessor, a single chip machine, a Graphical Processing Unit (GPU), etc.

[0259] The memory 2930 is configured to store various types of data to support the operation of the computing environment 2910. The memory 2930 may include predefined software 2932. Examples of such data include video data sets, image data, and instructions for any application or method operated in the computing environment 2910. The memory 2930 may be implemented using any type of volatile or non-volatile memory device, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic memory, flash memory, magnetic or optical disks, or a combination thereof.

[0260] The I / O interface 2940 provides an interface between the processor 2920 and a peripheral interface module such as a keyboard, a click wheel, buttons, etc. The buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. The I / O interface 2940 can connect to an encoder and a decoder.

[0261] In some implementations, a non-transitory computer-readable storage medium is also provided, for example in memory 2930, that includes a plurality of programs executable by processor 2920 in computing environment 2910 for performing the above-described methods. In one example, the plurality of programs may be executed by processor 2920 in computing environment 2910 to receive (e.g., from video encoder 20 in FIG. 2 ) a bitstream or datastream that includes encoded video information (e.g., video blocks representing encoded video frames and / or one or more associated syntax elements, etc.), and the plurality of programs may be executed by processor 2920 in computing environment 2910 to perform the above-described decoding methods in accordance with the received bitstream or datastream. In another example, a number of programs may be executed by the processor 2920 in the computing environment 2910 to perform the encoding method described above and encode the video information (e.g., video blocks representing encoded video frames and / or one or more associated syntax elements, etc.) into a bitstream or data stream, and a number of programs may be executed by the processor 2920 in the computing environment 2910 to transmit the bitstream or data stream (e.g., to the video decoder 30 in FIG. 3). Alternatively, a non-transitory computer-readable storage medium may have stored therein a bitstream or datastream including encoded video information (e.g., video blocks representing encoded video frames and / or one or more associated syntax elements, etc.) generated by an encoder (e.g., the video encoder 20 in FIG. 2) using, for example, the encoding method described above, for use by a decoder (e.g., the video decoder 30 in 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, an optical data storage device, etc.

[0262] In some implementations, a computing device is also provided that includes one or more processors (e.g., processor 2920) and a non-transitory computer-readable storage medium or memory 2930 having stored therein a number of programs executable by the one or more processors, the one or more processors being configured, when executing the number of programs, to perform the methods described above.

[0263] In some implementations, a computer program product is also provided that includes, for example, in memory 2930, a number of programs executable by processor 2920 in computing environment 2910 for performing the methods described above. For example, the computer program product may include a non-transitory computer-readable storage medium.

[0264] In some implementations, the computing environment 2910 may be implemented with one or more ASIs, 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.

[0265] The description of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or to be limiting of the present disclosure. Many modifications, variations, and alternative implementations will be apparent to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings.

[0266] Unless otherwise specified, the order of steps of the method according to the present disclosure is only intended to be illustrative, and the steps of the method according to the present disclosure are not limited to the order specifically described above, and may be changed according to actual conditions. In addition, at least one of the steps of the method according to the present disclosure may be adjusted, combined, or deleted according to actual requirements.

[0267] The examples have been chosen and described to explain the principles of the disclosure and to enable other parties to understand the disclosure of the various implementations and to best utilize the underlying principles and various implementations with various modifications as may be suitable for particular applications contemplated. Therefore, it should be understood that the scope of the disclosure is not limited to the particular examples of implementations disclosed, and modifications and other implementations are intended to be included within the scope of the disclosure.

Claims

1. 1. A video decoding method for sign prediction of transform coefficients, comprising: receiving a bitstream including encoded data of transform coefficients of transform blocks of a video frame from a video; determining, by a decoder, a plurality of regions in the transform block, the plurality of regions including a symbol prediction area for performing the symbol prediction and at least one other region; parsing, by the decoder, the bitstream to obtain signs of transform coefficients associated with the plurality of regions of the transform block according to a region-based order used to signal the signs of the transform coefficients; estimating, by the decoder, original signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block; updating the transform coefficients associated with the symbol prediction area based on the estimated original symbol; The method includes:

2. The video decoding method of claim 1 , wherein the regions in the transform block are determined based on an area size threshold.

3. 3. The video decoding method of claim 2, wherein the code prediction area is determined to be a first region in an upper left corner of the transform block having a width and height equal to the area size threshold.

4. 4. The method of claim 3, wherein the at least one other region includes a second region encompassing a remaining area of ​​the transform block outside the first region.

5. 5. The method of claim 4, wherein the signs of the transform coefficients in the first region are coded according to a first scanning order and the signs of the transform coefficients in the second region are coded according to a second scanning order that is different from the first scanning order.

6. 6. The method of claim 5, wherein the first scanning order is a horizontal scanning order and the second scanning order is a diagonal scanning order.

7. Parsing the bitstream to obtain signs of transform coefficients associated with the plurality of regions of the transform block according to a region-based order used to signal the signs of the transform coefficients, comprising: reading the signs of the transform coefficients from the bitstream according to the region-based order of the second region followed by the first region. The video decoding method of claim 4 , further comprising:

8. 4. The video decoding method of claim 3, wherein the at least one other region includes a second region that encompasses an area at the upper left corner of the transform block having a width and height equal to a maximum area size threshold and is outside the first region, and the at least one other region further includes a third region that surrounds a remaining area of ​​the transform block outside the first and second regions.

9. 9. The method of claim 8, wherein the signs of the transform coefficients in the first region, the second region, and the third region are coded according to at least two different scan orders.

10. 10. The method of claim 9, wherein the signs of the transform coefficients in the first region and the second region are coded according to a horizontal scan order and the transform coefficients in the third region are coded according to a diagonal scan order.

11. Parsing the bitstream to obtain signs of transform coefficients associated with the plurality of regions of the transform block according to a region-based order used to signal the signs of the transform coefficients, comprising: reading the signs of the transform coefficients from the bitstream according to the region-based order of the third region, followed by the first region, and then the second region; The video decoding method of claim 5 , further comprising:

12. The method of claim 2 , wherein the area size threshold is a fixed value for all transform blocks of the video, and the area size threshold is not signaled in the bitstream.

13. The method of claim 2 , wherein the area size threshold is adaptively determined for the transform block, and the area size threshold is signaled in the bitstream.

14. 14. The video decoding method of claim 13, wherein the area size threshold is signaled in a video parameter set, a sequence parameter set, a picture parameter set, or at a slice header and coding block level.

15. The bitstream further comprises a set of code signaling bits, and estimating the original code for the set of candidate transform coefficients associated with the code prediction area of ​​the transform block comprises: predicting signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block; estimating original codes for the set of candidate transform coefficients based on the set of predicted codes and the set of code signaling bits; The video decoding method of claim 1 , further comprising:

16. Predicting signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block includes: determining 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; applying a template-based hypothesis generation scheme to generate a plurality of candidate hypotheses for a plurality of combinations of said code candidates, respectively; selecting a hypothesis from the plurality of candidate hypotheses as a set of predictive codes for the set of candidate transform coefficients; The video decoding method of claim 15, further comprising:

17. applying an inverse linear transform and an inverse low-frequency non-separable transform (LFNST) to the transform coefficients of the transform block to generate residual samples in a residual block corresponding to the transform block; The video decoding method of claim 1 , further comprising:

18. a memory configured to store the bitstream; a processor, connected to said memory and configured to implement a video decoding method for sign prediction of transform coefficients according to any one of claims 1 to 17; A video decoding device comprising:

19. A non-transitory computer readable storage medium having stored therein instructions which, when executed by a processor, cause the processor to perform a video decoding method for sign prediction of transform coefficients according to any of claims 1 to 17, The bitstream is stored on the computer readable storage medium.

20. 18. A non-transitory computer readable storage medium having stored therein a bitstream comprising coded data of transform coefficients of a transform block, the bitstream being decodable by a video decoding method for sign prediction of transform coefficients according to any one of claims 1 to 17.

21. 1. A video coding method for sign prediction of transform coefficients, comprising: generating, by an encoder, transform coefficients for a transform block of a video frame from the video; determining, by the encoder, a plurality of regions in the transform block, the plurality of regions including a code prediction area for performing the code prediction and at least one other region; predicting, by the encoder, signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block; generating, by the encoder, a bitstream to signal signs of the transform coefficients associated with the plurality of regions of the transform block according to a region-based order; The method includes:

22. The video encoding method of claim 21 , wherein the regions in the transform block are determined based on an area size threshold.

23. 23. The video encoding method of claim 22, wherein the code prediction area is determined to be a first region in an upper left corner of the transform block having a width and height equal to the area size threshold.

24. 24. The video encoding method of claim 23, wherein the at least one other region includes a second region outside the first region that encompasses a remaining area of ​​the transform block.

25. encoding the transform coefficients in the first region according to a first scan order; encoding the transform coefficients in the second region according to a second scanning order different from the first scanning order; 25. The video encoding method of claim 24, further comprising:

26. 26. The video encoding method of claim 25, wherein the first scanning order is a horizontal scanning order and the second scanning order is a diagonal scanning order.

27. 25. The video encoding method of claim 24, wherein the signs of the transform coefficients associated with the multiple regions of the transform block are signaled according to the region-based order of the second region followed by the first region.

28. 24. The video encoding method of claim 23, wherein the at least one other region includes a second region that encompasses an area in the upper left corner of the transform block having a width and height equal to a maximum area size threshold and is outside the first region, and the at least one other region further includes a third region that surrounds the remaining area of ​​the transform block outside the first and second regions.

29. encoding the signs of the transform coefficients in the first region, the second region, and the third region according to at least two different scan orders; 30. The video encoding method of claim 28, further comprising:

30. 30. The video encoding method of claim 29, wherein the transform coefficients in the first region and the second region are coded according to a horizontal scan order and the transform coefficients in the third region are coded according to a diagonal scan order.

31. 26. The video encoding method of claim 25, wherein the signs of transform coefficients associated with the multiple regions of the transform block are signaled according to the region-based order of the third region, followed by the first region, and then the second region.

32. 23. The video encoding method of claim 22, wherein the area size threshold is a fixed value for all transform blocks of the video, and the area size threshold is not signaled in the bitstream.

33. adaptively determining the area size threshold for the transform block; signaling the area size threshold in the bitstream; and 23. The video encoding method of claim 22, further comprising:

34. 34. The video encoding method of claim 33, wherein the area size threshold is signaled in a video parameter set, a sequence parameter set, a picture parameter set, or at a slice header and coding block level.

35. generating a set of code signaling bits based on the codes predicted for the set of candidate transform coefficients; signaling said series of code signaling bits in said bitstream; 22. The video encoding method of claim 21, further comprising:

36. Predicting signs for a set of candidate transform coefficients associated with the sign prediction area of ​​the transform block includes: determining 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; applying a template-based hypothesis generation scheme to generate a plurality of candidate hypotheses for a plurality of combinations of said code candidates, respectively; selecting a hypothesis from the plurality of candidate hypotheses as a set of predictive codes for the set of candidate transform coefficients; 22. The video encoding method of claim 21, further comprising:

37. applying a linear transform and a low frequency non-separable transform (LFNST) to generate the transform coefficients of the transform block; The video encoding method of claim 1 , further comprising:

38. A processor configured to implement a video coding method for sign prediction of transform coefficients according to any one of claims 21 to 37; a memory coupled to the processor and configured to store the bitstream; A video encoding device comprising:

39. A non-transitory computer readable storage medium having stored therein instructions which, when executed by a processor, cause the processor to perform a video coding method for sign prediction of transform coefficients according to any of claims 21 to 37, comprising: The bitstream is stored on the computer readable storage medium.

40. A non-transitory computer readable storage medium having stored therein a bitstream produced by a video coding method for sign prediction of transform coefficients according to any one of claims 21 to 37.

Images