Search techniques for template matching for video coding

Abstract

A video decoder may be configured to receive a block of video data encoded using a coding mode, the coding mode comprising a search process in one or more reference frames. A video decoder may prefetch reference samples in a fixed search region of at least one of one or more reference frames and decode a block of video data using a coding mode, including performing a search process of the coding mode using the prefetched reference samples.

Description

[0001] This application claims priority to U.S. Patent Application No. 18 / 365,854, filed August 4, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to video decoding, including video encoding and video decoding. Background Technology

[0003] 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 Video 1 (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.

[0004] 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 referred to as a frame, and a reference picture may be referred to as a reference frame. Summary of the Invention

[0005] Generally, this disclosure describes techniques related to decoder-side motion vector derivation (DMVD) techniques (e.g., template matching, bilateral matching, decoder-side MV thinning, bidirectional optical flow). Specifically, this disclosure describes techniques for encoding and decoding video data using DMVD techniques, which provide faster and more efficient hardware implementations.

[0006] As an example, the techniques disclosed herein may include encoding video data based on constraints on the search region allowed by the DMVD technique. By limiting the search region of the DMVD technique, a video decoder hardware implementation may be configured to prefetch reference samples within the limited search region from external memory to local memory. Prefetching reference pixels in local memory before decoding begins allows for faster and more efficient decoding, as the fetching process from external memory can be slow.

[0007] The technology disclosed herein can be applied to any video codec in existing video codecs (such as ITU-T H.265 / HEVC (High Efficiency Video Decoding), ITU-T H.266 / VVC (Multi-Functional Video Decoding), Basic Video Decoding (EVC)), in future video decoding standards, or performed by the AOMedia Video 1 (AV1) codec.

[0008] In one example, a method for decoding video data includes: receiving a block of video data encoded using a decoding mode that includes a search process in one or more reference frames; prefetching reference samples in a fixed search region of at least one of the one or more reference frames; and decoding the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0009] In another example, an apparatus configured to decode video data includes an external memory, a local memory, and one or more processors communicating with the external memory and the local memory. The one or more processors are configured to: receive a block of video data encoded using a decoding mode that includes a search process in one or more reference frames; prefetch reference samples in a fixed search region of at least one of the one or more reference frames; and decode the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0010] In another example, this disclosure describes an apparatus configured to decode video data, the apparatus comprising: means for receiving a block of video data encoded using a decoding mode including a search process in one or more reference frames; means for prefetching reference samples in a fixed search region of at least one of the one or more reference frames; and means for decoding the video data block using the decoding mode, including means for performing the search process of the decoding mode using the prefetched reference samples.

[0011] In another example, this disclosure describes a non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors configured to decode video data to receive a block of video data encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; prefetching reference samples in a fixed search region of at least one of the one or more reference frames; and decoding the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0012] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from the description, drawings, and claims. Attached Figure Description

[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 2A and Figure 2B This is a conceptual graph illustrating example space neighboring motion vector candidates used for decoding motion vectors in merge mode and Advanced Motion Vector Prediction (AMVP) mode.

[0015] Figure 3A and Figure 3B This is a conceptual diagram illustrating the time motion vector prediction technique.

[0016] Figure 4 This is a conceptual diagram illustrating template matching prediction used for motion vector decoding.

[0017] Figure 5 This is a conceptual diagram illustrating the motion vector difference (MVD) values ​​of blocks in reference images that differ in temporal distance (TD) from the current image to the current block.

[0018] Figure 6 This is a conceptual diagram illustrating an example where two MVDs are mirror images regardless of their time distance.

[0019] Figure 7 This is a conceptual diagram illustrating an example of a 3×3 square search pattern within a bilateral matching search range.

[0020] Figure 8 This is a conceptual diagram illustrating an example of refining motion vectors using decoder-side motion vector refinement (DMVR).

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

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

[0023] Figure 11 This is a block diagram illustrating an example of pixel prefetching.

[0024] Figure 12 This is a conceptual diagram illustrating the example prefetch region.

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

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

[0027] Figure 15 This is a flowchart illustrating another example method for decoding the current block according to the technology of this disclosure. Detailed Implementation

[0028] Generally, this disclosure describes techniques related to decoder-side motion vector derivation (DMVD) techniques (e.g., template matching, bilateral matching, decoder-side MV thinning, bidirectional optical flow). Specifically, this disclosure describes techniques for encoding and decoding video data using DMVD techniques, which provide faster and more efficient hardware implementations.

[0029] A potential problem with DMVD is that the reference samples used to decode a particular block are unknown until motion vectors from neighboring blocks are decoded. This is because the initial motion vectors used to decode the current block in DMVD can be motion vectors from neighboring blocks. Since the motion vectors of neighboring blocks are not known until the block has been decoded, the reference samples used in the DMVD search process are also unknown.

[0030] Therefore, in some examples, the video decoder implementation may wait until the motion vectors of adjacent blocks are decoded and the motion vector of the current block is derived before extracting reference samples for decoding the current block. Specifically, the video decoder implementation may extract reference pixels from external memory (e.g., DDR RAM) and store them in local memory for decoding. Extracting pixels from external memory is typically a slow process and may be limited by memory bandwidth. Furthermore, external memory may encounter extraction requests from processing cores other than the video decoder. Therefore, other processes performed on the processing system including the video decoder may increase the time spent extracting reference samples for the DMVD process.

[0031] In view of these drawbacks, the techniques disclosed herein may include encoding video data according to constraints on the search region allowed by the DMVD technique. By limiting the search region of the DMVD technique, the range of potential reference samples for the search process is within a fixed search region based on the position of the current block. The fixed search region may be a pre-determined or signaled search region, which may be determined by the video decoder before decoding the image. Therefore, a video decoder hardware implementation may be configured to prefetch reference samples in the fixed search region from external memory to local memory. Prefetching reference samples in local memory before decoding begins allows for faster and more efficient decoding, since the fetching process from external memory can be slow.

[0032] 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 involve decoding (encoding and / or decoding) video data. Typically, video data includes any data used for processing video. Thus, video data may include raw, undecoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata, such as signaling data.

[0033] like Figure 1 As 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 computer-readable medium 110. Source device 102 and destination device 116 can include any of a wide variety of devices, including 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 are therefore referred to as wireless communication devices.

[0034] exist Figure 1 In the example, source device 102 includes a video source 104, a memory 106, a video encoder 200, and an output interface 108. Destination device 116 includes an input interface 122, a video decoder 300, a memory 120, and a 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 prefetching reference samples for template matching. Therefore, 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.

[0035] like Figure 1 The system 100 shown is merely an example. Typically, any digital video encoding and / or decoding device can perform techniques for prefetching reference samples for template matching. 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.

[0036] Generally, video source 104 represents the source of video data (i.e., raw, undecoded video data) and provides a sequential series of pictures (also referred to as "frames") of the video data to video encoder 200, which encodes the data of 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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 operate according to other wireless standards (such as the IEEE 802.11 specification, the IEEE 802.15 specification (e.g., ZigBee)). ™ ),Bluetooth ™The source device 102 and / or destination device 116 may include corresponding system-on-chip (SoC) devices. For example, source device 102 may include SoC devices for performing functions belonging to video encoder 200 and / or output interface 108, and destination device 116 may include SoC devices for performing functions belonging to video decoder 300 and / or input interface 122.

[0044] 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.

[0045] 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 decoded images 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.

[0046] Despite Figure 1 Not shown, but in some examples, both the video encoder 200 and the video decoder 300 may be integrated with the audio encoder and / or audio decoder, and may include appropriate MUX-DEMUX units or other hardware and / or software to process multiplexed streams that include both audio and video in a common data stream.

[0047] 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, 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 partially implemented 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 include integrated circuits, microprocessors, and / or wireless communication devices (such as cellular phones).

[0048] 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. Typically, 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 can use template matching to decode video data.

[0049] Typically, video encoder 200 and video decoder 300 perform block-based decoding of images. The term "block" generally 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. Typically, 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, video encoder 200 and video decoder 300 decode the luminance and chrominance components, where the chrominance components may include both red hue chrominance components and blue hue chrominance components. In some examples, video encoder 200 converts the received RGB format data to a YUV representation before encoding, and video decoder 300 converts the YUV representation to RGB format. Alternatively, preprocessing and postprocessing units (not shown) may perform these conversions.

[0050] 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 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.

[0051] 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.

[0052] 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) divides the image into multiple decoding tree units (CTUs). Video encoder 200 can divide 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 based on quadtree partitioning and a second level based on binary tree partitioning. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to decoding units (CUs).

[0053] 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.

[0054] 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 luma samples or 64x64 luma samples. However, in subsequent video decoding formats (e.g., AV2), superblocks can be defined by different (e.g., larger) luma 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 for each decoded block.

[0055] 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.

[0056] 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).

[0057] 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.

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

