Merging intra prediction data for video coding

Abstract

Certain aspects of the present disclosure provide video coding that incorporates intra data from one or more neighboring blocks and reuses intra data of a current block. An encoder can encode a syntax element indicating that an intra merge mode is used for the block. A merge candidate list can be generated that includes coding modes from one or more neighboring intra coded blocks, and two or more parameters associated with at least one coding mode can be stored. The encoder can calculate a template cost, reorder the candidate list based on the cost, select a coding mode from the merge candidate list, and encode the current block using the selected coding mode. A decoder can decode a syntax element, generate a merge candidate list, reorder the list, determine a coding mode based on the merge candidate list, and decode the current block using the coding mode.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application No. 19 / 171,928, filed April 7, 2025; U.S. Provisional Application No. 63 / 631,871, filed April 9, 2024; U.S. Provisional Application No. 63 / 656,856, filed June 6, 2024; and U.S. Provisional Application No. 63 / 681,982, filed August 12, 2024, the entire contents of each of these applications are hereby incorporated by reference. U.S. Patent Application No. 19 / 171,928, filed April 7, 2025, claims the benefits of U.S. Provisional Application No. 63 / 631,871, filed April 9, 2024; U.S. Provisional Application No. 63 / 656,856, filed June 6, 2024; and U.S. Provisional Application No. 63 / 681,982, filed August 12, 2024. Technical Field

[0003] This disclosure relates to various aspects of video encoding and video decoding. Background Technology

[0004] Digital video capabilities can be incorporated into a wide variety of devices, including digital televisions, digital live broadcast systems, wireless broadcasting systems, personal digital assistants (PDAs), laptops or desktop computers, tablets, e-book readers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite wireless phones (so-called "smartphones"), video conferencing equipment, video streaming devices, and more. Digital video devices implement video decoding technologies, such as those defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4 (Part 10, Advanced Video Decoding (AVC)), ITU-T H.265 / High Efficiency Video Decoding (HEVC), ITU-T H.266 / Variety Video Decoding (VVC) and extensions to these standards, as well as proprietary video codecs / formats such as AOMedia Video1 (AV1) developed by the Open Media Alliance. By implementing such video decoding technologies, video devices can more efficiently send, receive, encode, decode, and / or store digital video information.

[0005] Video decoding techniques include spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or remove redundancy inherent in video sequences. For block-based video decoding, video slices (e.g., video pictures or portions of video pictures) can be divided into video blocks, which may also be referred to as decoding tree units (CTUs), decoding units (CUs), and / or decoding nodes. Video blocks in a slice after intra-frame decoding (I) of a picture are encoded using spatial prediction relative to reference samples in adjacent blocks within the same picture. Video blocks in a slice after inter-frame decoding (P or B) of a picture can use spatial prediction relative to reference samples in adjacent blocks within the same picture or temporal prediction relative to reference samples in other reference pictures. A picture may be called a frame, and a reference picture may be called a reference frame. Summary of the Invention

[0006] The following summary provides a basic understanding of certain aspects of the disclosed subject matter. This summary is not a broad overview. It is not intended to identify key / important elements or describe the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that follows.

[0007] In summary, various methods, apparatuses, and systems related to improving the efficiency and performance of video decoding are disclosed. Decoding the current block may involve merging intra-frame data from neighboring blocks and reusing that intra-frame data for decoding. According to one aspect, the encoder generates a syntax element to signal the use of an intra-frame merging mode. The encoder then generates a merging candidate list, which includes decoding modes from neighboring intra-frame decoding blocks and multiple associated parameters for each mode. In some examples, the encoder calculates the template cost for each candidate, reorders the merging candidate list based on these costs, and selects the optimal mode to ensure it is best suited for the current block. The decoder receives the syntax element, generates the merging candidate list, reorders the merging candidate list, determines the optimal decoding mode, and decodes the current block using that decoding mode. Merging intra-frame data (including two or more parameters from some intra-frame prediction modes) and optimizing the selection of candidate decoding modes can reduce redundancy, improve prediction accuracy, and enhance overall video quality.

[0008] According to one aspect, a method for decoding video data is disclosed. The method includes: determining a decoding mode of one or more adjacent intra-decoded blocks from a current block based on an intra-merging mode, wherein at least a first decoding mode from a first adjacent block includes two or more parameters; generating a merge candidate list based on the intra-merging mode, the merge candidate list including the decoding mode from the one or more adjacent intra-decoded blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; selecting the first decoding mode from the merge candidate list; and decoding the current block using the first decoding mode and the two or more parameters.

[0009] According to another aspect, an apparatus configured to decode video data is disclosed. The apparatus includes one or more memories and processing circuitry communicating with the one or more memories. The processing circuitry is configured to: determine a decoding mode for one or more adjacent intra-decoding blocks from a current block based on an intra-merging mode, wherein a first decoding mode from a first adjacent block includes two or more parameters; generate a merge candidate list based on the intra-merging mode, the merge candidate list including the decoding mode from the one or more adjacent intra-decoding blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; select the first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0010] According to another aspect, a computer-readable storage medium having instructions stored thereon is disclosed, which, when executed, cause one or more processors to: determine, based on an intra-frame merging mode, a decoding mode of one or more adjacent intra-frame decoded blocks from a current block, wherein at least a first decoding mode in the decoding mode includes two or more parameters; generate a merge candidate list based on the intra-frame merging mode, the merge candidate list including the decoding mode from the one or more adjacent intra-frame decoded blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; select the first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0011] To accomplish the foregoing and related objectives, certain exemplary aspects of the claimed subject matter are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the subject matter can be practiced, all of which are intended to fall within the scope of the claimed subject matter. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the accompanying drawings. Attached Figure Description

[0012] The accompanying drawings depict certain features and are therefore not intended to limit the scope of this disclosure.

[0013] Figure 1 This is a block diagram illustrating an example video encoding and decoding system that can perform the techniques of this disclosure.

[0014] Figure 2 Example intra-frame prediction modes that can be used in conjunction with the techniques disclosed herein are illustrated.

[0015] Figure 3 Example adjacent blocks are shown for constructing a list of the most likely patterns that can be used in conjunction with the techniques disclosed herein.

[0016] Figure 4 A sample is illustrated in one example of decoder-side intra-frame mode derivation (DIMD) that can be used in conjunction with the techniques of this disclosure.

[0017] Figure 5 A sample of a location-dependent DIMD that can be used in conjunction with the techniques of this disclosure is illustrated.

[0018] Figure 6 An example of template-based intra-frame mode derivation (TIMD) fusion that can be used in conjunction with the techniques of this disclosure is illustrated.

[0019] Figure 7 An example reference line for template-based multi-reference line intra-frame prediction (TMRL) that can be used in conjunction with the techniques of this disclosure is illustrated.

[0020] Figure 8 An example of intra-template matching (intraTMP) that can be used in conjunction with the techniques disclosed herein is illustrated.

[0021] Figure 9 An example of intraTMP fusion that can be used in conjunction with the techniques disclosed herein is illustrated.

[0022] Figure 10 An example of an intraTMP linear filter model that can be used in conjunction with the techniques of this disclosure is illustrated.

[0023] Figure 11 An example of intraTMP subpixel precision that can be used in conjunction with the techniques of this disclosure is illustrated.

[0024] Figure 12 Examples of adjacent and non-adjacent adjacent blocks that can be used in conjunction with the techniques of this disclosure are illustrated.

[0025] Figure 13 Example template adjacent chroma decoding units that can be used in conjunction with the techniques of this disclosure are illustrated.

[0026] Figure 14 This is a block diagram illustrating an example video encoder that can perform the techniques of this disclosure.

[0027] Figure 15 This is a block diagram illustrating an example video decoder that can perform the techniques of this disclosure.

[0028] Figure 16 This is a flowchart illustrating an example method for encoding the current block according to the technology of this disclosure.

[0029] Figure 17 This is a flowchart illustrating an example method for decoding the current block according to the technology of this disclosure.

[0030] Figure 18 This is a flowchart illustrating an example method for decoding a current block of video data according to the technology of this disclosure.

[0031] For ease of understanding, the same reference numerals are used where possible to designate common elements across the figures. Elements and features of one embodiment can be beneficially incorporated into other embodiments without further elaboration. Detailed Implementation

[0032] Various aspects of this disclosure provide apparatus, methods, processing systems, and computer-readable media for performing video decoding by merging intra-frame data from adjacent blocks and reusing intra-frame data for decoding the current block.

[0033] The aspects disclosed herein address these drawbacks using intra-frame data merging. The encoder encodes syntax elements to signal the use of an intra-frame data merging mode and creates a merge candidate list. The merge candidate list may include intra-frame decoding modes from neighboring blocks along with multiple relevant parameters for each mode. Furthermore, the encoder evaluates the template cost of each decoding mode and reorders the merge candidate list. Template cost can be a measure of how well a candidate decoding mode's prediction matches a reconstructed video sample. Reordering prioritizes candidate decoding modes with lower costs (e.g., better predictions), placing them higher in the merge candidate list. The encoder then selects an intra-frame decoding mode from the reordered merge candidate list to encode the current block. The decoder performs a similar inverse process, including: decoding the syntax elements signaling the use of the intra-frame data merging mode, generating the merge candidate list, evaluating the template cost of each candidate decoding mode in the merge candidate list, recording the merge candidate list based on the template cost, selecting a decoding mode from the merge candidate list (e.g., based on the list index signaled by the encoder), and decoding the video data using the selected decoding mode. Depending on one particular aspect, the selected decoding mode may include two or more parameters of the decoding mode reused from adjacent blocks.

[0034] Intra-frame merging enhances efficiency by merging or reusing intra-frame decoding modes from adjacent blocks, thereby minimizing redundancy. Furthermore, intra-frame merging reduces the bit rate because only the index identifying the decoding mode is sent instead of the complete decoding mode information. Additionally, decoding is simplified because the decoder only needs to reconstruct the candidate list and retrieve the mode using the sent index. In this way, computational complexity is reduced, thus accelerating the encoding and decoding process. Moreover, utilizing decoding modes with more than one parameter can improve prediction accuracy by reducing prediction errors and better capturing complex structures. Furthermore, merging or reusing decoding modes from adjacent blocks reduces redundant information, thereby improving compression efficiency and accelerating decoding speed, and so on.

[0035] Example video decoding system

[0036] Figure 1 This is a block diagram illustrating an example video encoding and decoding system 100 capable of performing the techniques of this disclosure. The techniques of this disclosure generally relate to decoding (encoding and / or decoding) video data. Generally speaking, video data includes any data used for processing video. Thus, video data may include unencoded raw video, encoded video, decoded (e.g., reconstructed) video, and video metadata, such as signaling data.

[0037] like Figure 1As shown, in this example, system 100 includes a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116. Specifically, source device 102 provides the video data to destination device 116 via a computer-readable medium 110. Source device 102 and destination device 116 can be or may include any of a wide range of devices, such as desktop computers, laptop computers, mobile devices, tablet computers, set-top boxes, mobile phones (such as smartphones), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, broadcast receiver devices, etc. In some cases, source device 102 and destination device 116 may be configured for wireless communication and may therefore be referred to as wireless communication devices.

[0038] exist Figure 1 In the example, source device 102 includes a video source 104, memory 106, video encoder 200, and output interface 108. Destination device 116 includes an input interface 122, video decoder 300, memory 120, and display device 118. According to this disclosure, the video encoder 200 of source device 102 and the video decoder 300 of destination device 116 can be configured to apply techniques for intra-frame prediction. Thus, source device 102 represents an example of a video encoding device, while destination device 116 represents an example of a video decoding device. In other examples, the source device and destination device may include other components or arrangements. For example, source device 102 may receive video data from an external video source such as an external camera. Similarly, destination device 116 may interface with an external display device, rather than including an integrated display device.

[0039] like Figure 1 As shown, system 100 is merely an example. In general, any digital video encoding and / or decoding device can perform techniques for intra-frame prediction, as disclosed more specifically herein. Source device 102 and destination device 116 are merely examples of such decoding devices, where source device 102 generates decoded video data for transmission to destination device 116. This disclosure refers to a “decoding” device as a device that performs the decoding (e.g., encoding and / or decoding) of data. Thus, video encoder 200 and video decoder 300 represent examples of decoding devices, specifically, a video encoder and a video decoder, respectively. In some examples, source device 102 and destination device 116 may operate in a substantially symmetrical manner, such that each of source device 102 and destination device 116 includes video encoding and decoding components. Therefore, system 100 may support one-way or two-way video transmission between source device 102 and destination device 116, for example, for video streaming, video playback, video broadcasting, or video telephony.

[0040] Generally, video source 104 represents the source of video data (i.e., unencoded raw video data) and provides a sequential series of pictures (also referred to as "frames") of video data to video encoder 200, which encodes the data for the pictures. Video source 104 of source device 102 may include video capture devices such as cameras, video archives containing previously captured raw video, and / or video feed interfaces for receiving video from video content providers. Alternatively, video source 104 may generate computer graphics-based data as source video, or a combination of live video, archived video, and computer-generated video. In each case, video encoder 200 encodes the captured, pre-captured, or computer-generated video data. Video encoder 200 may rearrange the pictures from the received order (sometimes referred to as "display order") to a decoding order for decoding. Video encoder 200 may generate a bitstream comprising the encoded video data. Then, the source device 102 can output the encoded video data to the computer-readable medium 110 via the output interface 108 for reception and / or retrieval by, for example, the input interface 122 of the destination device 116.

[0041] The memory 106 of source device 102 and the memory 120 of destination device 116 represent general-purpose memory. In some examples, memories 106 and 120 may store raw video data, such as raw video from video source 104 and raw decoded video data from video decoder 300. Additionally or alternatively, memories 106 and 120 may store software instructions executable by, for example, video encoder 200 and video decoder 300. Although memories 106 and 120 are shown separately from video encoder 200 and video decoder 300 in this example, it should be understood that video encoder 200 and video decoder 300 may also include internal memory for functionally similar or equivalent purposes. Furthermore, memories 106 and 120 may store encoded video data, such as output from video encoder 200 and input to video decoder 300. In some examples, portions of memories 106 and 120 may be allocated as one or more video buffers, for example, to store raw decoded and / or encoded video data.

[0042] Computer-readable medium 110 may represent any type of medium or device capable of transmitting encoded video data from source device 102 to destination device 116. In one example, computer-readable medium 110 represents a communication medium that enables source device 102 to directly transmit encoded video data to destination device 116 in real time, for example, via a radio frequency network or a computer-based network. According to a communication standard such as a wireless communication protocol, output interface 108 may modulate the transmitted signal including the encoded video data, and input interface 122 may demodulate the received transmitted signal. The communication medium may include any wireless or wired communication medium, such as radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network such as a local area network, a wide area network, or a global network (such as the Internet). The communication medium may include a router, switch, base station, or any other equipment that may be useful for facilitating communication from source device 102 to destination device 116.

[0043] In some examples, source device 102 can output encoded data from output interface 108 to storage device 112. Similarly, destination device 116 can access encoded data from storage device 112 via input interface 122. Storage device 112 may include any data storage medium of various distributed or locally accessed data storage media, such as hard disk drives, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data.

[0044] In some examples, source device 102 can output encoded video data to file server 114 or another intermediate storage device that can store the encoded video data generated by source device 102. Destination device 116 can access the stored video data from file server 114 via streaming or download.

[0045] File server 114 can be any type of server device capable of storing encoded video data and sending the encoded video data to destination device 116. File server 114 may represent a web server (e.g., for a website), a server configured to provide file transfer protocol services (such as File Transfer Protocol (FTP) or FLUTE-based file delivery protocol), a Content Delivery Network (CDN) device, a Hypertext Transfer Protocol (HTTP) server, a Multimedia Broadcast Multicast Service (MBMS) or Enhanced MBMS (eMBMS) server, and / or a Network Attached Storage (NAS) device. File server 114 may additionally or alternatively implement one or more HTTP streaming protocols, such as HTTP-based Dynamic Adaptive Streaming (DASH), HTTP Live Streaming (HLS), Real-Time Streaming Protocol (RTSP), HTTP Dynamic Streaming, etc.

[0046] Destination device 116 can access encoded video data from file server 114 via any standard data connection, including an internet connection. This may include a wireless channel (e.g., Wi-Fi connection), a wired connection (e.g., digital subscriber line (DSL), cable modem, etc.), or a combination of both, suitable for accessing encoded video data stored on file server 114. Input interface 122 can be configured to operate according to any or more of the various protocols discussed above for retrieving or receiving media data from file server 114, or other such protocols for retrieving media data.

[0047] Output interface 108 and input interface 122 can represent a wireless transmitter / receiver, a modem, a wired networking component (e.g., an Ethernet card), a wireless communication component operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where output interface 108 and input interface 122 include wireless components, output interface 108 and input interface 122 can be configured to transmit data, such as encoded video data, according to cellular communication standards such as 4G, 4G-LTE (Long Term Evolution), Advanced LTE, 5G, etc. In some examples where output interface 108 includes a wireless transmitter, output interface 108 and input interface 122 can be configured to comply with other wireless standards such as the IEEE 802.11 specification, the IEEE 802.15 specification (e.g., ZigBee), etc. ™ ),Bluetooth ™Standards are used to transmit data, such as encoded video data. In some examples, source device 102 and / or destination device 116 may include corresponding system-on-chip (SoC) devices. For example, source device 102 may include an SoC device for performing functions belonging to video encoder 200 and / or output interface 108, and destination device 116 may include an SoC device for performing functions belonging to video decoder 300 and / or input interface 122.

[0048] The technology disclosed herein can be applied to video decoding to support any multimedia application in a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, internet streaming video transmission (such as HTTP-based Dynamic Adaptive Streaming (DASH)), digital video encoded onto data storage media, decoding of digital video stored on data storage media, or other applications.

[0049] The input interface 122 of the destination device 116 receives an encoded video bitstream from a computer-readable medium 110 (e.g., a communication medium, storage device 112, file server 114, etc.). The encoded video bitstream may include signaling information defined by the video encoder 200 and also used by the video decoder 300, such as syntax elements having values ​​describing the characteristics and / or processing of video blocks or other decoded units (e.g., slices, pictures, picture groups, sequences, etc.). The display device 118 displays a decoded picture of the decoded video data to the user. The display device 118 may represent 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.

[0050] although Figure 1Not shown, but in some examples, the video encoder 200 and the video decoder 300 may each be integrated with the audio encoder and / or audio decoder (e.g., audio codec), and may include appropriate MUX-DEMUX units or other hardware and / or software to handle multiplexed streams including both audio and video in a shared data stream. Example audio codecs may include AAC, AC-3, AC-4, ALAC, ALS, AMBE, AMR, AMR-WB (G.722.2), AMR-WB+, aptX (various versions), ATRAC, BroadVoice (BV16, BV32), CELT, Enhanced AC-3 (E-AC-3), EVS, FLAC, G.711, G.722, G.722.1, G.722.2 (AMR-WB), G.723.1, G.726, G.728, G.729, G.729.1, GSM-FR, HE-AAC, iLBC, iSAC, LA Lyra, Monkey's Audio, MP1, MP2 (MPEG-1, 2 Audio Layer II), MP3, Musepack, Nellymoser Asao, OptimFROG, Opus, Sac, Satin, SBC, SILK, Siren 7, Speex, SVOPC, TrueAudio (TTA), TwinVQ, USAC, Vorbis (Ogg), WavPack and Windows Media Aud.

[0051] Both the video encoder 200 and the video decoder 300 can be implemented as any of a variety of suitable encoder and / or decoder circuits comprising a processing system, 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 the technology is implemented in part in software, the device may store instructions for the software in a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the technology of this disclosure. Each of the video encoder 200 and the video decoder 300 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. Devices including the video encoder 200 and / or the video decoder 300 may implement the video encoder 200 and / or the video decoder 300 in processing circuitry such as integrated circuits and / or microprocessors. Such devices may be wireless communication devices (such as cellular phones) or any other type of device described herein.

[0052] The video encoder 200 and video decoder 300 may operate according to a video decoding standard such as ITU-T H.265 (also known as High Efficiency Video Decoding (HEVC)) or its extensions (such as Multi-View and / or Scalable Video Decoding Extensions)). Alternatively, the video encoder 200 and video decoder 300 may operate according to other proprietary or industry standards such as ITU-T H.266 (also known as Multi-Functional Video Decoding (VVC)). In other examples, the video encoder 200 and video decoder 300 may operate according to proprietary video codecs / formats such as AOMedia Video 1 (AV1), extensions to AV1, and / or subsequent versions of AV1 (e.g., AV2)). In other examples, the video encoder 200 and video decoder 300 may operate according to other proprietary formats or industry standards. However, the technology disclosed herein is not limited to any particular decoding standard or format. Generally speaking, the video encoder 200 and the video decoder 300 can be configured to perform the techniques of this disclosure in combination with any video decoding technique that uses intra-frame prediction, such as merging intra-frame data related to the decoding mode from adjacent blocks and reusing intra-frame data for decoding the current block.

[0053] Generally, the video encoder 200 and video decoder 300 perform block-based decoding of images. The term "block" typically refers to a structure that includes data to be processed (e.g., encoded, decoded, or otherwise used during encoding and / or decoding). For example, a block may include a two-dimensional matrix of samples of luminance and / or chrominance data. Generally, the video encoder 200 and video decoder 300 decode video data represented in YUV (e.g., Y, Cb, Cr) format. That is, instead of decoding the red, green, and blue (RGB) data used for images, the video encoder 200 and video decoder 300 decode both the luminance and chrominance components, where the chrominance components may include both red and blue hue chrominance components. In some examples, the video encoder 200 converts the received RGB format data to a YUV representation before encoding, and the video decoder 300 converts that YUV representation to RGB format. Alternatively, preprocessing and postprocessing units (not shown) may perform these conversions.

[0054] This disclosure generally relates to the decoding (e.g., encoding and decoding) of images to include processes of encoding or decoding data of the image. Similarly, this disclosure may relate to the decoding of blocks of images to include processes of encoding or decoding data used for the blocks (e.g., prediction and / or residual decoding). Encoded video bitstreams typically include a series of values ​​for syntax elements representing decoding decisions (e.g., decoding modes) and the partitioning of images into blocks. Therefore, references to the decoding of images or blocks should generally be understood as the decoded values ​​of the syntax elements that form the images or blocks.

[0055] HEVC defines various blocks, including decoding units (CUs), prediction units (PUs), and transform units (TUs). According to HEVC, a video decoder (such as a video encoder 200) divides the decoding tree unit (CTU) into CUs based on a quadtree structure. That is, the video decoder divides the CTU and CU into four equal, non-overlapping squares, and each node of the quadtree has zero or four child nodes. Nodes without child nodes are called "leaf nodes," and the CU of such leaf nodes may include one or more PUs and / or one or more TUs. The video decoder may further divide the PUs and TUs. For example, in HEVC, a residual quadtree (RQT) represents the partitioning of the TU. In HEVC, the PU represents inter-frame prediction data, while the TU represents residual data. The CU after intra-frame prediction includes intra-frame prediction information, such as intra-frame mode indication.

[0056] As another example, video encoder 200 and video decoder 300 can be configured to operate according to VVC. According to VVC, the video decoder (such as video encoder 200) partitions the image into multiple CTUs. Video encoder 200 can partition the CTUs according to a tree structure (such as a quadtree-binary tree (QTBT) structure or a multi-type tree (MTT) structure). The QTBT structure removes the concept of multiple partition types, such as the separation between CUs, PUs, and TUs in HEVC. The QTBT structure includes two levels: a first level partitioned according to quadtree partitioning, and a second level partitioned according to binary tree partitioning. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to CUs.

[0057] In the MTT partitioning structure, blocks can be divided using quadtree (QT) partitioning, binary tree (BT) partitioning, and one or more types of ternary tree (TT) partitioning (also known as triplet tree (TT)). A ternary tree or triplet tree partition is a partition in which a block is divided into three sub-blocks. In some examples, a ternary tree or triplet tree partition divides a block into three sub-blocks without dividing the original block through the center. Partition types in MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0058] When operating according to the AV1 codec, the video encoder 200 and video decoder 300 can be configured to decode video data in blocks. In AV1, the largest decoded block that can be processed is called a superblock. In AV1, a superblock can be 128x128 luminance samples or 64x64 luminance samples. However, in subsequent video decoding formats (e.g., AV2), superblocks can be defined by different (e.g., larger) luminance sample sizes. In some examples, the superblock is the top level of a block quadtree. The video encoder 200 can further divide the superblock into smaller decoded blocks. The video encoder 200 can use square or non-square partitions to divide the superblock and other decoded blocks into smaller blocks. Non-square blocks can include N / 2xN blocks, NxN / 2 blocks, N / 4xN blocks, and NxN / 4 blocks. The video encoder 200 and video decoder 300 can perform separate prediction and transform processing on each decoded block within the decoded block.

[0059] AV1 also defines video data tiles. A tile is a rectangular array of superblocks that can be decoded independently of other tiles. That is, the video encoder 200 and video decoder 300 can encode and decode the decoding blocks within a tile separately without using video data from other tiles. However, the video encoder 200 and video decoder 300 can perform filtering across tile boundaries. The tile size can be uniform or non-uniform. Tile-based decoding enables parallel processing and / or multithreading in the encoder and decoder implementations.