[0059] In HEVC, the largest decoding unit in a slice is called a Decoding Tree Block (CTB) or Decoding Tree Unit (CTU). A CTB contains a quadtree whose nodes are decoding units. In the HEVC master profile, the size of a CTB can range from 16×16 to 64×64 (but technically 8×8 CTB size is supported). Decoding Units (CUs) can have the same size as the CTB, as small as 8×8. Each decoding unit is decoded using a mode (i.e., inter-frame or intra-frame). An inter-frame decoded CU can be further divided into 2 or 4 prediction units (PUs) or become a single PU if no further division is applied. When two PUs exist within a CU, these two PUs can be rectangles of half the size or two rectangles of ¼ or ¾ the size of the CU. When a CU is inter-frame decoded, each PU has a set of motion information derived using a unique inter-frame prediction mode.

[0060] 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.

[0061] In some examples, a tile can be divided into multiple bricks, each brick comprising 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 comprises multiple complete tiles or a consecutive sequence of complete bricks comprising only one tile.

[0062] This disclosure uses "N×N" 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, 16×16 samples or 16 by 16 samples. Typically, a 16×16 CU has 16 samples in the vertical direction (y=16) and 16 samples in the horizontal direction (x=16). Similarly, an N×N CU 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 may 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 N×M samples, where M is not necessarily equal to N.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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. Typically, 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), from which it predicts samples for the current block. Assuming the video encoder 200 decodes the CTU and CU in raster scan order (from left to right, from top to bottom), such samples are typically located above, to the upper left, or to the left of the current block within the same frame as the current block.

[0067] 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.

[0068] 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.

[0069] 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-by-sample 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 the Mode Correlated Inseparable Secondary Transform (MDNSST), the Signal Correlation Transform, the Karhunen-Loeve Transform (KLT), etc. The video encoder 200 produces transform coefficients after applying one or more transforms.

[0070] As noted above, after any transform that produces the transform coefficients, the video encoder 200 may perform quantization on the transform coefficients. Quantization generally refers to a 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 round an n-bit value down to an m-bit value during quantization, where n is greater than m. In some examples, to perform quantization, the video encoder 200 may perform a bitwise right shift on the value to be quantized.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] Typically, 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).

[0076] 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.

[0077] 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, 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).

[0078] As will be explained in more detail below, the video encoder 200 and video decoder 300 can be configured to encode and decode video data using the DMVD technology of this disclosure. As an example, the video decoder 300 can be configured to: receive a block of video data encoded using a decoding mode that includes a search process in one or more reference frames (e.g., DMVD technology); prefetch reference samples in a fixed search region of at least one of the one or more reference frames; and decode the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0079] Figure 2A and Figure 2B This is a conceptual graph illustrating example space neighboring motion vector candidates used for decoding motion vectors in merging mode and Advanced Motion Vector Prediction (AMVP) mode. Specifically, Figure 2A The spatial neighbor motion vector (MV) candidates for PU0 130 for the merging mode are depicted, while Figure 2B Spatial adjacency MV candidates for PU0 132 for AMVP mode are depicted.

[0080] In the HEVC standard, there are two inter-frame prediction modes, named Merge (skipping special cases considered as merging) and Advanced Motion Vector Prediction (AMVP) mode for prediction units (PUs). In either AMVP or Merge mode, a list of motion vector (MV) candidates is maintained for multiple motion vector predictors. The motion vector for the current PU and a reference index in the Merge mode are generated by selecting a candidate from the MV candidate list. The MV candidate list contains up to five candidates for the Merge mode and only two candidates for the AMVP mode. A merge candidate can contain a set of motion information, such as motion vectors corresponding to both a list of reference images (list 0 and list 1) and a reference index. If the merge candidate is identified by the merge index, the reference image and associated motion vector for the prediction of the current block are determined.

[0081] On the other hand, in AMVP mode for each potential prediction direction from list 0 or list 1, the reference index along with the MV predictor (MVP) index needs to be explicitly signaled to the MV candidate list, since AMVP candidates only contain motion vectors. In AMVP mode, the predicted motion vectors can be further refined. Candidates for both modes are similarly derived from the same spatially and temporally adjacent blocks.

[0082] According to HEVC, spatial MV candidates are those for a specific PU (PU0) from... Figure 2A and Figure 2B The adjacent blocks shown are derived, although the method for generating candidates from blocks differs for merge mode and AMVP mode. In merge mode, it is possible to... Figure 2A The numbered sequence shown derives up to four spatial MV candidates for PU0 130, and the order is as follows: left (0, A1), top (1, B1), top right (2, B0), bottom left (3, A0), and top left (4, B2).

[0083] In AVMP mode, adjacent blocks are divided into two groups: the left group consisting of blocks 0 and 1, and the upper group consisting of blocks 2, 3, and 4, as shown below. Figure 2B As shown. For each group, potential candidates in the neighboring blocks of PU0 132 that refer to the same reference image indicated by the signaled reference index have the highest priority to be selected to form the final candidates for that group. It is possible that not all neighboring blocks contain motion vectors pointing to the same reference image. Therefore, if such a candidate cannot be found, the first available candidate can be scaled to form the final candidate; thus, the temporal distance difference can be compensated.

[0084] Figure 3A and Figure 3B This is a conceptual diagram illustrating the Temporal Motion Vector Prediction (TMVP) technique. Specifically, Figure 3AThe location of the TMVP candidate for PU0 134 is depicted and marked "T", while Figure 3B It describes motion vector scaling based on the temporal distance between images.

[0085] If TMVP is enabled and TMVP candidates are available, the video decoder can add TMVP candidates to the MV candidate list, following the spatial MV candidates. The motion vector derivation process for TMVP candidates is the same for both merge mode and AMVP mode. However, in merge mode, the target reference index of the TMVP candidate can be set to 0.

[0086] The primary block location for TMVP candidate export is the bottom right block outside the PU, such as... Figure 3A Block 136A is shown to compensate for the bias in the upper and left blocks used to generate spatially adjacent candidates. However, if block 136A is located outside the current CTB line or motion information is unavailable, the center block of the PU (block 136B) can be used instead of the TMVP candidate.

[0087] The motion vectors for TMVP candidates are derived from the co-located PUs of the co-located images indicated at the slice level. The motion vectors of the co-located PUs are called co-located MVs. Similar to the temporal direct mode in AVC, the co-located MVs need to be scaled to compensate for temporal distance differences in order to derive the TMVP candidate motion vectors, such as... Figure 3B As shown.

[0088] HEVC includes various other motion vector prediction techniques, such as those discussed below.

[0089] Assume that the value of a motion vector is proportional to the distance between the images during rendering time. A motion vector associates a reference image with the image containing the motion vector (i.e., the containing image). When predicting another motion vector using one motion vector, the distance between the containing image and the reference image is calculated based on the Picture Order Count (POC) value.

[0090] For a motion vector to be predicted, its associated containing image and reference image can be different. Therefore, a new distance (based on POC) is calculated. The motion vector is then scaled based on these two POC distances. For spatially adjacent candidates, the containing images of two motion vectors are the same, while the reference images are different. In HEVC, motion vector scaling is applied to both TMVP and AMVP candidates for spatial and temporal adjacency.

[0091] If the list of motion vector candidates is incomplete, artificial motion vector candidates can be generated and inserted at the end of the list until the list is full. In the merge mode, there are two types of artificial motion vector candidates: combined candidates derived only for B slices, and zero candidates used only for AMVP if the first type does not provide enough artificial candidates. For each pair of candidates that is already in the candidate list and has the necessary motion information, a bidirectional combined motion vector candidate is derived by combining the motion vector of the first candidate in the image in reference list 0 and the motion vector of the second candidate in the image in reference list 1.

[0092] Candidates from different blocks may happen to be the same, which reduces the efficiency of merging / AMVP candidate lists. Video decoders can address this problem by applying a pruning process. Using a pruning process, the video decoder compares one candidate in the current candidate list with other candidates to avoid inserting identical candidates to some extent. To reduce complexity, instead of comparing every potential candidate with all other existing candidates, only a limited number of pruning process iterations can be applied.

[0093] Figure 4 This is a conceptual diagram illustrating template matching (TM) prediction for motion vector decoding. Template matching (TM) prediction is a special merging mode based on frame rate upconversion (FRUC) technology. Using this mode, motion information for the current block (such as the current CU 140) is not signaled but rather derived on the decoder side (e.g., by the video decoder 300). The video encoder 200 can also perform these techniques during motion compensation. TM can be applied to both AMVP mode and regular merging mode. In AMVP mode, MVP candidate selection is determined based on template matching to pick the initial motion vector (MV) that achieves the minimum difference between the current block template and the reference block template. In regular merging mode, a TM mode flag is signaled to indicate the use of TM, and then TM is applied to the merging candidates indicated by the merging index for MV refinement. That is, the motion vector associated with the merging candidate is used as the initial MV.

[0094] like Figure 4 As shown, template matching can be used to derive motion information of the current CU 140 by finding the closest match between a template in the current image 142 (the top adjacent block and / or left adjacent block of the current CU) and a block in the reference image 144 (of the same size as the template). If an AMVP candidate is selected based on an initial matching error (e.g., an initial MV), the MVP is refined by searching for template matching within region 146. If a merge candidate is indicated by a signaling merge index, its merged MV corresponding to L0 and L1 is independently refined by template matching, and then the less accurate MV is further refined again using a better MV as a priori value.