[0060] In some examples, the video encoder 200 and the video decoder 300 may use a single QTBT or MTT structure to represent each of the luma and chroma components, while in other examples, the video encoder 200 and the video decoder 300 may use two or more QTBT or MTT structures, such as one QTBT / MTT structure for the luma component and another QTBT / MTT structure for the two chroma components (or two QTBT / MTT structures for the respective chroma components).

[0061] The video encoder 200 and the video decoder 300 can be configured to use quadtree partitioning, QTBT partitioning, MTT partitioning, superblock partitioning or other partitioning structures.

[0062] In some examples, a CTU includes a decoded tree block (CTB) of luminance samples, two corresponding CTBs of chrominance samples of an image with three sample arrays, or a CTB of samples of an image decoded using three separate color planes and a syntax structure for decoding the samples. A CTB can be an NxN sample block of some value N, such that a partitioning method divides the components into CTBs. A component is an array or a single sample from one of the three arrays (luminance and two chrominance) constituting a 4:2:0, 4:2:2, or 4:4:4 color format image, or an array or a single sample constituting an array or array constituting a monochrome format image. In some examples, a decoded block is an MxN sample block of values ​​M and N, such that a partitioning method divides the CTB into decoded blocks.

[0063] Blocks (e.g., CTUs or CUs) can be grouped in various ways within an image. As an example, a brick can refer to a rectangular area of ​​a row of CTUs within a specific tile in an image. A tile can be a rectangular area of ​​CTUs within a specific tile column and a specific tile row in an image. A tile column refers to a rectangular area of ​​a CTU having a height equal to the height of the image and a width specified by syntax elements (e.g., such as in an image parameter set). A tile row refers to a rectangular area of ​​a CTU having a height specified by syntax elements (e.g., such as in an image parameter set) and a width equal to the width of the image.

[0064] In some examples, a tile can be divided into multiple bricks, each of which may include one or more CTU rows within the tile. A tile that is not divided into multiple bricks can also be called a brick. However, bricks that are a true subset of a tile cannot be called a tile. Bricks in an image can also be arranged in slices. A slice can be an integer number of bricks in an image that can be uniquely contained within a single Network Abstraction Layer (NAL) unit. In some examples, a slice includes multiple complete tiles or a continuous sequence of complete bricks that include only one tile.

[0065] This disclosure uses "NxN" and "N by N" interchangeably to refer to the sample size of a block (such as a CU or other video block) in the vertical and horizontal dimensions, for example, 16x16 samples or 16 by 16 samples. Generally, a 16x16 CU will have 16 samples in the vertical direction (y=16) and 16 samples in the horizontal direction (x=16). Similarly, an NxNCU typically has N samples in the vertical direction and N samples in the horizontal direction, where N represents a non-negative integer value. Samples in a CU can be arranged in rows and columns. Furthermore, a CU does not necessarily need to have the same number of samples in the horizontal direction as it does in the vertical direction. For example, a CU may include NxM samples, where M is not necessarily equal to N.

[0066] The video encoder 200 encodes video data representing prediction and / or residual information, as well as other information, for use in the control unit (CU). The prediction information indicates how the CU should be predicted to form a prediction block for the CU. The residual information typically represents the sample-by-sample difference between a sample of the CU before encoding and the prediction block.

[0067] To predict the Cubic Frame (CU), the video encoder 200 typically forms prediction blocks for the CU through inter-frame prediction or intra-frame prediction. Inter-frame prediction typically refers to predicting the CU from data in a previously decoded image, while intra-frame prediction typically refers to predicting the CU from data in a previously decoded image within the same frame. To perform inter-frame prediction, the video encoder 200 can use one or more motion vectors to generate prediction blocks. The video encoder 200 can typically perform a motion search to identify reference blocks that closely match the CU, for example, based on the differences between the CU and a reference block. The video encoder 200 can use sum of absolute differences (SAD), sum of squared differences (SSD), mean absolute difference (MAD), mean squared difference (MSD), or other such difference calculations to compute difference metrics to determine whether a reference block closely matches the current CU. In some examples, the video encoder 200 can use unidirectional or bidirectional prediction to predict the current CU.

[0068] Some examples of VVC also provide an affine motion compensation mode, which can be viewed as an inter-frame prediction mode. In affine motion compensation mode, the video encoder 200 can determine two or more motion vectors representing non-translational motion, such as zooming in or out, rotation, perspective motion, or other irregular motion types.

[0069] To perform intra-frame prediction, the video encoder 200 can select an intra-frame prediction mode to generate prediction blocks. Some examples of VVC provide sixty-seven intra-frame prediction modes, including various directional modes, as well as planar and DC modes. Generally, the video encoder 200 selects an intra-frame prediction mode that describes the neighboring samples of the current block (e.g., the block of the CU) and predicts samples of the current block from them. Assuming the video encoder 200 decodes the CTU and CU in raster scan order (from left to right, from top to bottom), such samples can typically be located above, to the upper left, or to the left of the current block in the same image as the current block.

[0070] The video encoder 200 encodes data representing the prediction mode of the current block. For example, for inter-frame prediction modes, the video encoder 200 may encode data indicating which of the various available inter-frame prediction modes is used, as well as the motion information for the corresponding mode. For example, for unidirectional or bidirectional inter-frame prediction, the video encoder 200 may encode motion vectors using Advanced Motion Vector Prediction (AMVP) or merging modes. The video encoder 200 may use similar modes to encode motion vectors used for affine motion compensation modes.

[0071] AV1 includes two common techniques for encoding and decoding blocks of video data. These two common techniques are intra-frame prediction (e.g., intra-frame prediction or spatial prediction) and inter-frame prediction (e.g., inter-frame prediction or temporal prediction). In the context of AV1, when using intra-frame prediction modes to predict blocks of video data for the current frame, the video encoder 200 and video decoder 300 do not use video data from other frames of the video data. For most intra-frame prediction modes, the video encoder 200 encodes blocks of the current frame based on the difference between sample values ​​in the current block and predicted values ​​generated from reference samples in the same frame. The video encoder 200 determines the predicted values ​​generated from the reference samples based on the intra-frame prediction mode.

[0072] After prediction (such as intra-frame or inter-frame prediction for a block), the video encoder 200 can compute residual data for the block. The residual data (such as a residual block) represents the sample-wise difference between the block and the prediction block used to form the block, which is formed using the corresponding prediction mode. The video encoder 200 can apply one or more transforms to the residual block to produce transformed data in the transform domain rather than the sample domain. For example, the video encoder 200 can apply a Discrete Cosine Transform (DCT), an integer transform, a wavelet transform, or a conceptually similar transform to the residual video data. Additionally, the video encoder 200 can apply a secondary transform after the first transform, such as a Mode Correlated Inseparable Secondary Transform (MDNSST), a Signal Correlation Transform, a Karhunen-Loeve Transform (KLT), etc. The video encoder 200 produces transform coefficients after applying one or more transforms.

[0073] As noted above, after any transformation that produces the transform coefficients, the video encoder 200 may perform quantization on the transform coefficients. Quantization generally refers to the process in which the transform coefficients are quantized to reduce the amount of data used to represent them, thereby providing further compression. By performing the quantization process, the video encoder 200 may reduce the bit depth associated with some or all of the transform coefficients. For example, the video encoder 200 may quantize the transform coefficients during quantization. n The place value is rounded down to... m Bit value, where n Greater than m In some examples, in order to perform quantization, the video encoder 200 may perform a bit-by-bit right shift of the value to be quantized.

[0074] After quantization, the video encoder 200 can scan the transform coefficients to generate a one-dimensional vector from a two-dimensional matrix containing the quantized transform coefficients. The scan can be designed to place higher-energy (and therefore lower-frequency) transform coefficients before the vector and lower-energy (and therefore higher-frequency) transform coefficients after the vector. In some examples, the video encoder 200 can utilize a predefined scan order to scan the quantized transform coefficients to produce a serialized vector, and then entropy-encode the quantized transform coefficients of that vector. In other examples, the video encoder 200 can perform an adaptive scan. After scanning the quantized transform coefficients to form a one-dimensional vector, the video encoder 200 can entropy-encode the one-dimensional vector, for example, according to context-adaptive binary arithmetic decoding (CABAC). The video encoder 200 can also entropy-encode the values ​​of syntax elements describing metadata associated with the encoded video data, which is used by the video decoder 300 when decoding the video data.

[0075] To perform CABAC, the video encoder 200 can assign context within a context model to the symbols to be transmitted. Context may involve, for example, whether the neighboring values ​​of a symbol are zero. Probability determination can be based on the context assigned to the symbols.

[0076] The video encoder 200 may further generate syntax data for the video decoder 300, such as block-based syntax data, image-based syntax data, and sequence-based syntax data, for example, in image headers, block headers, and slice headers, or generate other syntax data such as sequence parameter sets (SPS), image parameter sets (PPS), or video parameter sets (VPS). The video decoder 300 may also decode such syntax data to determine how to decode the corresponding video data.

[0077] In this way, the video encoder 200 can generate a bitstream that includes encoded video data, such as syntax elements describing the partitioning of images into blocks (e.g., CUs) and prediction and / or residual information for the blocks. Finally, the video decoder 300 can receive the bitstream and decode the encoded video data.

[0078] Generally, the video decoder 300 performs the reverse process of the video encoder 200 to decode the encoded video data of the bitstream. For example, the video decoder 300 can use CABAC to decode the values ​​of syntax elements used for the bitstream in a manner substantially similar to but reversed by the CABAC encoding process of the video encoder 200. Syntax elements can define partitioning information for dividing a picture into CTUs and defining the CUs of each CTU according to a corresponding partitioning structure such as a QTBT structure. Syntax elements can further define prediction and residual information for video data blocks (e.g., CUs).

[0079] The residual information can be represented, for example, by quantized transform coefficients. The video decoder 300 can inversely quantize and inverse transform the quantized transform coefficients of the block to reconstruct the residual block for the block. The video decoder 300 uses a signaling prediction mode (intra-frame prediction or inter-frame prediction) and associated prediction information (e.g., motion information for inter-frame prediction) to form a prediction block for the block. The video decoder 300 can then combine the prediction block and the residual block (on a sample-by-sample basis) to reconstruct the original block. The video decoder 300 can perform additional processing, such as performing a deblocking process to reduce visual artifacts along the block boundaries.

[0080] This disclosure may generally relate to "signaling" certain information (such as syntax elements). The term "signaling" can generally refer to the communication of values ​​and / or other data of syntax elements used to decode encoded video data. That is, video encoder 200 may signal the values ​​of syntax elements in the bitstream. Generally speaking, signaling refers to generating values ​​in the bitstream. As noted above, source device 102 may transmit the bitstream to destination device 116 substantially in real time or not in real time (such as when syntax elements are stored in storage device 112 for later retrieval by destination device 116).

[0081] As will be discussed in more detail below, this disclosure describes techniques for merging intra-prediction related data from multiple different intra-prediction or decoding modes in adjacent blocks. For example, according to the techniques of this disclosure, video encoder 200 and video decoder 300 may: determine decoding modes of one or more adjacent intra-decoding blocks from the current block based on an intra-merging mode, wherein at least a first decoding mode among the decoding modes from the first adjacent block includes two or more parameters; generate a merge candidate list based on the intra-merging mode, the merge candidate list including decoding modes from one or more adjacent intra-decoding blocks, the merge candidate list storing two or more parameters of the first decoding mode from the first adjacent block; select a first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0082] Since April 2021, JVET has been developing Enhanced Compression Model (ECM) software to enhance compression capabilities beyond VVC. The set of decoding tools in the ECM software encompasses functional blocks within the hybrid video decoding framework, including intra-frame prediction, inter-frame prediction, transform and coefficient decoding, intra-loop filtering, and entropy decoding. The techniques disclosed herein can be applied to ECM and existing video codecs such as VVC, AV1, AV2, or any other codec using intra-frame prediction.

[0083] Example Intra-Frame Decoding Tool

[0084] The following describes the selected intra-frame decoding tools currently used in ECM. Further descriptions of intra-frame tools can be found in “Algorithmic Description of Enhanced Compression Model 12 (ECM 12)” by M. Coban, R.-L. Liao, K. Naser, J. Ström, and L. Zhang, JVET-AG2025, March 2024.

[0085] Most Probable Pattern (MPM)

[0086] like Figure 2 As illustrated, intra-frame modes may include planar mode, DC mode, and 65 (or more) angle mode 210. Figure 2 Examples of intra-frame prediction or decoding modes that can be used in conjunction with the techniques disclosed herein are illustrated.

[0087] The video encoder 200 and the video decoder 300 can construct an MPM list using planar modes, intra-frame modes used in adjacent blocks of the current CU, decoder-side intra-frame mode derivation (DIMD) modes, and derivation modes that add offsets using existing angular modes in the list. Figure 3 This is an example showing the top-left (A1) adjacent block 310 and the top (A) adjacent block 312, the top-right (Ar) adjacent block 314, the left (L) adjacent block 316, and the bottom-left (BL) adjacent block 318. Intra-frame modes in the MPM list use shorter bitstreams to gain decoding benefits.

[0088] Decoder-side intra-frame mode derivation (DIMD)

[0089] When using DIMD, up to five DIMD patterns can be derived by analyzing the orientation of the content in the surrounding region of the current block. As shown below, the gradient histogram (HoG) is calculated on a three-sample width / height L-shaped template formed by the reconstructed samples.

[0090]

[0091] HoG is obtained using a Sobel filter, and the accumulation... Figure 4 The magnitude of all gradients in a given direction for all samples 410 within region 412. Figure 4 Example 410 is illustrated in one instance of DIMD that can be used in conjunction with the techniques of this disclosure. The video encoder 200 and video decoder 300 can select the direction with the highest cumulative amplitude as the DIMD mode. The video encoder 200 and video decoder 300 can then mix the obtained predictor with the DIMD mode to form the final DIMD prediction.

[0092] Location-dependent DIMD

[0093] An example of location-dependent DIMD is described in S. Blasi et al., “EE2-1.8: Location-dependent DIMD,” 29th meeting of the Joint Video Expert Group (JVET) of ITU-T SG16 WP 3 and ISO / IEC JTC 1 / SC 29 (telephone), January 11-20, 2023 (hereafter referred to as “JVET-AC0098”). Gradient calculations are performed separately for samples in each region, resulting in three histograms: H_above 510, H_left 512, and H_aboveLeft 514, as shown below. Figure 5 As shown. Figure 5 A sample of a location-dependent DIMD that can be used in conjunction with the techniques of this disclosure is illustrated.

[0094] Histograms H_above and H_left can be used to determine whether the DIMD mode dimdMode_i depends on a specific template region ABOVE or LEFT. There are three position-dependent indices (locDep_i), as shown below:

[0095] If (H[dimdMode_i] > 3H_left[dimdMode_i]): locDep_i = 1 (dimdMode_i depends on region ABOVE)

[0096] If (H[dimdMode_i] > 3H_above[dimdMode_i]): locDep_i = 2 (dimdMode_i depends on region LEFT)

[0097] Otherwise, locDep_i = 0 (dimdMode_i is not position-dependent).

[0098] Each value of locDep_i results in a different DIMD prediction. For more details, please refer to JVET-AC0098.

[0099] On-Bound Frame Decoding (OBIC)

[0100] An example of an occurrence-based intra-frame decoding (OBIC) mode is described in R. Yoouvalari et al., “EE2-2.2: Occurrence-based intra-frame decoding (OBIC),” 34th meeting of the Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, Rennes, France, 17-24 April 2024 (hereinafter referred to as “JVET-AH0076”). According to the OBIC method, the video decoder derives the intra-frame prediction mode of a block based on the occurrence of intra-frame modes in the block's spatial neighborhood. Under OBIC technology, the video decoder can obtain the block prediction using a mixture of up to five intra-frame modes (the highest occurrence rate) as well as planar modes or block vector-based prediction. The video decoder can determine the mixing weights based on the occurrence of each mode in the neighborhood. The mode used can be signaled using the PU level flag of CABAC decoding. The OBIC mode is used as a sub-mode of DIMD, and its flag can be signaled after the DIMD flag.

[0101] Template-based intra-frame mode derivation (TIMD) fusion

[0102] For each intra-prediction mode, wide-angle, DC, horizontal, vertical, and extended mode in the MPM list, the sum of absolute transformation differences (SATD) between the template's prediction and the reconstructed sample is calculated, such as... Figure 6 As shown. Figure 6 An example of the fusion of template-based intra-frame mode derivation (TIMD) 610 that can be used in conjunction with the techniques of this disclosure is illustrated.

[0103] The first two intra-prediction modes with the lowest SATD (e.g., TIMD1, TIMD2) are the TIMD modes selected for fusion.

[0104] If costMode2 < 2 costMode1: Prediction is based on weight1 Pred_TIMD1 + weight2 Pred_TIMD2 is derived, where weight1 = cost_TIMD2 / (cost_TIMD1 + cost_TIMD2), and weight2 = 1 - weight1. Otherwise, the prediction is derived only from TIMD1. A third non-angular TIMD pattern (e.g., planar or DC) can be used in conjunction with Pred_TIMD1 and Pred_TIMD2.

[0105] Template-based multi-reference line intra-frame prediction (TMRL)

[0106] The TMRL mode combines reference lines with prediction modes and uses a template matching method to construct a candidate combination list. The indices of the candidate combination list are decoded to indicate which reference line and prediction mode to use when decoding the current block. For more details, see L. Xu et al., “EE2-1.10: Template-based Multi-Reference Line Prediction,” 28th meeting of the Joint Video Experts Group (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29, Mainz, Germany, 20-28 October 2022 (hereafter referred to as “JVET-AB0156”).

[0107] The TMRL candidate is constructed as follows. The extended reference lines {1, 3, 5, 7, 12} have 5 x 10 = 50 combinations with the block-allowed intra-prediction patterns. Since the extended reference lines start from reference line 1, the area covered by reference line 0 is used for template matching. The sum of absolute differences (SAD) cost on template region 710 (e.g., ...) Figure 7 The calculations shown are between prediction and reconstruction (generated from 50 combinations). The 20 combinations with the lowest SAD cost are selected in ascending order to form the TMRL candidate list. The indices of the TMRL candidate list are decoded to indicate which reference line and which combination of prediction modes to use when decoding the current block.

[0108] Intra-template matching (intraTMP)

[0109] Intra-Template Matching Prediction (IntraTMP) is a special intra-prediction mode that copies the best prediction block from the reconstructed portion of the current frame, whose L-shaped template matches the current template. For a predefined search range, the video encoder 200 searches for the template most similar to the current template in the reconstructed portion of the current frame and uses the corresponding block as the prediction block. The video encoder 200 then signals the use of this mode, and the same prediction operation is performed at the video decoder 300.

[0110] The prediction signal is generated by matching the L-shaped, top-only, or left-only causal neighborhood of the current block with another block in a predefined search, such as... Figure 8 As shown. Figure 8 An example of intra-template matching (intraTMP) 810 that can be used in conjunction with the techniques of this disclosure is illustrated.

[0111] IntraTMP Fusion

[0112] Multiple prediction blocks from the reconstructed portion of the current frame (e.g., such as...) Figure 9 The reference block (n) shown (n = 0, 1, ...) is derived through the intraTMP search process. Figure 9An example of intraTMP fusion 910 that can be used in conjunction with the techniques of this disclosure is illustrated. Multiple predictors are then blended to derive the final prediction block. The blending weights (e.g., w(n), (n = 0, 1, …) as shown below) are computed from the template matching cost of each predictor, or using a Wiener filter-based weight derivation method. For further details, please refer to L. Zhang et al., “EE2-1.11: Intra-template matching prediction fusion,” 30th meeting of the Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, Antalya, Turkey, 21-28 April 2023 (hereinafter referred to as “JVET-AD0072”) and J. Ho et al., “EE2-1.16: Fusion method of Intra-template matching prediction (Intra TMP),” 30th meeting of the Joint Video Experts Group (JVET) of ITU-T SG16 WP 3 and ISO / IEC JTC 1 / SC 29, Antalya, Turkey, 21-28 April 2023 (hereinafter referred to as “JVET-AD0116”).

[0113] Intra-frame TMP linear filter model

[0114] Linear filters can be learned between the reference template and the current template, and a linear model can be applied to the reference block, such as... Figure 10 As shown. Figure 10 An example of an intraTMP linear filter model 1010 that can be used in conjunction with the techniques of this disclosure is illustrated. When subpixel precision is not used, this mode can be used with a single predictor, i.e., intraTMP without fusion. Additional details can be found in J. Huo et al., “EE2-1.115a: IntraTMP Based on Linear Filter Models,” 30th Meeting of the Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, Antalya, Turkey, 21-28 April 2023 (hereinafter referred to as “JVET-AD0112”).

[0115] IntraTMP subpixel precision

[0116] When using a single predictor (without fusion-based intraTMP), subpixel precision can be used with 1 / 2 pixel precision, 1 / 4 pixel precision, and 3 / 4 pixel precision, each with 8 possible orientations, such as... Figure 11 As shown. Figure 11An example of intraTMP subpixel precision 1110 that can be used in conjunction with the techniques of this disclosure is illustrated. For further details, see X. Li et al., “EE2-1.12: Intra TMP with Subpixel Precision,” 30th Meeting of the Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, Antalya, Turkey, 21-28 April 2023 (hereafter referred to as “JVET-AD0125”).

[0117] IntraTMP with local illumination compensation

[0118] In some examples, IntraTMP with Local Illumination Compensation (LIC) is allowed. Consider the following:

[0119] 1) Allows LIC to be used together with intraTMP.

[0120] 2) Allows the use of top-only and left-only templates to determine the LIC model for screen content decoding. For camera capture decoding, only the top-left template is used.

[0121] 3) Similar to Intra-Block Copy LC (IBC-LIC), it supports the Multi-Mode Linear Model (MMLM) for screen content decoding. For further details, see F. Le Leannec et al., “EE2-1.5: IntraTMP Extension to LIC,” ITU-TSG 16 WP 3 and ISO / IEC JTC 1 / SC 29 Joint Video Experts Group (JVET), 33rd Meeting (telephone), January 17-26, 2024 (hereafter referred to as “JVET-AG0136”).

[0122] The behavior of the current block is highly correlated with that of its neighboring blocks, and the mode selections may be similar or identical. Some example ECM techniques and traditional video codecs can incorporate intra-frame parameters (e.g., block vector (BV), intra-prediction index, etc.) from adjacent intra-decoded blocks into the current decoded block.

[0123] Current versions of ECM employ numerous intra-frame decoding tools, such as intraTMP, DIMD, TIMD, and TMRL. These intra-frame decoding tools can use more than one intra-frame parameter to reconstruct predictions. For example, DIMD and TIMD have more than one intra-frame prediction mode index and weighting factor, TMRL has a set of intra-frame prediction mode indexes and multiple reference line indices, and intraTMP fusion has more than one BV and weighting factor, etc. However, ECM does not allow merging all intra-frame data from adjacent blocks into the current decoding block. This disclosure describes techniques for merging some or all intra-frame data from selected adjacent blocks. In this way, intra-frame prediction can be performed more efficiently when many different possible intra-frame prediction modes are available.

[0124] Example

[0125] In some examples, intra-frame decoding tools can use at least two parameters (e.g., mode index, weighting factor, etc.) to derive the predictor. The mode index indicates which intra-frame angle modes or block vectors (BVs) are used. The weighting factor indicates how different predictors are combined with corresponding weighting factors for fusion. In one example, video encoder 200 and video decoder 300 can be configured to merge some or all of the intra-frame data (e.g., two or more intra-frame prediction parameters) used in selected intra-frame decoding neighboring blocks related to the current decoding block. Video encoder 200 and video decoder 300 can reuse the merged intra-frame data (e.g., intra-frame decoding modes and associated parameters of the intra-frame decoding modes) and perform the same intra-frame prediction reconstruction process used in the selected neighboring blocks. The following example illustrates the intra-frame data that can be reused in the current block:

[0126] (1) If adjacent blocks are decoded using DIMD mode, the merged data may include an intra-prediction mode index, a weighting factor, and a position-dependent index derived via DIMD. Different merged datasets may be applied to this example of the present disclosure. For example, the merged data may include an intra-prediction mode index and a weighting factor derived via DIMD (e.g., without a position-dependent index).

[0127] (2) If adjacent blocks are decoded using TIMD mode, the merged data may include intra-prediction mode indexes derived via TIMD and weighting factors. Different merged datasets may be applied to this example of the disclosure.

[0128] (3) If adjacent blocks are decoded using the intraTMP fusion mode, the merged data may include BV, weighting factors, and LIC parameters derived through the intraTMP search process. Different merged datasets may be applied to this example of the disclosure. For example, the merged data may include BV and weighting factors derived through the intraTMP search process (e.g., without LIC parameters).

[0129] (4) If adjacent blocks are decoded using the intraTMP linear filter model, the merged data may include the BV set derived through the intraTMP search process and the weighting factor. Different merged datasets may be applied to this example of the disclosure.