[0095] Motion-compensated interpolation is performed when the motion vector points to the fractional sample localization. To reduce complexity, bilinear interpolation can be used instead of the conventional 8-tap DCT-IF interpolation for template matching to generate a template on the reference image. The matching cost of template matching... The following can be calculated:

[0096] (1)

[0097] In formula (1) above, As a weighting factor, it (e.g., based on empirical tests) can be set to 4. and These indicate the current test MV and the initial MV (i.e., the MVP candidate in AMVP mode or the merge motion in merge mode). The sum of absolute differences (SAD) can be used as the matching cost for template matching.

[0098] When using TM, motion can be refined using only luma samples. The derived motion can be used for both luma and chroma predictions for MC inter-frames. After determining MV, the final MC can be performed using an 8-tap interpolation filter for luma and a 4-tap interpolation filter for chroma.

[0099] MV refinement is a pattern-based MV search where the conditions are template matching cost and hierarchical structure. In some examples, two search modes are supported: diamond search and cross search for MV refinement. The hierarchical structure specifies the iterative process used to refine the MV, starting with coarse MVD precision (e.g., quarter-pixel) and ending with fine MVD precision (e.g., 1 / 8 pixel). The MV can be searched directly in diamond mode with quarter-luminance sample MVD precision, followed by cross mode with quarter-luminance sample MVD precision, and then cross mode with eighth-luminance sample MVD precision. The search range 146 for MV refinement can be set to equal (-8, +8) luminance samples around the initial MV. When the current block has bidirectional prediction, the two MVs are refined independently, and the best of the two MVs (in terms of matching cost) is set as the prior value to further refine the other MV with BCW (bidirectional prediction using CU-level weights) weight values.

[0100] Figure 5This is a conceptual diagram illustrating the motion vector difference (MVD) values ​​of blocks in reference images that differ in temporal distance (TD) from the current image, including the current block 150. Bilateral matching (also known as bilateral merging or BM) prediction is another merging mode based on Frame Rate Boosting Converter (FRUC) technology. When a video decoder (such as video encoder 200 or video decoder 300) determines to apply the BM mode, the video decoder can derive two initial motion vectors, MV0 and MV1. The video decoder can decode merge candidate indices representing merge candidates in the constructed merge list. The video decoder can perform a bilateral matching search around MV0 and MV1. The video decoder can derive the final MV0' and MV1' based on the minimum bilateral matching cost.

[0101] The motion vector differences MVD0 (denoted by MV0'-MV0) and MVD1 (denoted by MV1'-MV1) pointing to reference blocks 152 and 154 can be proportional to the temporal distance (TD) (e.g., TD0 and TD1) between the current image and the two reference images. The temporal distance can be represented by the difference between the picture order count (POC) values ​​of the corresponding images. Figure 5 Examples of MVD0 and MVD1 are shown, where TD1 is 4 times that of TD0.

[0102] Figure 6 This is a conceptual diagram illustrating an example where two MVDs are mirror images regardless of their time distance. Figure 6 Another possible design is described, in which MVD0 and MVD1 are mirror images regardless of the values ​​of TD0 and TD1. Figure 6 In the example, MVD0 and MVD1 are mirror images, where the value of TD1 is four times the value of TD0.

[0103] Figure 7 This is a conceptual diagram illustrating an example of a 3×3 square search pattern within a bilateral matching search range. Based on bilateral matching, video decoders (such as video encoder 200 and video decoder 300) can perform a local search around initial MV0 and MV1 to derive final MV0' and MV1'. The video decoder can apply the local search to the 3×3 square search pattern and iterate through the search range [-8, 8]. In each search iteration, the video decoder can calculate the bilateral matching costs of the eight surrounding MVs in the search pattern and compare these costs with the bilateral matching cost of the central MV. The MV with the minimum bilateral matching cost becomes the new central MV in the next search iteration. The video decoder can terminate the local search when the current central MV has the minimum cost within the 3×3 square search pattern or when the local search reaches a predefined maximum search iteration. Figure 7 An example of a 3×3 square search pattern in the search range [-8, 8] is shown.

[0104] Figure 8 This is a conceptual diagram illustrating an example of refining motion vectors using decoder-side motion vector refinement (DMVR) for the current block 160. Decoder-side motion vector refinement (DMVR) is applied in the VVC to improve the accuracy of the MV in the merged mode. Both the video encoder 200 and the video decoder 300 can perform the DMVR process. In the bidirectional prediction operation, a refined MV is searched around the initial MV in reference picture lists L0 and L1. According to the DMVR technique, the video decoder calculates the distortion between two candidate blocks 162A and 164A in reference picture lists L0 and L1. Figure 8 As illustrated, the SAD (Sum of Aspects) is calculated between candidate blocks 162B and 164B based on each candidate MV around the initial MV. The MV candidates 162B and 164B with the lowest SAD become the refined MVs and are used to generate the bidirectional prediction signal.

[0105] The refined MV derived from the DMVR process is used to generate inter-frame prediction samples and is also used in temporal motion vector prediction for future image decoding. The original MV is used in the deblocking process and also in spatial motion vector prediction for future CU decoding. DMVR is based on a sub-block merging pattern with a predefined maximum processing unit of 16×16 luma samples. When the width and / or height of a CU is greater than 16 luma samples, the CU can be further divided into sub-blocks with a width and / or height equal to 16 luma samples.

[0106] In one example of DMVR, the search point revolves around the initial MV, and the MV offset follows the MV difference mirroring rule. In other words, any point examined by DMVR, represented by the candidate MV pair (MV0, MV1), follows these two equations:

[0107] MV0' = MV0 + MV_offset

[0108] MV1' = MV1 - MV_offset

[0109] In the above equation, MV_offset represents the thinning offset between the initial MV and the thinned MV in one of the reference images. The thinning search range is two integer luminance samples from the initial MV. The search includes an integer sample offset search phase and a fractional sample thinning phase.

[0110] The video decoder performs a 25-point full search for integer sample offset search. First, the SAD (Sum of Aspects) of the initial MV pair is calculated. If the SAD of the initial MV pair is less than a threshold, the integer sample stage of DMVR is terminated. Otherwise, the SAD of the remaining 24 points is calculated and checked according to the raster scan order. The point with the smallest SAD is selected as the output of the integer sample offset search stage. To reduce the loss due to uncertainty in DMVR refinement, it is proposed to support the original MV during the DMVR process. The SAD between reference blocks referenced by the initial MV candidate references is reduced by 1 / 4 of the SAD value.

[0111] The integer sample search is followed by fractional sample refinement. To save computational complexity, fractional sample refinement is derived using the parametric error surface equation instead of an additional search via SAD comparison. Fractional sample refinement is conditionally invoked based on the output of the integer sample search phase. Fractional sample refinement is further applied when the integer sample search phase terminates at a center with the minimum SAD in either the first or second iteration.

[0112] In subpixel offset estimation based on parametric error surfaces, the following 2-D parabolic error surface equation is fitted using the center localization cost and the cost at four neighboring localization points from the center:

[0113] E x, y = A(x - x min ) 2 + B(y - y min ) 2 + C

[0114] Where (x) min , y min ) corresponds to the fractional location with the minimum cost, and C corresponds to the minimum cost value. The above equation is solved using the cost values ​​of the five search points, (x min , y min The following can be calculated:

[0115] x min = (E -1,0 – E 1,0 ) / 2(E -1,0 + E 1,0 – 2E 0,0 )

[0116] y min = (E 0,-1 – E 0,1 ) / 2(E 0,-1 + E 0,1 – 2E 0,0 )

[0117] xmin and y min The value is automatically constrained between -8 and 8 because all cost values ​​are positive and the minimum is E(0, 0). This corresponds to a half-pixel offset with 1 / 16 pixel (pel) MV accuracy in VVC. The calculated score (x min , y min An integer distance is added to the thin MV to obtain a subpixel-accurate thin increment MV.

[0118] In VVC, the resolution of the MV is 1 / 16 of a luminance sample. An 8-tap interpolation filter is used to interpolate the samples at fractional localization. In DMVR, the search point is around the initial fractional pixel MV with an integer sample offset, so interpolation is needed for those fractionally localized samples in the DMVR search process. To reduce computational complexity, a bilinear interpolation filter is used to generate fractional samples for the search process in DMVR. Another important effect is that, by using a bilinear filter, DVMR does not access more reference samples compared to the normal motion compensation process, with a 2-sample search range. After obtaining the refined MV using the DMVR search process, a normal 8-tap interpolation filter is applied to generate the final prediction. To avoid accessing more reference samples in the normal MC process, samples that are not needed by the interpolation process based on the original MV but are needed by the interpolation process based on the refined MV can be filled from the available samples.

[0119] In VVC, DMVR is enabled if all of the following conditions are met:

[0120] • CU-level merging mode with bidirectional predictive MV

[0121] • Relative to the current image, one reference image is in the past and another reference image is in the future.

[0122] • The distances from the two reference images to the current image (i.e., the difference in point of view, POC) are the same.

[0123] • The CU has more than 64 luminance samples.

[0124] • Both CU height and CU width are greater than or equal to 8 luminance samples.

[0125] • BCW weight index indicates equal weights

[0126] • Weighted prediction (WP) is not enabled for the current block.

[0127] • Combined Inter-Frame Intra-Frame Prediction (CIIP) mode is not used in the current block.

[0128] As described above, when decoding video data using the decoder-side motion vector derivation (DMVD) methods discussed above (e.g., TM, BM, DMVR), hardware implementation issues related to the extraction of reference samples may arise. Specifically, DMVD decoding techniques may lead to two main hardware implementation problems: spatial motion vector propagation and access to neighboring reconstructed samples.

[0129] For many DMVD methods, propagating spatial motion vectors with refined vector information to subsequent blocks used for spatial motion vector prediction is a critical hardware implementation burden. Motion field reconstruction, reference sample extraction, and motion compensation (e.g., operations involving access to reference samples, such as interpolation processes and DMVD methods) are typically separated into different pipeline stages, with the first two often performed several cycles (or several CTUs) before motion compensation to better ensure that the reference samples are ready on-chip for interpolation. Since the refined vector information is unknown during the first two stages, all three stages can only be completed sequentially, which breaks the pipeline design and increases decoding latency.

[0130] One workaround is to extract more reference samples to cover all possible reference samples that might be used during motion compensation. However, due to spatial motion vector prediction (e.g., using motion vectors from neighboring blocks), the refined motion information may carry over to subsequent blocks and accumulate spatially, making it impossible to determine the size of the reference samples to be extracted from the reference image. Therefore, such a solution is functionally no different from extracting all samples from the reference image, which would require increasing the on-chip memory buffer size to store all reference samples. Another workaround is to stop propagating the refined vector information to subsequent blocks in the current image, but this carries the risk of significantly reducing motion prediction efficiency and potentially increasing distortion.

[0131] Accessing adjacent reconstructed samples for template matching to generate the current block template also leads to longer latency in decoding. Without template matching, inter-frame blocks can be reconstructed independently, regardless of the reconstruction of adjacent blocks (unlike intra-frame blocks, which must wait for adjacent block reconstructions to perform intra-frame prediction). However, template matching involves accessing adjacent reconstructed samples, which means that in inter-frame prediction, a certain interdependence is introduced between the current block and the reconstruction of adjacent blocks, resulting in increased decoding latency.

[0132] In summary, a potential problem with DMVD techniques (including template matching) is that the reference samples used to decode a particular block are unknown until motion vectors from neighboring blocks are decoded. This is because the initial motion vectors used to decode the current block in DMVD can be motion vectors from neighboring blocks. Since the motion vectors of neighboring blocks are not known until the block has been decoded, the reference samples used during the search process in DMVD are also unknown. This can mean that the corresponding reference samples used by DMVD may not be loaded locally in a timely manner. This potential unavailability of reference samples can cause hardware pipeline processing to stall until the latest reference pixels are fetched from external memory. Therefore, the uncertainty in the timing of reference sample fetching causes serious dependency problems, which can be a critical path in video decoder hardware design.

[0133] In view of these drawbacks, the techniques disclosed herein may include encoding video data according to constraints on the search region allowed by the DMVD technique. Specifically, the search region of the DMVD process may be limited to a fixed search region. By limiting the search region of the DMVD technique to a fixed search region, the range of potential reference samples for the search process is known based on the position of the current block. Therefore, the video decoder hardware implementation of the video decoder 300 may be configured to prefetch reference samples in the fixed search region from external memory to local memory before decoding the current block. Prefetching reference samples in local memory before decoding of the current block begins allows for faster and more efficient decoding, since the fetching process from external memory can be slow.

[0134] Figure 1 And the following text Figure 9 and Figure 10 The video encoder 200 and video decoder 300 may be configured to perform the techniques disclosed herein. In one example, the video encoder 200 may be configured to encode a block of video data using DMVD technology. Or, more generally, the video encoder 200 may be configured to encode using a decoding mode that includes a search process in one or more reference frames. Such decoding modes may include template matching, bilateral matching prediction, decoder-side motion vector refinement, or any other decoding mode that may use search regions in adjacent motion vectors and / or reference frames. The video encoder 200 may be configured to encode the current block using a fixed search region. In some examples, encoding the current block using a fixed search region may disallow the use of specific initial motion vectors from such adjacent blocks if motion vectors from adjacent blocks point outside the fixed search region.

[0135] In a reversible manner, the video decoder 300 can be configured to receive a block of video data encoded using a decoding mode that includes a search process in one or more reference frames. Because the video encoder 200 uses a fixed search region, the video decoder 300 can prefetch reference samples in the fixed search region of at least one of the one or more reference frames. The video decoder 300 can then use the decoding mode to decode the video data block, including performing the search process of the decoding mode using the prefetched reference samples.

[0136] Figure 9 This is a block diagram illustrating an example video encoder 200 that can perform the techniques of this disclosure. Figure 9 This disclosure is provided for illustrative purposes and should not be construed as a limitation on the techniques extensively illustrated and described herein. For illustrative purposes, this disclosure describes a video encoder 200 based on VVC (ITU-T H.266, under development) and HEVC (ITU-T H.265) technologies. 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.

[0137] exist Figure 9 In the example, the video encoder 200 includes a video data memory 230, a mode selection unit 202, a residual generation unit 204, a transform processing unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse transform processing unit 212, a reconstruction unit 214, a filter unit 216, a decoded picture buffer (DPB) 218, and an entropy coding unit 220. Any or all of the video data memory 230, mode selection unit 202, residual generation unit 204, transform processing unit 206, quantization unit 208, inverse quantization unit 210, inverse transform processing unit 212, reconstruction unit 214, filter unit 216, DPB 218, and entropy coding unit 220 may be implemented in one or more processors or in processing circuitry. For example, the units of the video encoder 200 may 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 encoder 200 may include additional or alternative processors or processing circuitry to perform these and other functions.

[0138] Video data storage 230 can store video data to be encoded by components of video encoder 200. Video encoder 200 can receive data from, for example, video source 104 (…). Figure 1The video data memory 230 receives video data stored in the video data memory 230. The DPB 218 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 230 and DPB 218 can be formed from any of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The video data memory 230 and DPB 218 can be provided by the same memory device or separate memory devices. In various examples, the video data memory 230 can be on-chip (as illustrated) with other components of the video encoder 200, or off-chip relative to those components.

[0139] In this disclosure, references to video data memory 230 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 230 should be understood as a reference memory that stores 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.

[0140] Examples Figure 9 Various units help understand the operations performed by the video encoder 200. Units can be implemented as fixed-function circuits, programmable circuits, or combinations thereof. Fixed-function circuits are circuits that provide specific functionality and are pre-defined for the operations that can be performed. Programmable circuits are circuits that can be programmed to perform various tasks and provide flexible functionality for 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 in the unit may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units in the unit may be integrated circuits.

[0141] 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 1The video encoder 200 may store instructions (e.g., object 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.

[0142] The video data storage unit 230 is configured to store received video data. The video encoder 200 can retrieve images of the video data from the video data storage unit 230 and provide the video data to the residual generation unit 204 and the mode selection unit 202. The video data in the video data storage unit 230 can be raw video data to be encoded.

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

[0144] Mode selection unit 202 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. Mode selection unit 202 can ultimately select a combination of coding parameters that has a better rate-distortion value compared to other tested combinations.

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

[0146] Typically, mode selection unit 202 also controls its components (e.g., motion estimation unit 222, motion compensation unit 224, and intra-prediction unit 226) 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, motion estimation unit 222 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 218). Specifically, motion estimation unit 222 may calculate values ​​representing the similarity between a potential reference block and the current block, for example, based on sum of absolute differences (SAD), sum of squared differences (SSD), mean absolute difference (MAD), mean squared difference (MSD), etc. Motion estimation unit 222 may typically perform these calculations using sample-by-sample differences between the current block and the reference blocks under consideration. Motion estimation unit 222 may identify reference blocks with the lowest values ​​produced by these calculations to indicate the reference block that best matches the current block.

[0147] The motion estimation unit 222 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. The motion estimation unit 222 can then provide the motion vectors to the motion compensation unit 224. For example, for unidirectional inter-frame prediction, the motion estimation unit 222 can provide a single motion vector, while for bidirectional inter-frame prediction, the motion estimation unit 222 can provide two motion vectors.

[0148] Motion compensation unit 224 can be configured to perform any of the various decoder-side motion vector derivation (DMVD) techniques disclosed herein. Although referred to as "decoder-side," it should be understood that video encoder 200 can also perform these techniques such that the reference blocks identified by the derived / refined motion vectors are identical. The term "decoder-side" is used because the decoder (e.g., video decoder 300) is capable of deriving / refining the motion vectors of a block using one or more of these various techniques without requiring additional information signaled by video encoder 200.

[0149] According to the technology disclosed herein, motion compensation unit 224 can decode video data using any of the DMVD techniques described above, based on a fixed search region in a reference image. The fixed search region can be any M×N region. A larger M×N fixed search region allows for the potential to achieve better compression efficiency at the cost of requiring larger on-chip local memory for prefetching and storing reference pixels. A smaller M×N fixed search region allows for the use of smaller on-chip memory and shorter memory access latency, but at the potential cost of compression efficiency. The size of the M×N fixed search region can be chosen based on these trade-offs.

[0150] In some examples, the M×N fixed search region is predetermined and is the same for all images. In other examples, the M×N fixed search region can be adaptable at the image or sequence level. In such examples, the video encoder 200 can be configured to encode syntax elements indicating the size of the M×N fixed search region.

[0151] Then, the motion compensation unit 224 can execute any of the various DMVD techniques of this disclosure (or other similar DMVD techniques) to perform a refinement search within a fixed search region. The motion compensation unit 224 can use one or more unrefined motion vectors from the previous decoded block to the current block to perform a motion field reconstruction stage, and then use one or more unrefined motion vectors to perform a reference sample extraction stage to retrieve reference samples within the fixed search region. The motion compensation unit 224 can then use the retrieved reference samples to perform the DMVD technique.

[0152] In some examples, when the motion compensation unit 224 performs TM, the motion compensation unit 224 may use only adjacent reconstructed samples to form the current block template.

[0153] Finally, after deriving or refining one or more motion vectors using one or more DMVD techniques of this disclosure, motion compensation unit 224 can obtain reference samples to generate prediction blocks using the motion vectors. The formation of the prediction blocks can be performed during the motion compensation phase. For example, motion compensation unit 224 can use the motion vectors to retrieve data for the reference blocks. As another example, where the motion vectors have fractional sample precision, motion compensation unit 224 can interpolate the values ​​of the prediction blocks according to one or more interpolation filters. Furthermore, for bidirectional inter-frame prediction, motion compensation unit 224 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.

[0154] When operating according to the AV1 video decoding format, the motion estimation unit 222 and the motion compensation unit 224 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.

[0155] As another example, for intra-prediction or intra-prediction decoding, intra-prediction unit 226 may generate a prediction block from samples adjacent to the current block. For example, for directional mode, intra-prediction unit 226 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 226 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.

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

[0157] Mode selection unit 202 provides a prediction block to residual generation unit 204. Residual generation unit 204 receives the original, undecoded version of the current block from video data memory 230 and the prediction block from mode selection unit 202. Residual generation unit 204 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 204 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 204 may be formed using one or more subtractor circuits performing binary subtraction.

[0158] In the example where mode selection unit 202 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 its luma decoding block, while the size of a PU can refer to the size of its luma prediction unit. Assuming a particular CU size is 2N×2N, video encoder 200 can support PU sizes of 2N×2N or N×N for intra-frame prediction, and symmetric PU sizes of 2N×2N, 2N×N, N×2N, N×N, or similar for inter-frame prediction. Video encoder 200 and video decoder 300 can also support asymmetric partitioning for PU sizes of 2N×nU, 2N×nD, nL×2N, and nR×2N for inter-frame prediction.

[0159] In an example where mode selection unit 202 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 2N×2N, 2N×N, or N×2N.

[0160] 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 202 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 202 may not generate a prediction block, but instead generate syntax elements indicating how the block is reconstructed based on a selected palette. In such modes, mode selection unit 202 may provide these syntax elements to entropy coding unit 220 for encoding.

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

[0162] Transform processing unit 206 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 206 may apply various transformations to the residual block to form the transform coefficient block. For example, transform processing unit 206 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 206 may perform multiple transformations on the residual block, such as primary and secondary transformations (e.g., rotation transformations). In some examples, transform processing unit 206 does not apply any transformations to the residual block.

[0163] When operating according to AV1, transform processing unit 206 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"). Transform processing unit 206 may apply various transforms to the residual block to form the transform coefficient block. For example, transform processing unit 206 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.

[0164] Quantization unit 208 quantizes the transform coefficients in a transform coefficient block to produce a quantized transform coefficient block. Quantization unit 208 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 202) 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 206.

[0165] The inverse quantization unit 210 and the inverse transform processing unit 212 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 214 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 202. For example, the reconstruction unit 214 can add samples of the reconstructed residual block to corresponding samples of the prediction block generated by the mode selection unit 202 to generate the reconstructed block.

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

[0167] When operating according to AV1, filter unit 216 may perform one or more filtering operations on the reconstructed block. For example, filter unit 216 may perform a deblocking operation to reduce block artifacts along the edges of the CU. In other examples, filter unit 216 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 216 may also include a loop recovery filter applied after CDEF and may include a separable symmetric normalized Wiener filter or a dual-guided filter.

[0168] The video encoder 200 stores reconstructed blocks in the DPB 218. For example, in an example where the filter unit 216 is not operated, the reconstruction unit 214 may store reconstructed blocks in the DPB 218. In an example where the filter unit 216 is operated, the filter unit 216 may store filtered reconstructed blocks in the DPB 218. The motion estimation unit 222 and the motion compensation unit 224 may retrieve reference images formed by the reconstructed (and potentially filtered) blocks from the DPB 218 to perform inter-frame prediction for blocks of subsequent encoded images. Additionally, the intra-frame prediction unit 226 may use the reconstructed blocks of the current image in the DPB 218 to perform intra-frame prediction for other blocks in the current image.

[0169] Typically, entropy coding unit 220 can entropy-encode syntax elements received from other functional components of video encoder 200. For example, entropy coding unit 220 can entropy-encode quantized transform coefficient blocks from quantization unit 208. As another example, entropy coding unit 220 can entropy-encode predictive syntax elements (e.g., motion information for inter-frame prediction or intra-frame mode information for intra-frame prediction) from mode selection unit 202. Entropy coding unit 220 can perform one or more entropy coding operations on syntax elements (another example of video data) to generate entropy-coded data. For example, entropy coding unit 220 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, entropy coding unit 220 can operate in a bypass mode where syntax elements are not entropy-encoded.

[0170] The video encoder 200 can output a bitstream that includes the entropy coding syntax elements required to reconstruct slices or blocks of images. Specifically, the entropy coding unit 220 can output a bitstream.

[0171] According to AV1, entropy coding unit 220 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. Entropy coding unit 220 can store the probabilities as an n-bit (e.g., 15-bit) cumulative distribution function (CDF). Entropy coding unit 220 can perform recursive scaling to update the context using an update factor based on the alphabet size.

[0172] 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.

[0173] 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.

[0174] In this way, video encoder 200 represents an example of a video encoder, which includes: a memory configured to store video data; and one or more processors implemented in a circuit and configured to encode blocks of video data using DMVD encoding technology and a fixed search region.

[0175] Figure 10 This is a block diagram illustrating an example video decoder 300 that can perform the techniques of this disclosure. Figure 10 This disclosure is provided for illustrative purposes and not for limiting the techniques extensively illustrated and described herein. For illustrative purposes, this disclosure describes a video decoder 300 based on the techniques of VVC (ITU-T H.266, under development) and HEVC (ITU-T H.265). However, the techniques of this disclosure can be implemented by video decoding devices configured for other video decoding standards.

[0176] exist Figure 10In the example, the video decoder 300 includes a decoded picture buffer (CPB) memory 320, an entropy decoding unit 302, a prediction processing unit 304, an inverse quantization unit 306, an inverse transform processing unit 308, a reconstruction unit 310, a filter unit 312, and a decoded picture buffer (DPB) 314. Any or all of the CPB memory 320, entropy decoding unit 302, prediction processing unit 304, inverse quantization unit 306, inverse transform processing unit 308, reconstruction unit 310, filter unit 312, and DPB 314 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.

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

[0178] When operating according to AV1, motion compensation unit 316 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 318 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, intra-block copy (IBC), and / or palette mode, as described above.

[0179] CPB memory 320 can store video data to be decoded by components of video decoder 300, such as encoded video bitstreams. For example, it can be retrieved from computer-readable medium 110 ( Figure 1The video data stored in the CPB memory 320 is obtained. The CPB memory 320 may include a CPB that stores encoded video data (e.g., syntax elements) from the encoded video bitstream. Furthermore, the CPB memory 320 may store video data other than the syntax elements of the decoded picture, such as temporary data representing the output of various units from the video decoder 300. The DPB 314 typically stores a decoded picture that the video decoder 300 may output, and / or uses the decoded picture as reference video data when decoding subsequent data or pictures of the encoded video bitstream. The CPB memory 320 and the DPB 314 may be formed from any of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The CPB memory 320 and the DPB 314 may be provided by the same memory device or separate memory devices. In various examples, the CPB memory 320 and / or DPB 314 may be on-chip along with other components of the video decoder 300, or off-chip relative to those components. This will be discussed below. Figure 11 As shown, the memory system of the video decoder 300 may include local memory (e.g., cache memory implemented on-chip relative to the hardware of the video decoder 300) and external memory (e.g., DDR RAM) that can be accessed by the video decoder 300 and other processing cores of the video encoding and decoding system 100.

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

[0181] Examples Figure 10 The various units shown help to understand the operations performed by the video decoder 300. These units can be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Similar to... Figure 9Fixed-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.

[0182] 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.

[0183] The entropy decoding unit 302 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 304, the inverse quantization unit 306, the inverse transform processing unit 308, the reconstruction unit 310, and the filter unit 312 can generate decoded video data based on the syntax elements extracted from the bitstream.

[0184] Typically, 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").

[0185] Entropy decoding unit 302 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 306 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 306. Inverse quantization unit 306 can, for example, perform a bit-by-bit left shift operation to inverse quantize the quantized transform coefficients. Inverse quantization unit 306 can thereby form a transform coefficient block including the transform coefficients.

[0186] After the inverse quantization unit 306 forms the transform coefficient block, the inverse transform processing unit 308 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 308 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.

[0187] Furthermore, the prediction processing unit 304 generates a prediction block based on the prediction information syntax elements entropy decoded by the entropy decoding unit 302. For example, if the prediction information syntax elements indicate that the current block is an inter-frame prediction, the motion compensation unit 316 can generate the prediction block. In this case, the prediction information syntax elements may indicate the reference picture from which the reference block is to be retrieved in the DPB 314, 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 316 may generally follow the same procedure as relative to the motion compensation unit 224 ( Figure 9 The method described is essentially the same as the method used to perform the inter-frame prediction process.

[0188] According to the technology of this disclosure, motion compensation unit 316 may determine a fixed search region from which reference samples of reference pictures (e.g., stored in DPB 314) are retrieved for use in performing DMVD on the current block of video data. The size of the fixed search region may be the same for each of various DMVD techniques, such as Template Matching (TM), Bilateral Merging (BM), Decoder-Side Motion Vector Refinement (DMVR), and / or multiple-pass DMVR. While the technology of this disclosure is described with respect to the DMVD techniques described above, the same technology may be used with any decoding technique that uses a search process and / or uses motion vector information from adjacent blocks. In other examples, different fixed search regions (e.g., M×N search regions) may be used for one or more DMVD techniques. In one example, video decoder 300 may be pre-configured with the size of the fixed search region for each DMVD decoding mode in the DMVD decoding modes. In other examples, video decoder 300 may decode syntax elements indicating the size of the fixed search region to be used for a picture or picture sequence.

[0189] The motion compensation unit 316 or another functional unit of the video decoder 300 can be configured to prefetch reference samples of one or more reference images from one or more lists of reference images (e.g., list 0 and list 1) based on the size of a fixed search region. As will be shown below, the position of the fixed search region within the reference images can be determined based on the position of the current block to be decoded. In some examples, the fixed search region is centered on the position of the current block. In other examples, the fixed search region may be offset from the position of the current block.

[0190] Prefetching reference samples may include accessing reference samples in a fixed search region of a reference image from external memory (e.g., RAM), and storing reference samples in the local memory (e.g., cache memory) of the video decoder 300. In some examples, the local memory may be DPB 314. In other examples, DPB 314 may include both external memory and local memory. That is, some decoded images considered to be part of DPB 314 may be stored in external memory, while other decoded images considered to be part of DPB 314 may be stored in local memory. In the art of this disclosure, prefetching reference samples in a fixed search region includes accessing reference samples from external memory and storing them in local memory.

[0191] Then, the motion compensation unit 316 can execute any of the various DMVD techniques of this disclosure (or other similar DMVD techniques) to perform a refinement search within a fixed search region using pre-fetched reference samples. The motion compensation unit 316 can use one or more unrefined motion vectors from the previous decoded block to the current block to perform a motion field reconstruction stage, and then use one or more unrefined motion vectors to perform a reference sample extraction stage to retrieve reference samples within the fixed search region. The motion compensation unit 316 can then use the retrieved reference samples to perform the DMVD technique.

[0192] In some examples, when the motion compensation unit 316 performs TM, the motion compensation unit 316 may use only adjacent reconstructed samples to form the current block template.

[0193] Finally, after deriving or refining one or more motion vectors using one or more DMVD techniques of this disclosure, motion compensation unit 316 can obtain reference samples to generate prediction blocks using the motion vectors. The formation of the prediction blocks can be performed during the motion compensation phase. For example, motion compensation unit 316 can use the motion vectors to retrieve data for the reference blocks. As another example, if the motion vectors have fractional sample accuracy, motion compensation unit 316 can interpolate the prediction blocks according to one or more interpolation filters. Furthermore, for bidirectional inter-frame prediction, motion compensation unit 316 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.

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

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

[0196] Filter unit 312 can perform one or more filtering operations on the reconstructed block. For example, filter unit 312 can perform a deblocking operation to reduce block artifacts along the edges of the reconstructed block. The operation of filter unit 312 is not necessarily performed in all examples.

[0197] The video decoder 300 can store reconstructed blocks in the DPB 314. For example, in an example where the operation of the filter unit 312 is not performed, the reconstruction unit 310 can store the reconstructed blocks in the DPB 314. In an example where the operation of the filter unit 312 is performed, the filter unit 312 can store the filtered reconstructed blocks in the DPB 314. As discussed above, the DPB 314 can provide reference information (such as samples of the current image for intra-frame prediction and samples of previously decoded images for subsequent motion compensation) to the prediction processing unit 304. Furthermore, the video decoder 300 can output decoded images (e.g., decoded video) from the DPB 314 for use in applications such as... Figure 1 The subsequent presentation on display devices such as display device 118.

[0198] In this manner, video decoder 300 represents an example of a video decoder, which includes: a memory configured to store video data; and one or more processors implemented in a circuit and configured to: receive a block of video data encoded using a decoding mode that includes a search process in one or more reference frames; prefetch reference samples in a fixed search region of at least one of the one or more reference frames; and decode the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0199] Figure 11 This is a block diagram illustrating an example of pixel prefetching. For example... Figure 11 As shown, the video decoder 300 can be configured to prefetch reference samples 410 from external memory 404 and store the prefetched reference samples in local memory 402. External memory 404 can be any type of system memory (e.g., RAM) that can be configured to store large amounts of data. Typically, external memory 404 can be used by processing cores in the processing system other than the video decoder 300. For example, external memory 404 can be accessed by a central processing unit (CPU), graphics processing unit (GPU), DSP, or other processing cores. Local memory 402 can be memory that is only available to the video decoder 300, such as a cache. Local memory 402 typically provides faster data access than external memory 420. As discussed above, local memory 402 and external memory 404 can functionally constitute DPB 314, even though they are different memory units with different bandwidths and access times.

[0200] Video decoder 300 can receive video data blocks encoded using a decoding mode that includes a search process in one or more reference frames. Examples of such decoding may include template matching (TM) predictive decoding modes, bilateral matching (BM) predictive decoding modes, and decoder-side motion vector refinement (DMVR) decoding modes. However, it should be understood that the techniques disclosed herein can be applied in conjunction with any decoding mode that uses a search process in a reference picture. In this context, the use of a search process may simply be the use of motion vectors pointing to locations in the reference picture. Restricting the search process to a specific fixed search area in the reference picture may include disallowing (e.g., at video encoder 200) the use of motion vectors from neighboring blocks that point outside the fixed search area in the reference picture.

[0201] Based on the use of a decoding mode that includes a search process in one or more reference frames, the video decoder 300 may prefetch reference samples 410 in a fixed search region of at least one of the one or more reference frames. The video decoder 300 may determine reference images for decoding blocks of an image before decoding the image, and prefetch reference samples in a fixed search region of one or more such reference images before decoding the current block of video data. In some examples, the video encoder 200 may prefetch reference samples from all reference images used for decoding the current block before decoding the current block. Prefetching reference samples 410 may include retrieving reference samples from external memory 404 and storing the reference samples as prefetched reference samples in local memory 402. The video decoder 300 may then use the decoding mode to decode the video data block, including performing the search process of the decoding mode using the prefetched reference samples.

[0202] It should be noted that the prefetching of reference samples according to the technology of this disclosure is suitable for use with decoding modes that use both integer and fractional reference samples. Since the required reference pixels have already been locally fetched from external memory, the video decoder 300 can schedule a fractional pixel interpolation process for the corresponding fractional pixel search before decoding the block. That is, the timing required for the fractional interpolation operation will not further affect the complexity of DMVD operations (such as those in TM mode). Therefore, the video decoder 300 can also be configured to perform an interpolation process on the prefetched reference samples before decoding the video data block when fractional reference pixels are used in the decoding mode.

[0203] Figure 12 This is a conceptual diagram illustrating the example prefetch region. Figure 12 A portion of reference image 450 is shown. (See image 450.) Figure 12 As shown, the video decoder 300 can prefetch reference samples in a fixed (M×N) search region 452 of CU0. Similarly, the video decoder 300 can prefetch reference samples in a fixed (M×N) search region 454 of CU1 and in a fixed (M×N) search region 456 of CU2. Although this example shows the video data block as a CU, in other examples, the fixed search region may be based on other types of blocks, such as decode tree units (CTUs) and / or maximum decode units (LCUs).

[0204] like Figure 12As shown, the position of the search region 452 of CU0 is typically centered around CU0. That is, the position of the search region 452 in the reference image is based on the position of a fixed block. In other examples, the search region 452 may not be centered around CU0, but may be offset from the position of CU0 by several samples. Such offsets may be predetermined or signaled by the video encoder 200. Typically, the position of a fixed search region in at least one reference frame is based on the location of the video data block in the current frame.

[0205] Furthermore, it should be noted that for each of the consecutive CUs (CU0, CU1, and CU2) in a row, the fixed search regions substantially overlap. Therefore, the video decoder 300 does not need to prefetch all search regions into local memory, as most of such regions are likely already in local memory. Instead, after prefetching the search region of the first CU, additional prefetching operations for consecutive CUs may only require fetching the next set of reference samples not yet in local memory. For example, when prefetching reference samples in the fixed region of the next CU to the right of CU2, the video decoder 300 may only need to... Figure 12 Pre-sample reference samples from region 458.

[0206] The technology disclosed herein offers the following advantages. Because the video encoder 200 and video decoder 300 are configured to use a fixed, co-located search region using DMVD techniques such as TM, it is not necessary to decode dynamic motion vector information from adjacent video data blocks to determine what reference samples may be needed. Instead, the video decoder 300 can prefetch all reference samples within a fixed search region in the reference picture used to decode the current block. This eliminates the uncertainty in reference sample extraction, thereby improving decoding speed and simplifying the decoder hardware implementation. Since the fixed search region in the reference picture is known before decoding the current block, the search region of the reference pixels can be prefetched to on-chip local storage based on a pre-arranged schedule. Additionally, the video decoder 300 can pre-interpolate fractional samples for fractional TM mode (or other modes using fractional samples) without further increasing the complexity of TM. Furthermore, the required memory bandwidth is also predetermined and its corresponding increase is limited after the initial region extraction is performed per CU / LCU row as described above.

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

[0208] In this example, the video encoder 200 initially predicts the current block (350). For example, the video encoder 200 may form a prediction block for the current block. Specifically, the video encoder 200 may perform inter-frame prediction to predict the block, including performing decoder-side motion vector derivation (DMVD) alone or in any combination of various techniques according to this disclosure to form motion vectors for the current block. The video encoder 200 then uses the motion vectors to form the prediction block. The video encoder 200 may then compute a residual block for the current block (352). To compute the residual block, the video encoder 200 may compute the difference between the original uncracked block of 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 (354). Next, the video encoder 200 may scan the quantized transform coefficients of the residual block (356). During or after the scan, the video encoder 200 may entropy encode the transform coefficients (358). For example, the video encoder 200 can use CAVLC or CABAC to encode the transform coefficients. The video encoder 200 can then output the entropy-coded data (360) of the block.

[0209] The video encoder 200 can also decode the current block after encoding it, using the decoded version of the current block as reference data for subsequent decoded data (e.g., in inter-frame prediction mode or intra-frame prediction mode). Therefore, the video encoder 200 can inversely quantize and inversely transform the coefficients to reproduce the residual block (362). The video encoder 200 can combine the residual block with the prediction block to form a decoded block (364). The video encoder 200 can then store the decoded block in the DPB 218 (366).

[0210] Figure 14 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 include the current CU. Although this relates to video decoder 300 ( Figure 1 and Figure 10 This description is provided, but it should be understood that other devices can be configured to perform similar actions. Figure 14 Similar to the method.

[0211] The video decoder 300 may receive entropy-coded data for 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 (370). The video decoder 300 may entropy decode the entropy-coded data to determine prediction information for the current block and reproduce the transform coefficients of the residual block (372). The video decoder 300 may, for example, use an inter-frame prediction mode as indicated by the prediction information of the current block to predict the current block (374) to compute a predicted block for the current block. Specifically, the video decoder 300 may perform inter-frame prediction to predict the block, including performing decoder-side motion vector derivation (DMVD) alone or in any combination according to any of the various techniques of this disclosure to form a motion vector for the current block. The video decoder 300 may then use the motion vector to form a predicted block. The video decoder 300 may then perform an inverse scan of the reproduced transform coefficients (376) to create a block of quantized transform coefficients. The video decoder 300 can then inversely quantize the transform coefficients and apply the inverse transform to the transform coefficients to produce a residual block (378). The video decoder 300 can then perform final decoding of the current block by combining the predicted block and the residual block (380).

[0212] Figure 15 This is a flowchart illustrating an example method for decoding the current block using motion vectors derived and / or refined according to the techniques of this disclosure. Figure 15 The method can be achieved by a video decoder 300 (e.g., in...). Figure 14 The method is executed during step 374.

[0213] The video decoder 300 can be configured to receive video data blocks encoded using a decoding mode that includes a search process (500) in one or more reference frames. The video data block can be a decoding unit (CU) of video data or a maximum decoding unit (LCU) of video data. In one example, the decoding mode is a template matching (TM) predictive decoding mode. In another example, the decoding mode is a bilateral matching (BM) predictive decoding mode. In yet another example, the decoding mode is a decoder-side motion vector refinement (DMVR) decoding mode.

[0214] The video decoder 300 may also be configured to prefetch reference samples (502) within a fixed search region of at least one of the one or more reference frames. In one example, to prefetch the reference sample, the video decoder 300 is configured to retrieve the reference sample from external memory and store the reference sample as a prefetched reference sample in local memory. In one example, the size of the fixed search region is pre-configured at the video decoder 300. In another example, the video decoder 300 may be configured to receive and decode syntax elements indicating the size of the fixed search region. The position of the fixed search region within the at least one reference frame may be based on the location of the video data block in the current frame.

[0215] The video decoder 300 can also be configured to decode the video data block using the decoding mode, including performing the search process (504) of the decoding mode using prefetched reference samples. In some examples, the decoding mode uses fractional reference pixels, and the video decoder 300 is configured to perform an interpolation process on the prefetched reference samples before decoding the video data block.

[0216] Certain techniques of this disclosure are summarized in the following provisions:

[0217] Clause 1. A method for decoding video data, the method comprising: receiving a block of video data encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; prefetching reference samples in a fixed search region of at least one of the one or more reference frames; and decoding the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0218] Clause 2. The method according to Clause 1, wherein prefetching the reference sample comprises: retrieving the reference sample from external memory; and storing the reference sample as a prefetched reference sample in local memory.

[0219] Clause 3. The method according to any one of Clauses 1 to 2, wherein the decoding mode uses fractional reference pixels, the method further comprising: performing an interpolation process on pre-fetched reference samples before decoding the video data block.

[0220] Clause 4. The method according to any one of Clauses 1 to 3, wherein the decoding pattern is a template matching (TM) predictive decoding pattern.

[0221] Clause 5. The method according to any one of Clauses 1 to 3, wherein the decoding mode is a bilateral matching (BM) predictive decoding mode.

[0222] Clause 6. The method according to any one of Clauses 1 to 3, wherein the decoding mode is a decoder-side motion vector refinement (DMVR) decoding mode.

[0223] Clause 7. The method according to any one of Clauses 1 to 6, wherein the video data block is a decoding unit (CU) of video data or a maximum decoding unit (LCU) of video data.

[0224] Clause 8. The method according to any one of Clauses 1 to 7, the method further comprising: receiving a syntax element indicating the size of the fixed search region.

[0225] Clause 9. The method according to any one of Clauses 1 to 8, wherein the position of the fixed search region in the at least one reference frame is based on the positioning of the video data block in the current frame.

[0226] Clause 10. The method according to any one of Clauses 1 to 9, the method further comprising: displaying an image including the decoded video data blocks.

[0227] Clause 11. An apparatus configured to decode video data, the apparatus comprising: an external memory; a local memory; and one or more processors in communication with the external memory and the local memory, the one or more processors being configured to: receive a block of video data encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; prefetch reference samples in a fixed search region of at least one of the one or more reference frames; and decode the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0228] Clause 12. The apparatus according to Clause 11, wherein, for prefetching the reference sample, the one or more processors are further configured to: retrieve the reference sample from the external memory; and store the reference sample in the local memory as the prefetched reference sample.

[0229] Clause 13. The apparatus according to any one of Clauses 11 to 12, wherein the decoding mode uses fractional reference pixels, and wherein the one or more processors are further configured to perform an interpolation process on prefetched reference samples prior to decoding the video data block.

[0230] Clause 14. The apparatus according to any one of Clauses 11 to 13, wherein the decoding mode is a template matching (TM) predictive decoding mode.

[0231] Clause 15. The apparatus according to any one of Clauses 11 to 13, wherein the decoding mode is a bilateral matching (BM) predictive decoding mode.

[0232] Clause 16. The apparatus according to any one of Clauses 11 to 13, wherein the decoding mode is a decoder-side motion vector refinement (DMVR) decoding mode.

[0233] Clause 17. The apparatus according to any one of Clauses 11 to 16, wherein the video data block is a decoding unit (CU) of video data or a maximum decoding unit (LCU) of video data.

[0234] Clause 18. The apparatus according to any one of Clauses 11 to 17, wherein the one or more processors are further configured to: receive a syntax element indicating the size of the fixed search region.

[0235] Clause 19. The apparatus according to any one of Clauses 11 to 18, wherein the position of the fixed search region in the at least one reference frame is based on the positioning of the video data block in the current frame.

[0236] Clause 20. The apparatus according to any one of Clauses 11 to 19, the apparatus further comprising: a display configured to display an image including the decoded video data blocks.

[0237] Clause 21. An apparatus configured to decode video data, the apparatus comprising: means for receiving a block of video data encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; means for prefetching reference samples in a fixed search region of at least one of the one or more reference frames; and means for decoding the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0238] Clause 22. The apparatus according to Clause 21, wherein the component for prefetching the reference sample comprises: a component for retrieving the reference sample from an external memory; and a component for storing the reference sample as a prefetched reference sample in a local memory.