[0130] (5) If adjacent blocks are decoded using the intraTMP interpolation filter, the merged data may include the BV set derived through the intraTMP search process and the direction index. Different merged datasets may be applied to this example of the disclosure.

[0131] (6) If adjacent blocks are decoded using TMRL, the merged data may include a set of intra-prediction mode indexes and multiple reference line indices. Different merged datasets may be applied to this example of the disclosure.

[0132] Video encoder 200 may encode (or video decoder 300 may decode) a syntax element to signal the use of an intra-merge mode. In one instance, the syntax element may correspond to an intra-merge flag to indicate whether an intra-merge mode is enabled. If the flag is true, a candidate list is constructed, where each candidate stores intra-frame data used in checked neighboring blocks. Checked neighboring blocks are blocks around the current block that have been decoded or reconstructed. In another example, before signaling the intra-merge flag, video encoder 200 may signal (or video decoder 300 may decode) a general derivation flag to indicate whether the modes in the current CU include modes derivation from neighboring blocks, such as DIMD, OBIC, and proposed intra-merge modes. If the general derivation flag is true, several sub-derivation flags (such as the OBIC flag and the internal merge flag) may be further signaled to indicate which intra-merge mode to use.

[0133] Figure 12 An example of checked neighboring blocks 1210 is shown, which includes adjacent blocks (e.g., directly adjacent to the center block) and non-adjacent blocks (e.g., numbered squares, circles, and rhombuses), and the checking order is predefined. Neighboring blocks are checked until the list is full. The list size is a pre-allocated positive number.

[0134] In another example, a candidate list is constructed from a historical candidate list. The historical candidate list has a fixed size and follows a first-in-first-out (FIFO) storage procedure to store intra-frame data from the current decoded block. The video encoder 200 and video decoder 300 can remove candidates initially stored in the current historical candidate list. In another example, the process can add derived candidates to the list. Derived candidates are derived from existing candidates. For example, intra-prediction mode indices and weighting factors are derived from existing DIMD candidates in the list by recalculating the occurrence counts of intra-prediction modes.

[0135] Candidate comparison is applied during list construction to check if a candidate is identical to one of the existing candidates in the list. If it is not identical to any existing candidate, it is added to the list.

[0136] In one example, the decoding process adds candidates from neighboring blocks decoded using different types of intra-decoding modes (such as DIMD, TIMD, intraTMP fusion, etc.) to a list. In another example, there are several candidate lists, each constructed from an intra-decoding mode (or a set of intra-decoding modes). One or more flags can be signaled to indicate which candidate list the current decoding block uses. For example, there could be two candidate lists, one constructed from DIMD-decoded neighboring blocks and the other from intraTMP-fused decoded neighboring blocks. Flags can be signaled to indicate which list the current decoding block uses.

[0137] In one example, the candidates selected during the decoding process are adjacent blocks decoded through different modes but sharing the same reconstruction process. For example, candidates can be constructed using DIMD and TIMD modes. Both types of candidates can share the DIMD reconstruction process to generate the predictor. TIMD1 and TIMD2 can be restricted to non-angular intra-frame modes to suit the DIMD fusion reconstruction process, where the first few modes are non-angular modes and the last mode is a planar mode.

[0138] In one example, the decoding process restricts the proposed list to candidates storing intra-frame data from neighboring blocks decoded by intra-frame fusion tools such as DIMD fusion, TIMD fusion, intraTMP fusion, and the intraTMP linear filter model. Each candidate stores at least two parameters from the intra-frame data of neighboring blocks. In another example, the list may include candidates storing at least two parameters of the intra-frame data, and candidates storing only one parameter.

[0139] In one example, the intra-frame prediction data merging mode proposed in this disclosure is constrained by the CU size. For example, if the CU area is smaller than a pre-assigned positive value, the mode flag is bypassed. In another example, the proposed list size depends on the CU size. For example, given several pre-assigned positive values, a larger list size is set if the CU area is large, and a smaller list size is set if the CU area is small.

[0140] In another example of this disclosure, the video encoder 200 and video decoder 300 may be configured to reorder the proposed list according to template cost. In one example, the template may include adjacent blocks that are adjacent to the current chroma CU. In another example, the template may include other adjacent blocks that are not adjacent to the current chroma CU. Figure 13 Templates B 1310 and C 1320 shown are examples of templates. The template width can be 1 pixel. In another example, the width can be greater than 1 pixel.

[0141] In one example, template cost is calculated by summing the absolute values ​​of the differences between the reconstructed samples in the template and the predicted values ​​generated by the evaluated intra-frame mode. In some other examples, template cost can be calculated using other measures, such as SATD cost, mean squared error, etc.

[0142] In another example of this disclosure, the video encoder 200 and video decoder 300 may be configured to bypass Multi-Transform Selection (MTS) indexing signaling if the intra-frame merge flag is true. More specifically, if the intra-frame merge flag is true, the video decoder 300 may derive the transform type using inference (e.g., based on other video decoding characteristics) without signaling. For example, if the intra-frame merge flag is true, the video decoder 300 may derive the transform type based on the transform block size. An example of this method is that if the transform block is greater than a first predefined value or if the transform block is less than a second predefined value, the horizontal transform type is derived as a first transform type, where the first predefined value is greater than the second predefined value. If the transform block is less than or equal to the first predefined value and if the transform block is greater than or equal to the second predefined value, the horizontal transform type is derived as a second transform type. The same example can be applied to the vertical transform type. The first and second transform types may be DCT2, DST7, etc.

[0143] Example video encoder and decoder

[0144] Figure 14 This is a block diagram illustrating an example video encoder 200 that can perform the techniques of this disclosure. Figure 14This disclosure is provided for illustrative purposes and should not be construed as limiting the techniques extensively illustrated and described herein. For illustrative purposes, this disclosure describes the video encoder 200 in accordance with VVC and HEVC techniques. However, the techniques of this disclosure can be performed by video encoding devices configured for other video decoding standards and video decoding formats, such as AV1 and subsequent formats of AV1 video decoding.

[0145] exist Figure 14 In the example, the video encoder 200 includes a video data memory 1430, a mode selection unit 1402, a residual generation unit 1404, a transform processing unit 1406, a quantization unit 1408, an inverse quantization unit 1410, an inverse transform processing unit 1412, a reconstruction unit 1414, a filter unit 1416, a decoded picture buffer (DPB) 1418, and an entropy coding unit 1420. Any or all of the video data memory 1430, mode selection unit 1402, residual generation unit 1404, transform processing unit 1406, quantization unit 1408, inverse quantization unit 1410, inverse transform processing unit 1412, reconstruction unit 1414, filter unit 1416, DPB 1418, and entropy coding unit 1420 can be implemented in one or more processors or in processing circuitry. For example, the units of the video encoder 200 can be implemented as one or more circuit or logic elements as part of hardware circuitry, or as part of a processor, ASIC, or FPGA. In addition, the video encoder 200 may include additional or alternative processors or processing circuitry to perform these and other functions.

[0146] Video data storage 1430 is an example of a storage system capable of storing video data to be encoded by components of video encoder 200. Video encoder 200 can, for example, receive data from video source 104 (…). Figure 1 The video data memory 1430 receives video data stored in the video data memory 1430. The DPB 1418 is an example of a memory system that can act as a reference picture memory, storing reference video data for use when the video encoder 200 predicts subsequent video data. The video data memory 1430 and DPB 1418 can each be formed from any of one or more various memory devices or memory cells, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The video data memory 1430 and DPB 1418 can be provided by the same memory device or separate memory devices. In various examples, the video data memory 1430 can be on-chip (as illustrated) with other components of the video encoder 200, or off-chip relative to those components.

[0147] In this disclosure, references to video data memory 1430 should not be construed as limited to memory inside video encoder 200 (unless specifically described) or memory outside video encoder 200 (unless specifically described). Rather, references to video data memory 1430 should be understood as reference memory storing video data received by video encoder 200 for encoding (e.g., video data for the current block to be encoded). Figure 1 The memory 106 can also provide temporary storage for the outputs from various units of the video encoder 200.