[0239] Clause 23. The apparatus of any one of Clauses 21 to 22, wherein the decoding mode uses fractional reference pixels, the apparatus further comprising: a component for performing an interpolation process on prefetched reference samples prior to decoding the video data block.

[0240] Clause 24. The apparatus according to any one of Clauses 21 to 23, wherein the decoding mode is one of Template Matching (TM) predictive decoding mode, Bilateral Matching (BM) predictive decoding mode, or Decoder-Side Motion Vector Refinement (DMVR) decoding mode.

[0241] Clause 25. The apparatus according to any one of Clauses 21 to 24, the apparatus further comprising: a component for receiving a syntax element indicating the size of the fixed search area.

[0242] Clause 26. A non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors configured to decode video data to: receive a block of video data encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; prefetch reference samples in a fixed search region of at least one of the one or more reference frames; and decode the video data block using the decoding mode, including performing the search process of the decoding mode using the prefetched reference samples.

[0243] Clause 27. The non-transitory computer-readable storage medium according to Clause 26, wherein, in order to prefetch the reference sample, the instructions further cause the one or more processors to: retrieve the reference sample from external memory; and store the reference sample as a prefetched reference sample in local memory.

[0244] Clause 28. A non-transitory computer-readable storage medium according to any one of Clauses 26 to 27, wherein the decoding mode uses fractional reference pixels, and wherein the instructions further cause the one or more processors to perform an interpolation process on prefetched reference samples before decoding the video data block.