[0148] Figure 14 Various units are illustrated to aid in understanding the operations performed by the video encoder 200. Units can be implemented as fixed-function circuits, programmable circuits, or combinations thereof. Fixed-function circuits refer to circuits that provide specific functionality and are pre-defined for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functionality in the operations that can be performed. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. Fixed-function circuits can execute software instructions (e.g., to receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more units within the unit may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units within the unit may be integrated circuits.

[0149] The video encoder 200 may include an arithmetic logic unit (ALU), an essential function unit (EFU), digital circuitry, analog circuitry, and / or a programmable core, all formed by programmable circuitry. In an example where the operation of the video encoder 200 is performed using software executed by programmable circuitry, memory 106 ( Figure 1 The video encoder 200 may store instructions (e.g., target code) of the software received and executed by the video encoder 200, or another memory (not shown) within the video encoder 200 may store such instructions.

[0150] The video data storage unit 1430 is configured to store received video data. The video encoder 200 can retrieve images of the video data from the video data storage unit 1430 and provide the video data to the residual generation unit 1404 and the mode selection unit 1402. The video data in the video data storage unit 1430 can be the raw video data to be encoded.

[0151] The mode selection unit 1402 includes a motion estimation unit 1422, a motion compensation unit 1424, and an intra-frame prediction unit 1426. The mode selection unit 1402 may include additional functional units for performing video prediction based on other prediction modes. As an example, the mode selection unit 1402 may include a palette unit, an intra-frame block copying unit (which may be part of the motion estimation unit 1422 and / or the motion compensation unit 1424), an affine unit, a linear model (LM) unit, etc.

[0152] The mode selection unit 1402 typically coordinates multiple coding channels to test combinations of coding parameters and the resulting rate-distortion values ​​for such combinations. Coding parameters may include the CTU-CU partitioning, the prediction mode for the CU, the transformation type of the residual data for the CU, the quantization parameters of the residual data for the CU, etc. The mode selection unit 1402 can ultimately select a combination of coding parameters that has a better rate-distortion value compared to other tested combinations.

[0153] The video encoder 200 can divide images retrieved from the video data storage 1430 into a series of CTUs and encapsulate one or more CTUs within slices. The mode selection unit 1402 can divide the image's CTUs according to the tree structure described above (such as an MTT structure, a QTBT structure, a superblock structure, or the aforementioned quadtree structure). As described above, the video encoder 200 can form one or more CUs by dividing CTUs according to a tree structure. Such CUs are also commonly referred to as "video blocks" or "blocks".

[0154] Generally, the mode selection unit 1402 also controls its components (e.g., motion estimation unit 1422, motion compensation unit 1424, and intra-frame prediction unit 1426) to generate prediction blocks for the current block (e.g., the current CU, or, in HEVC, the overlapping portion of PU and TU). To perform inter-frame prediction for the current block, the motion estimation unit 1422 may perform a motion search to identify one or more closely matching reference blocks in one or more reference pictures (e.g., one or more previously decoded pictures stored in DPB 1418). Specifically, the motion estimation unit 1422 may calculate, for example, values ​​representing the similarity between a potential reference block and the current block based on sum of absolute differences (SAD), sum of squared differences (SSD), mean absolute difference (MAD), mean squared difference (MSD), etc. The motion estimation unit 1422 may typically perform these calculations using the sample-by-sample difference between the current block and the reference blocks under consideration. The motion estimation unit 1422 may identify the reference block with the lowest value produced by these calculations to indicate the reference block that best matches the current block.

[0155] Motion estimation unit 1422 can generate one or more motion vectors (MVs) that define the location of a reference block in a reference image relative to the location of the current block in the current image. Motion estimation unit 1422 can then provide the motion vectors to motion compensation unit 1424. For example, for unidirectional inter-frame prediction, motion estimation unit 1422 can provide a single motion vector, while for bidirectional inter-frame prediction, motion estimation unit 1422 can provide two motion vectors. Motion compensation unit 1424 can then use the motion vectors to generate a prediction block. For example, motion compensation unit 1424 can use the motion vectors to retrieve data for the reference block. As another example, if the motion vectors have fractional sample accuracy, motion compensation unit 1424 can interpolate the prediction block according to one or more interpolation filters. Furthermore, for bidirectional inter-frame prediction, motion compensation unit 1424 can retrieve data for two reference blocks identified by corresponding motion vectors and combine the retrieved data, for example, by per-sample averaging or weighted averaging.

[0156] When operating according to the AV1 video decoding format, the motion estimation unit 1422 and the motion compensation unit 1424 can be configured to encode the decoded blocks of video data (e.g., both luma and chroma decoded blocks) using translational motion compensation, affine motion compensation, overlap block motion compensation (OBMC), and / or composite inter-intra-frame prediction.

[0157] As another example, for intra-prediction or intra-prediction decoding, intra-prediction unit 1426 may generate a prediction block from samples adjacent to the current block. For example, for directional mode, intra-prediction unit 1426 may typically mathematically combine the values ​​of adjacent samples and fill these calculated values ​​across the current block in a defined direction to produce a prediction block. As another example, for DC mode, intra-prediction unit 1426 may calculate the average of the adjacent samples of the current block and generate a prediction block to include the resulting average for each sample of the prediction block.

[0158] When operating according to the AV1 video decoding format, the intra-prediction unit 1426 can be configured to encode decoded blocks of video data (e.g., both luma and chroma decoded blocks) using directional intra-prediction, non-directional intra-prediction, recursive filter intra-prediction, luma-chroma (CFL) prediction, intra-block copying (IBC), and / or palette modes. The mode selection unit 1402 may include additional functional units for performing video prediction according to other prediction modes.

[0159] Mode selection unit 1402 provides a prediction block to residual generation unit 1404. Residual generation unit 1404 receives an uncoded raw version of the current block from video data memory 1430 and a prediction block from mode selection unit 1402. Residual generation unit 1404 calculates the sample-by-sample difference between the current block and the prediction block. The resulting sample-by-sample difference defines the residual block for the current block. In some examples, residual generation unit 1404 may also determine the differences between sample values ​​in the residual block to generate the residual block using residual differential pulse decoding modulation (RDPCM). In some examples, residual generation unit 1404 may be formed using one or more subtractor circuits performing binary subtraction.

[0160] In the example where mode selection unit 1402 divides a CU into PUs, each PU can be associated with a luma prediction unit and a corresponding chroma prediction unit. Video encoder 200 and video decoder 300 can support PUs of various sizes. As noted above, the size of a CU can refer to the size of the luma decoding block of the CU, while the size of a PU can refer to the size of the luma prediction unit of the PU. Assuming a particular CU size is 2Nx2N, video encoder 200 can support PU sizes of 2Nx2N or NxN for intra-frame prediction, and symmetric PU sizes of 2Nx2N, 2NxN, Nx2N, NxN, or similar for inter-frame prediction. Video encoder 200 and video decoder 300 can also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N, and nRx2N for inter-frame prediction.

[0161] In an example where the mode selection unit 1402 does not further divide the CU into PUs, each CU can be associated with a luminance decoding block and a corresponding chrominance decoding block. As mentioned above, the size of the CU can refer to the size of the luminance decoding block of the CU. The video encoder 200 and the video decoder 300 can support CU sizes of 2Nx2N, 2NxN, or Nx2N.

[0162] For other video decoding techniques, such as intra-block copy mode decoding, affine mode decoding, and linear model (LM) mode decoding, as some examples, mode selection unit 1402 generates a prediction block for the current block being encoded via a corresponding unit associated with the decoding technique. In some examples (such as palette mode decoding), mode selection unit 1402 may not generate a prediction block, but instead generate syntax elements indicating how the block will be reconstructed based on a selected palette. In such modes, mode selection unit 1402 may provide these syntax elements to entropy coding unit 1420 for encoding.

[0163] As described above, the residual generation unit 1404 receives video data for the current block and the corresponding prediction block. Then, the residual generation unit 1404 generates a residual block for the current block. To generate the residual block, the residual generation unit 1404 calculates the sample-by-sample difference between the prediction block and the current block.

[0164] Transform processing unit 1406 applies one or more transformations to the residual block to generate a block of transform coefficients (referred to herein as a "transform coefficient block"). Transform processing unit 1406 may apply various transformations to the residual block to form the transform coefficient block. For example, transform processing unit 1406 may apply a discrete cosine transform (DCT), direction transform, Karhunen-Loeve transform (KLT), or conceptually similar transformations to the residual block. In some examples, transform processing unit 1406 may perform multiple transformations on the residual block, such as primary and secondary transformations (e.g., rotation transformations). In some examples, transform processing unit 1406 does not apply any transformations to the residual block.

[0165] When operating according to AV1, the transform processing unit 1406 may apply one or more transforms to the residual block to generate a block of transform coefficients (referred to herein as a "transform coefficient block"). The transform processing unit 1406 may apply various transforms to the residual block to form the transform coefficient block. For example, the transform processing unit 1406 may apply a combination of horizontal / vertical transforms, which may include the Discrete Cosine Transform (DCT), the Asymmetric Discrete Sine Transform (ADST), the Reversed ADST (e.g., ADST in reverse order), and the Identity Transform (IDTX). When using the Identity Transform, the transform is skipped in either the vertical or horizontal direction. In some examples, transform processing may be skipped entirely.

[0166] Quantization unit 1408 quantizes the transform coefficients in a transform coefficient block to produce a quantized transform coefficient block. Quantization unit 1408 quantizes the transform coefficients of the transform coefficient block according to the quantization parameter (QP) value associated with the current block. Video encoder 200 (e.g., via mode selection unit 1402) can adjust the degree of quantization applied to the transform coefficient block associated with the current block by adjusting the QP value associated with the CU. Quantization may cause information loss, and therefore, the quantized transform coefficients may have lower accuracy compared to the original transform coefficients produced by transform processing unit 1406.

[0167] The inverse quantization unit 1410 and the inverse transform processing unit 1412 can apply inverse quantization and inverse transform, respectively, to the quantized transform coefficient block to reconstruct the residual block based on the transform coefficient block. The reconstruction unit 1414 can generate a reconstructed block corresponding to the current block (although potentially with some degree of distortion) based on the reconstructed residual block and the prediction block generated by the mode selection unit 1402. For example, the reconstruction unit 1414 can add samples of the reconstructed residual block to corresponding samples of the prediction block generated by the mode selection unit 1402 to generate the reconstructed block.

[0168] Filter unit 1416 may perform one or more filtering operations on the reconstructed block. For example, filter unit 1416 may perform a deblocking operation to reduce block artifacts along the edges of the CU. In some examples, the operation of filter unit 1416 may be skipped.

[0169] When operating according to AV1, filter unit 1416 may perform one or more filtering operations on the reconstructed block. For example, filter unit 1416 may perform a deblocking operation to reduce block artifacts along the edges of the CU. In other examples, filter unit 1416 may apply a constrained direction enhancement filter (CDEF) after deblocking and may include the application of a non-separable, nonlinear, low-pass directional filter based on the estimated edge direction. Filter unit 1416 may also include a loop recovery filter applied after CDEF and may include a separable symmetric normalized Wiener filter or a dual-guided filter.

[0170] The video encoder 200 stores reconstructed blocks in the DPB 1418. For example, in an example where the operation of the filter unit 1416 is not performed, the reconstruction unit 1414 may store the reconstructed blocks in the DPB 1418. In an example where the operation of the filter unit 1416 is performed, the filter unit 1416 may store the filtered reconstructed blocks in the DPB 1418. The motion estimation unit 1422 and the motion compensation unit 1424 may retrieve a reference picture formed by the reconstructed (and potentially filtered) blocks from the DPB 1418 to perform inter-frame prediction for blocks of subsequent encoded pictures. In addition, the intra-frame prediction unit 1426 may use the reconstructed blocks of the current picture in the DPB 1418 to perform intra-frame prediction for other blocks in the current picture.

[0171] Generally, the entropy coding unit 1420 can entropy code syntax elements received from other functional components of the video encoder 200. For example, the entropy coding unit 1420 can entropy code a block of quantized transform coefficients from the quantization unit 1408. As another example, the entropy coding unit 1420 can entropy code predictive syntax elements (e.g., motion information for inter-frame prediction or intra-frame mode information for intra-frame prediction) from the mode selection unit 1402. The entropy coding unit 1420 can perform one or more entropy coding operations on the syntax elements (another example of video data) to generate entropy-coded data. For example, the entropy coding unit 1420 can perform context-adaptive variable-length decoding (CAVLC), CABAC, variable-to-variable (V2V) length decoding, syntax-based context-adaptive binary arithmetic decoding (SBAC), probability interval partitioning entropy (PIPE) decoding, exponential Golomb coding, or another type of entropy coding operation on the data. In some examples, the entropy coding unit 1420 can operate in a bypass mode where syntax elements are not entropy encoded.

[0172] The video encoder 200 can output a bitstream containing entropy-coded syntax elements required to reconstruct slices or blocks of images. Specifically, the entropy coding unit 1420 can output a bitstream.

[0173] According to AV1, the entropy coding unit 1420 can be configured as a symbol-to-symbol adaptive multi-symbol arithmetic decoder. The syntax elements in AV1 consist of an N-element alphabet, and the context (e.g., a probability model) consists of a set of N probabilities. The entropy coding unit 1420 can store the probabilities as an n-bit (e.g., 15-bit) cumulative distribution function (CDF). The entropy coding unit 1420 can perform recursive scaling to update the context using an update factor based on the alphabet size.

[0174] The operations described above are relative to blocks. This description should be understood as operations applied to luma decoding blocks and / or chroma decoding blocks. As described above, in some examples, the luma decoding block and chroma decoding block are the luma and chroma components of the CU. In some examples, the luma decoding block and chroma decoding block are the luma and chroma components of the PU.

[0175] In some examples, it is not necessary to repeat the operations performed relative to the luma decoder for the chroma decoder block. As an example, the operations for identifying the motion vector (MV) and reference image of the luma decoder block do not need to repeat the MV and reference image used to identify the chroma block. Instead, the MV used for the luma decoder block can be scaled to determine the MV used for the chroma block, and the reference image can be the same. As another example, the intra-frame prediction process can be the same for both the luma and chroma decoders.

[0176] Video encoder 200 represents an example of a device configured to encode video data, the device including a memory and one or more processing units. The memory is configured to store video data, and the one or more processing units are implemented in circuitry and configured to: determine a decoding mode of one or more adjacent intra-decoding blocks from the current block based on an intra-merging mode, wherein at least a first decoding mode from the first adjacent block includes two or more parameters; generate a merge candidate list based on the intra-merging mode, the merge candidate list including decoding modes from one or more adjacent intra-decoding blocks, the merge candidate list storing two or more parameters of the first decoding mode from the first adjacent block; select a first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and two or more parameters.

[0177] Figure 15 This is a block diagram illustrating an example video decoder 300 that can perform the techniques of this disclosure. Figure 15 This disclosure is provided for illustrative purposes and is not intended to limit the techniques extensively illustrated and described herein. For illustrative purposes, the video decoder 300 is described in accordance with VVC and HEVC techniques. However, the techniques of this disclosure may be implemented by video decoding devices configured for other video decoding standards.

[0178] exist Figure 15 In the example, the video decoder 300 includes a decoded picture buffer (CPB) memory 1520, an entropy decoding unit 1502, a prediction processing unit 1504, an inverse quantization unit 1506, an inverse transform processing unit 1508, a reconstruction unit 1510, a filter unit 1512, and a DPB 1514. Any or all of the CPB memory 1520, entropy decoding unit 1502, prediction processing unit 1504, inverse quantization unit 1506, inverse transform processing unit 1508, reconstruction unit 1510, filter unit 1512, and DPB 1514 can be implemented in one or more processors or in processing circuitry. For example, the units of the video decoder 300 can be implemented as one or more circuit or logic elements as part of hardware circuitry, or as part of a processor, ASIC, or FPGA. Furthermore, the video decoder 300 may include additional or alternative processors or processing circuitry to perform these and other functions.

[0179] The prediction processing unit 1504 includes a motion compensation unit 1516 and an intra-prediction unit 1518. The prediction processing unit 1504 may include additional units that perform predictions based on other prediction modes. As an example, the prediction processing unit 1504 may include a palette unit, an intra-block copying unit (which may form part of the motion compensation unit 1516), an affine unit, a linear model (LM) unit, etc. In other examples, the video decoder 300 may include more, fewer, or different functional components.

[0180] When operating according to AV1, motion compensation unit 1516 can be configured to decode video data blocks (e.g., both luma and chroma blocks) using translational motion compensation, affine motion compensation, OBMC, and / or composite inter-intra-frame prediction, as described above. Intra-frame prediction unit 1518 can be configured to decode video data blocks (e.g., both luma and chroma blocks) using directional intra-frame prediction, non-directional intra-frame prediction, recursive filter intra-frame prediction, CFL, IBC, and / or palette mode, as described above.

[0181] CPB memory 1520 is an example of a memory system capable of storing video data (such as encoded video bitstreams) to be decoded by components of video decoder 300. For example, it can be stored from computer-readable medium 110 ( Figure 1 The video data stored in the CPB memory 1520 is obtained. The CPB memory 1520 may include a CPB that stores encoded video data (e.g., syntax elements) from the encoded video bitstream. Furthermore, the CPB memory 1520 may store video data other than the syntax elements of the decoded picture, such as temporary data representing the output from various units of the video decoder 300. The DPB 1514 is an example of a memory system that typically stores decoded pictures, which the video decoder 300 can output, and / or uses as reference video data when decoding subsequent data or pictures of the encoded video bitstream. The CPB memory 1520 and the DPB 1514 may each be formed from any of various memory devices or memory cells, such as DRAM (including SDRAM), MRAM, RRAM, or other types of memory devices. The CPB memory 1520 and the DPB 1514 may be provided by the same memory device or separate memory devices. In various examples, the CPB memory 1520 may be on-chip along with other components of the video decoder 300, or off-chip relative to those components.

[0182] Additionally or alternatively, in some examples, the video decoder 300 may be from the memory 120 ( Figure 1The decoded video data can be retrieved from the memory. That is, the memory 120 can utilize the CPB memory 1520 to store data, as discussed above. Similarly, when some or all of the functionality of the video decoder 300 is implemented in software to be executed by the processing circuitry of the video decoder 300, the memory 120 can store instructions to be executed by the video decoder 300.

[0183] Figure 15 The various units are illustrated to aid in understanding the operations performed by the video decoder 300. These units can be implemented as fixed-function circuits, programmable circuits, or combinations thereof. Similar to... Figure 14 Fixed-function circuits are circuits that provide specific functionality and are pre-defined for the operations they can perform. Programmable circuits are circuits that can be programmed to perform various tasks and provide flexible functionality for the operations they can perform. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. Fixed-function circuits can execute software instructions (e.g., to receive or output parameters), but the type of operation performed by a fixed-function circuit is typically immutable. In some examples, one or more units in a cell may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units in a cell may be integrated circuits.

[0184] The video decoder 300 may include an ALU, EFU, digital circuitry, analog circuitry, and / or a programmable core formed by programmable circuitry. In an example where the operation of the video decoder 300 is performed by software executed on programmable circuitry, on-chip or off-chip memory may store instructions (e.g., object code) of the software received and executed by the video decoder 300.

[0185] The entropy decoding unit 1502 can receive encoded video data from the CPB and perform entropy decoding on the video data to reproduce the syntax elements. The prediction processing unit 1504, the inverse quantization unit 1506, the inverse transform processing unit 1508, the reconstruction unit 1510, and the filter unit 1512 can generate decoded video data based on the syntax elements extracted from the bitstream.

[0186] Generally speaking, the video decoder 300 reconstructs the image block by block. The video decoder 300 can perform the reconstruction operation on each block individually (where the block currently being reconstructed (i.e., decoded) can be referred to as the "current block").

[0187] Entropy decoding unit 1502 can entropy decode the syntax elements of the quantized transform coefficients defining the quantized transform coefficient block, as well as transform information (such as quantization parameters (QP) and / or transform mode indications). Inverse quantization unit 1506 can use the QP associated with the quantized transform coefficient block to determine the degree of quantization, and similarly, determine the degree of inverse quantization to be applied by inverse quantization unit 1506. Inverse quantization unit 1506 can, for example, perform a bit-by-bit left shift operation to inverse quantize the quantized transform coefficients. Inverse quantization unit 1506 can thereby form a transform coefficient block including the transform coefficients.

[0188] After the inverse quantization unit 1506 forms the transform coefficient block, the inverse transform processing unit 1508 may apply one or more inverse transforms to the transform coefficient block to generate a residual block associated with the current block. For example, the inverse transform processing unit 1508 may apply an inverse DCT, an inverse integer transform, an inverse Karhunen-Loeve transform (KLT), an inverse rotation transform, an inverse direction transform, or another inverse transform to the transform coefficient block.

[0189] Furthermore, the prediction processing unit 1504 generates a prediction block based on the prediction information syntax elements entropy decoded by the entropy decoding unit 1502. For example, if the prediction information syntax elements indicate that the current block is an inter-frame prediction, the motion compensation unit 1516 can generate the prediction block. In this case, the prediction information syntax elements may indicate a reference picture in the DPB 1514 from which the reference block is to be retrieved, and a motion vector identifying the position of the reference block in the reference picture relative to the position of the current block in the current picture. The motion compensation unit 1516 may generally follow the same procedure as relative to the motion compensation unit 224 ( Figure 14 The method described is essentially the same as the method used to perform the inter-frame prediction process.

[0190] As another example, when the prediction information syntax element indicates that the current block is intra-predictive, the intra-predictive unit 1518 may generate a prediction block according to the intra-predictive mode indicated by the prediction information syntax element. Similarly, the intra-predictive unit 1518 may generally follow the same procedure as relative to the intra-predictive unit 226 ( Figure 14 The intra-prediction process is performed in a manner substantially similar to that described above. The intra-prediction unit 1518 can retrieve data of neighboring samples of the current block from the DB 1514.

[0191] Reconstruction unit 1510 can use prediction blocks and residual blocks to reconstruct the current block. For example, reconstruction unit 1510 can add samples from the residual block to the corresponding samples from the prediction block to reconstruct the current block.

[0192] Filter unit 1512 may perform one or more filtering operations on the reconstructed block. For example, filter unit 1512 may perform a deblocking operation to reduce block artifacts along the edges of the reconstructed block. The operation of filter unit 1512 may not be performed in all examples.

[0193] The video decoder 300 can store reconstructed blocks in the DPB 1514. For example, in an example where the operation of the filter unit 1512 is not performed, the reconstruction unit 1510 can store the reconstructed blocks in the DPB 1514. In an example where the operation of the filter unit 1512 is performed, the filter unit 1512 can store the filtered reconstructed blocks in the DPB 1514. As discussed above, the DPB 1514 can provide reference information (such as samples of the current image for intra-frame prediction and previously decoded images for subsequent motion compensation) to the prediction processing unit 1504. Furthermore, the video decoder 300 can output decoded images (e.g., decoded video) from the DPB 1514 for subsequent rendering in applications such as... Figure 1 Display devices such as 118.

[0194] In this manner, video decoder 300 represents an example of a video decoding device including a memory and one or more processing units. The memory is configured to store video data, and the one or more processing units are implemented in circuitry and configured to: determine a decoding mode of one or more adjacent intra-decoding blocks from the current block based on an intra-frame merging mode, wherein at least a first decoding mode from the first adjacent block includes two or more parameters; generate a merge candidate list based on the intra-frame merging mode, the merge candidate list including decoding modes from one or more adjacent intra-decoding blocks, the merge candidate list storing two or more parameters of the first decoding mode from the first adjacent block; select a first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0195] Example decoding method

[0196] Figure 16 This is a flowchart illustrating an example method for encoding the current block according to the technology of this disclosure. The current block may be or may include the current CU. Although relative to the video encoder 200 ( Figure 1 and Figure 14 This description is provided, but it should be understood that other devices can be configured to perform similar actions. Figure 16 Similar to the method.

[0197] In this example, the video encoder 200 initially predicts the current block (1600). For example, the video encoder 200 may form a prediction block for the current block. The video encoder 200 may then compute a residual block for the current block (1602). To compute the residual block, the video encoder 200 may compute the difference between the unencoded original block for the current block and the prediction block. The video encoder 200 may then transform the residual block and quantize the transform coefficients of the residual block (1604). Next, the video encoder 200 may scan the quantized transform coefficients of the residual block (1606). During or after the scan, the video encoder 200 may entropy encode the transform coefficients (1608). For example, the video encoder 200 may use CAVLC or CABAC to encode the transform coefficients. The video encoder 200 may then output the entropy-encoded data of the block (1610).

[0198] Figure 17 This is a flowchart illustrating an example method for decoding a current block of video data according to the technology of this disclosure. The current block may be or may include the current CU. Although relative to the video decoder 300 ( Figure 1 and Figure 15 This description is provided, but it should be understood that other devices can be configured to perform similar actions. Figure 17 Similar to the method.

[0199] The video decoder 300 may receive entropy-coded data of the current block, such as entropy-coded prediction information and entropy-coded data for the transform coefficients of the residual block corresponding to the current block (1700). The video decoder 300 may entropy decode the entropy-coded data to determine the prediction information for the current block and reproduce the transform coefficients of the residual block (1702). The video decoder 300 may, for example, use an intra-frame prediction mode or inter-frame prediction mode indicated by the prediction information of the current block to predict the current block (1704) to compute a prediction block for the current block. The video decoder 300 may then inverse scan the reproduced transform coefficients (1706) to create a block of quantized transform coefficients. The video decoder 300 may then inverse quantize the transform coefficients and apply an inverse transform to the transform coefficients to produce a residual block (1708). The video decoder 300 may finally decode the current block by combining the prediction block and the residual block (1710).

[0200] Figure 18 This is a flowchart illustrating an example method 1800 for decoding a current block of video data according to the technology of this disclosure. The current block may be or may include the current CU. Aspects may be... Figure 1 and Figure 14 The video encoder 200 and the video encoder 200 made by Figure 1 and Figure 15The video decoder 300 performs these aspects. More specifically, aspects can be performed by the intra-frame prediction unit 1426 of the video encoder 200 and the intra-frame prediction unit 1518 of the video decoder 300. Although the disclosed aspects can be performed by the video encoder 200 and the video decoder 300, other devices can be configured to perform them in conjunction with... Figure 18 Similar to the method.

[0201] Example method 1800 begins at box 1802, which decodes a syntax element that indicates the intra-frame merge mode for the current block. According to one aspect, the syntax element may correspond to a flag that can be set when intra-frame merge mode is to be used, and not set when intra-frame merge mode is not used. Regardless of the specific implementation, a syntax element can be used to activate the intra-frame merge mode for the current block.

[0202] Example method 1800 continues at box 1804, which determines the decoding mode of the adjacent intra-frame decoding blocks from the current block. For example, Figure 12 The example illustrates a block surrounded by adjacent blocks on either side, where small squares correspond to intra-frame data including the decoding mode. According to one aspect, the first decoding mode may utilize two or more parameters.

[0203] Example method 1800 continues at box 1806 by generating a merge candidate list that includes decoding modes from adjacent intra-decoding blocks of the current block, the current block including decoding modes with multiple parameters. According to one aspect, the merge candidate list may include multiple types of intra-prediction modes. Furthermore, multiple merge candidate lists can be generated for each type of intra-prediction mode, such that additional indexes, etc., are passed to identify a specific merge candidate list.

[0204] Example method 1800 continues at box 1808, namely, reordering the merge candidate list. According to one aspect, a template cost can be calculated for each decoding mode in the merge candidate list. The template cost can be a measure of how well the decoded mode's predicted value matches the reconstructed video sample. The merge candidate list can be reordered based on cost, for example, placing decoding modes with lower costs (e.g., providing better predictions) higher or closer to the beginning of the merge candidate list. This reordering allows for a more optimal selection of the decoding mode for the current video block and helps ensure that the "best" decoding mode based on template cost is more likely to be selected for final decoding. Therefore, overall decoding efficiency and video quality are improved.

[0205] Next, example method 1800 proceeds to box 1810, where a decoding mode is selected from the reordered merge candidate list. For example, a first decoding mode may be selected. Selection may be based on the encoder's template cost, etc. According to one aspect, the encoder may encode and send the index corresponding to the selected decoding mode from the reordered merge candidate list. The decoder may generate the reordered merge candidate list, decode the index, and use the index to select the decoding mode.

[0206] Next, example method 1800 continues at box 1812, which decodes the current block using the selected decoding mode. In one instance, this decoding may correspond to either encoding or decoding the current block.

[0207] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a computer-readable medium or transmitted via a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium (which corresponds to a tangible medium such as a data storage medium) or a communication medium, including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may include computer-readable media.

[0208] By way of example, and not limitation, such computer-readable storage media may include one or more of RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology (such as infrared, radio, and microwave) is included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to non-transient tangible storage media. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs use lasers to reproduce data optically. Combinations of these should also be included within the scope of computer-readable media.

[0209] Instructions can be executed by one or more processors, such as one or more DSPs, general-purpose microprocessors, ASICs, FPGAs, or other equivalent integrated or discrete logic circuits. Therefore, the terms "processor" and "processing circuit" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into combined codecs. Furthermore, these techniques can be fully implemented in one or more circuit or logic elements.

[0210] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or IC sets (e.g., chip sets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but implementation by different hardware units is not necessarily required. Rather, as described above, various units can be combined in a codec hardware unit, or various units can be provided by a collection of interoperable hardware units (including one or more processors as described above) combined with appropriate software and / or firmware.

[0211] Example Terms

[0212] Specific implementation examples are described in the following numbered clauses:

[0213] Clause 1: A method for decoding video data, the method comprising: determining, based on an intra-frame merging mode, a decoding mode of one or more adjacent intra-frame decoded blocks from a current block, wherein at least a first decoding mode of the decoding modes from a first adjacent block includes two or more parameters; generating a merge candidate list based on the intra-frame merging mode, the merge candidate list including the decoding modes from the one or more adjacent intra-frame decoded blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; selecting the first decoding mode from the merge candidate list; and decoding the current block using the first decoding mode and the two or more parameters.

[0214] Clause 2: The method according to Clause 1, wherein the first decoding mode is a decoder-side intra-mode derivation (DIMD), and wherein the two or more parameters include two or more of an intra-prediction mode index, a weighting factor, or a position-dependent index derived using DIMD.

[0215] Clause 3: The method according to Clauses 1 to 2, wherein the first decoding mode is an intra-template matching (intraTMP) fusion mode, and wherein the two or more parameters include two or more of a block vector, a weighting factor, or a local illumination compensation (LIC) factor derived using the intraTMP search procedure.

[0216] Clause 4: The method according to Clauses 1 to 3, wherein the first decoding mode is an intra-template matching (intraTMP) linear filter model, and wherein the two or more parameters include two or more of a set of block vectors or weighting factors derived using the intraTMP search procedure.

[0217] Clause 5: The method according to Clauses 1 to 4, wherein the first decoding mode is an intra-template matching (intraTMP) interpolation filter, and wherein the two or more parameters include two or more of a set of block vectors derived using the intraTMP search procedure, pixel precision, or orientation index.

[0218] Clause 6: The method according to Clauses 1 to 5, wherein the first decoding mode is a template-based multi-reference line prediction (TMRL) mode, and wherein the two or more parameters include a set of intra-frame prediction mode indexes or two or more of a plurality of reference line indices.

[0219] Clause 7: The method according to Clauses 1 to 6, wherein the decoding modes in the merged candidate list include multiple types of intra-frame prediction modes.

[0220] Clause 8: The method according to Clauses 1 to 7, wherein generating the merge candidate list including the decoding mode based on the intra-frame merging mode comprises: generating a first merge candidate list for an intra-frame prediction mode of a first type; and generating a second merge candidate list for an intra-frame prediction mode of a second type.

[0221] Clause 9: The method according to Clauses 1 to 8 further includes: reordering the decoding patterns in the merged candidate list based on template cost.

[0222] Clause 10: The method according to Clauses 1 to 9, wherein decoding the current block using the first decoding mode comprises: encoding the current block using the first decoding mode.

[0223] Clause 11: The method according to Clauses 1 to 10, wherein decoding the current block using the first decoding mode comprises: decoding the current block using the first decoding mode.

[0224] Clause 12: The method according to Clauses 1 to 11 further comprises: decoding a syntax element that indicates an intra-frame merging mode for the current block.

[0225] Clause 13: The method according to Clauses 1 to 12 further includes: determining the transform type of the current block based on the transform block size based on the syntax element indicating the use of the intra-frame merging mode.

[0226] Clause 14: An apparatus configured to decode video data, the apparatus comprising: one or more memories; and processing circuitry communicating with the one or more memories, the processing circuitry being configured to: determine, based on an intra-frame merging mode, a decoding mode of one or more adjacent intra-frame decoded blocks from a current block, wherein a first decoding mode of the decoding modes from a first adjacent block includes two or more parameters; generate a merge candidate list based on the intra-frame merging mode, the merge candidate list including the decoding modes from the one or more adjacent intra-frame decoded blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; select the first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0227] Clause 15: The apparatus according to Clause 14, wherein the processing circuitry is configured to decode a syntax element that indicates the intra-frame merging mode for the current block.

[0228] Clause 16: The apparatus according to Clauses 14 to 15, wherein the decoding modes in the merged candidate list include multiple types of intra-frame prediction modes.

[0229] Clause 17: The apparatus according to Clauses 14 to 16, wherein generating the merge candidate list including the decoding mode based on the intra-frame merging mode comprises: generating a first merge candidate list for an intra-frame prediction mode of a first type; and generating a second merge candidate list for an intra-frame prediction mode of a second type.

[0230] Clause 18: The apparatus according to Clauses 14 to 17, wherein decoding the current block using the first decoding mode comprises: encoding the current block using the decoding mode.

[0231] Clause 19: The apparatus according to claims 14 to 17, wherein decoding the current block using the first decoding mode comprises: decoding the current block using the first decoding mode.

[0232] Clause 20: A non-transitory computer-readable storage medium having instructions thereon, which, when executed, cause one or more processors to: determine, based on an intra-frame merging mode, a decoding mode of one or more adjacent intra-frame decoded blocks from a current block, wherein at least a first decoding mode of the decoding modes includes two or more parameters; generate a merge candidate list based on the intra-frame merging mode, the merge candidate list including the decoding modes from the one or more adjacent intra-frame decoded blocks, the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; select the first decoding mode from the merge candidate list; and decode the current block using the first decoding mode and the two or more parameters.

[0233] Clause 21: An apparatus comprising: one or more memories; and processing circuitry communicating with the one or more memories, the processing circuitry being configured to perform a method according to any one of Clauses 1 to 20.

[0234] Clause 22: A processing system comprising: a memory including computer-executable instructions; and a processor configured to execute the computer-executable instructions and cause the processing system to perform a method according to any one of Clauses 1 to 20.

[0235] Clause 23: A processing system comprising components for performing the method according to any one of Clauses 1 to 20.

[0236] Clause 24: A non-transitory computer-readable medium storing program code for causing a processing system to perform the steps according to any one of Clauses 1 to 20.

[0237] Clause 25: A computer program product embodied on a computer-readable storage medium, said computer-readable storage medium including code for performing the method according to any one of Clauses 1 to 20.

[0238] Additional Notes

[0239] The foregoing description is provided to enable those skilled in the art to practice the various embodiments described herein. The examples discussed herein are not intended to limit the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments. For example, the function and arrangement of the elements discussed may be changed without departing from the scope of this disclosure. Various processes or components may be omitted, substituted, or added as appropriate in the various examples. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Furthermore, features described in some examples may be combined in others. For example, any number of aspects set forth herein may be used to implement an apparatus or practice. Moreover, the scope of this disclosure is intended to cover such apparatuses or methods practiced using other structures, functionalities, or structures and functionalities that complement or replace the various aspects of this disclosure set forth herein. It should be understood that any aspect of the disclosure herein may be embodied by one or more elements of the claims.

[0240] As used in this article, the phrase “at least one of” in a list of items refers to any combination of those items, including a single member. As an example, “at least one of a, b, or c” is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0241] As used herein, the term "determine" encompasses a wide variety of actions. For example, "determine" can include calculation, computation, processing, derivation, research, searching (e.g., searching in a table, database, or other data structure), assertion, etc. Additionally, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Furthermore, "determine" can include parsing, selecting, picking, building, etc.

[0242] The methods disclosed herein include one or more steps or actions for implementing the methods. The steps and / or actions of the methods may be interchanged without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of a particular step and / or action may be modified without departing from the scope of the claims. Furthermore, the various operations of the methods described above may be performed by any suitable component capable of performing the corresponding function. This component may include various hardware and / or software components and / or modules, including but not limited to circuits, application-specific integrated circuits (ASICs), or processors. Generally, where the operations illustrated in the figures are present, those operations may have corresponding components with similar numbering plus functional components.

[0243] The following claims are not intended to be limited to the embodiments shown herein, but should be granted the full scope consistent with the language of the claims. Within the claims, unless specifically stated otherwise, reference to elements in the singular form is not intended to mean “one and only one,” but rather “one or more.” Unless specifically stated otherwise, the term “some” means one or more. No element of any claim should be construed in accordance with 35 USC §112(f) unless it is expressly referred to herein by the phrase “for a component of,” or, in the case of a method claim, by the phrase “for a step of.” All structural and functional equivalents of elements throughout the various aspects described herein that are known to a person of ordinary skill in the art, or will later be known, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly stated in the claims.

Claims

1. A method for decoding video data, the method comprising: The decoding modes of one or more adjacent intra-decoding blocks from the current block are determined based on the intra-frame merging mode, wherein at least one of the decoding modes from the first adjacent block includes two or more parameters. A merge candidate list is generated based on the intra-frame merging mode, the merge candidate list including the decoding modes from the one or more adjacent intra-frame decoding blocks, and the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; Select the first decoding mode from the merge candidate list; as well as The current block is decoded using the first decoding mode and the two or more parameters.

2. The method of claim 1, wherein the first decoding mode is decoder-side intra-mode derivation (DIMD), and wherein the two or more parameters include two or more of an intra-prediction mode index, a weighting factor, or a position-dependent index derived using DIMD.

3. The method of claim 1, wherein the first decoding mode is an intra-template matching (intraTMP) fusion mode, and wherein the two or more parameters include two or more of a block vector, a weighting factor, or a local illumination compensation (LIC) factor derived using the intraTMP search procedure.

4. The method of claim 1, wherein the first decoding mode is an intra-template matching (intraTMP) linear filter model, and wherein the two or more parameters include two or more of a set of block vectors or weighting factors derived using the intraTMP search procedure.

5. The method of claim 1, wherein the first decoding mode is an intra-template matching (intraTMP) interpolation filter, and wherein the two or more parameters include two or more of a set of block vectors derived using the intraTMP search procedure, pixel precision, or orientation index.

6. The method of claim 1, wherein the first decoding mode is a template-based multi-reference line prediction (TMRL) mode, and wherein the two or more parameters include a set of intra-frame prediction mode indices or a plurality of reference line indices, both or more.

7. The method of claim 1, wherein the decoding modes in the merged candidate list include multiple types of intra-frame prediction modes.

8. The method of claim 1, wherein generating the candidate list of merges including the decoding mode based on the intra-frame merging mode comprises: Generate a first merge candidate list for the first type of intra-frame prediction mode; as well as Generate a second merge candidate list for the second type of intra-frame prediction mode.

9. The method according to claim 1, further comprising: The decoding patterns in the merge candidate list are reordered based on template cost.

10. The method of claim 1, wherein decoding the current block using the first decoding mode comprises: The current block is encoded using the first decoding mode.

11. The method of claim 1, wherein decoding the current block using the first decoding mode comprises: The current block is decoded using the first decoding mode.

12. The method according to claim 1, further comprising: The syntax element is decoded, which indicates the intra-frame merging mode for the current block.

13. The method according to claim 12, further comprising: The transform type of the current block is determined based on the transform block size, according to the syntax element indicating the use of the intra-frame merging mode.

14. An apparatus configured to decode video data, the apparatus comprising: One or more memory units; Processing circuitry, which communicates with the one or more memories, is configured to: The decoding mode of one or more adjacent intra-decoding blocks from the current block is determined based on the intra-frame merging mode, wherein the first decoding mode in the decoding mode from the first adjacent block includes two or more parameters; A merge candidate list is generated based on the intra-frame merging mode, the merge candidate list including the decoding modes from the one or more adjacent intra-frame decoding blocks, and the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; Select the first decoding mode from the merge candidate list; as well as The current block is decoded using the first decoding mode and the two or more parameters.

15. The apparatus of claim 14, wherein the processing circuitry is further configured to: decode a syntax element indicating the intra-frame merging mode for the current block.

16. The apparatus of claim 14, wherein the decoding modes in the merged candidate list include multiple types of intra-frame prediction modes.

17. The apparatus of claim 14, wherein, in order to generate the merge candidate list including the decoding mode based on the intra-frame merging mode, the processing circuitry is further configured to: Generate a first merge candidate list for the first type of intra-prediction mode; and Generate a second merge candidate list for the second type of intra-frame prediction mode.

18. An apparatus configured to encode video data, the apparatus comprising: One or more memory units; Processing circuitry, which communicates with one or more memories, is configured to: The decoding mode of one or more adjacent intra-decoding blocks from the current block is determined based on the intra-frame merging mode, wherein at least a first decoding mode in the decoding mode includes two or more parameters; A merge candidate list is generated based on the intra-frame merging mode, the merge candidate list including the decoding mode from the one or more adjacent intra-frame decoding blocks, and the merge candidate list storing the two or more parameters of the first decoding mode from the first adjacent block; Select the first decoding mode from the merge candidate list; as well as The current block is encoded using the first decoding mode and the two or more parameters.

19. The apparatus of claim 18, wherein the processing circuitry is further configured to: encode a syntax element indicating the intra-frame merging mode for the current block.

20. The apparatus of claim 18, wherein the decoding modes in the merged candidate list include multiple types of intra-frame prediction modes.

Images