[0245] Clause 29. The non-transitory computer-readable storage medium according to any one of Clauses 26 to 28, wherein the decoding mode is one of Template Matching (TM) predictive decoding mode, Bilateral Matching (BM) predictive decoding mode, or Decoder-Side Motion Vector Refinement (DMVR) decoding mode.

[0246] Clause 30. A non-transitory computer-readable storage medium according to any one of Clauses 26 to 29, wherein the instructions further cause the one or more processors to: receive a syntax element indicating the size of the fixed search region.

[0247] It should be recognized that, based on the examples, certain actions or events of any technique described herein may be performed in a different order, and may be added, combined, or omitted entirely (e.g., not all actions or events described are necessary for implementing the technique). Furthermore, in some examples, actions or events may be performed concurrently (e.g., through multithreading, interrupt handling, or multiple processors) rather than sequentially.

[0248] 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. Thus, 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.

[0249] By way of example, and not limitation, such computer-readable storage media may include 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 technologies (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are 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 utilize lasers to optically reproduce data. The combinations described above should also be included within the scope of computer-readable media.

[0250] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (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.

[0251] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or a set of ICs (e.g., chipsets). 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. Specifically, as described above, various units may be combined in a codec hardware unit, or various units may be provided by a collection of interoperable hardware units (including one or more processors as described above) combined with appropriate software and / or firmware.

[0252] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for decoding video data, the method comprising: Receive video data blocks encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; Pre-fetch reference samples in a fixed search region of at least one of the one or more reference frames; as well as Decoding the video data block using the decoding mode includes performing the search process of the decoding mode using prefetched reference samples.

2. The method according to claim 1, wherein pre-fetching the reference sample comprises: Retrieve the reference sample from external memory; as well as The reference sample is stored in the local memory as the prefetched reference sample.

3. The method of claim 1, wherein the decoding mode uses fractional reference pixels, the method further comprising: An interpolation process is performed on the pre-fetched reference samples before decoding the video data block.

4. The method according to claim 1, wherein the decoding mode is a template matching (TM) predictive decoding mode.

5. The method according to claim 1, wherein the decoding mode is a bilateral matching (BM) predictive decoding mode.

6. The method according to claim 1, wherein the decoding mode is a decoder-side motion vector refinement (DMVR) decoding mode.

7. The method according to claim 1, wherein the video data block is a video data decoding unit (CU) or a video data maximum decoding unit (LCU).

8. The method according to claim 1, further comprising: Receive a syntax element that indicates the size of the fixed search region.

9. The method of claim 1, wherein the position of the fixed search region in the at least one reference frame is based on the positioning of the video data block in the current frame.

10. The method according to claim 1, further comprising: Displays an image including the decoded video data blocks.

11. An apparatus configured to decode video data, the apparatus comprising: External storage; Local memory; and One or more processors that communicate with the external memory and the local memory, the one or more processors being configured to: Receive video data blocks encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; Pre-fetch reference samples in a fixed search region of at least one of the one or more reference frames; as well as Decoding the video data block using the decoding mode includes performing the search process of the decoding mode using prefetched reference samples.

12. The apparatus of claim 11, wherein, in order to prefetch the reference sample, the one or more processors are further configured to: Retrieve the reference sample from the external memory; and The reference sample is stored in the local memory as the prefetched reference sample.

13. The apparatus of claim 11, wherein the decoding mode uses fractional reference pixels, and wherein the one or more processors are further configured to: An interpolation process is performed on the pre-fetched reference samples before decoding the video data block.

14. The apparatus of claim 11, wherein the decoding mode is a template matching (TM) predictive decoding mode.

15. The apparatus of claim 11, wherein the decoding mode is a bilateral matching (BM) predictive decoding mode.

16. The apparatus of claim 11, wherein the decoding mode is a decoder-side motion vector refinement (DMVR) decoding mode.

17. The apparatus of claim 11, wherein the video data block is a video data decoding unit (CU) or a video data maximum decoding unit (LCU).

18. The apparatus of claim 11, wherein the one or more processors are further configured to: Receive a syntax element that indicates the size of the fixed search region.

19. The apparatus of claim 11, wherein the position of the fixed search region in the at least one reference frame is based on the positioning of the video data block in the current frame.

20. The apparatus of claim 11, further comprising: A display configured to display an image including blocks of decoded video data.

21. An apparatus configured to decode video data, the apparatus comprising: A component for receiving video data blocks encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; A component for pre-fetching reference samples in a fixed search region of at least one of the one or more reference frames; and The components for decoding the video data block using the decoding mode include components for performing the search process of the decoding mode using prefetched reference samples.

22. The apparatus of claim 21, wherein the component for pre-fetching the reference sample comprises: Components used to retrieve the reference sample from external memory; and A component for storing the reference sample in local memory as a prefetched reference sample.

23. The apparatus of claim 21, wherein the decoding mode uses fractional reference pixels, the apparatus further comprising: A component for performing an interpolation process on a pre-fetched reference sample before decoding the video data block.

24. The apparatus of claim 21, wherein the decoding mode is one of template matching (TM) predictive decoding mode, bilateral matching (BM) predictive decoding mode, or decoder-side motion vector refinement (DMVR) decoding mode.

25. The apparatus of claim 21, further comprising: A component for receiving a syntax element that indicates the size of the fixed search region.

26. A non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors configured to decode video data: Receive video data blocks encoded using a decoding mode, the decoding mode including a search process in one or more reference frames; Pre-fetch reference samples in a fixed search region of at least one of the one or more reference frames; as well as Decoding the video data block using the decoding mode includes performing the search process of the decoding mode using prefetched reference samples.

27. The non-transitory computer-readable storage medium of claim 26, wherein, in order to prefetch the reference sample, the instructions further cause the one or more processors to: Retrieve the reference sample from external memory; and The reference sample is stored in the local memory as the prefetched reference sample.

28. The non-transitory computer-readable storage medium of claim 26, wherein the decoding mode uses fractional reference pixels, and wherein the instructions further cause the one or more processors to: An interpolation process is performed on the pre-fetched reference samples before decoding the video data block.

29. The non-transitory computer-readable storage medium of claim 26, wherein the decoding mode is one of template matching (TM) predictive decoding mode, bilateral matching (BM) predictive decoding mode, or decoder-side motion vector refinement (DMVR) decoding mode.

30. The non-transitory computer-readable storage medium of claim 26, wherein the instructions further cause the one or more processors to: Receive a syntax element that indicates the size of the fixed search region.

Images