Bi-directional optical flow sub-block refinement for affine modeled blocks

Abstract

A video decoder may be configured to derive an initial motion vector for a current block of video data; determining whether to apply a multiple iteration bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector based on a size of the current block; determining a modified motion vector of the current block using the single BDOF in response to determining that the single BDOF is applied to the initial motion vector; determining a prediction block of the current block corresponding to the modified motion vector; and using the prediction block to determine a decoded version of the current block.

Description

[0001] This application claims priority to U.S. Patent Application No. 18 / 818,235, filed August 28, 2024, and U.S. Provisional Patent Application No. 63 / 535,885, filed August 31, 2023, the entire contents of each of which are incorporated herein by reference. U.S. Patent Application No. 18 / 818,235 claims the benefit of U.S. Provisional Patent Application No. 63 / 535,885. Technical Field

[0002] This disclosure relates to 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 Video1 (AV1) developed by the Open Media Alliance. By implementing such video decoding technologies, video devices can more efficiently send, receive, encode, decode, and / or store digital video information.

[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] The technology disclosed herein relates generally to decoder-side motion vector derivation techniques (e.g., template matching, bilateral matching, decoder-side MV thinning, bidirectional optical flow (BDOF)), and more specifically to BDOF. Video decoders typically apply multiple operations of BDOF to blocks to determine refined motion vectors that produce potentially better prediction blocks (e.g., prediction blocks that more closely resemble the corresponding original blocks of the video data). For example, as discussed in more detail below, in a first operation, the video decoder may search a first sub-region for a modified motion vector that minimizes the bilateral matching cost between two reference blocks in different reference images to determine a first modified motion vector. For a second operation, the video decoder may search a second modified motion vector in different (e.g., smaller) sub-regions around the prediction block of the first modified motion vector that minimizes the bilateral matching cost between two reference blocks in different reference images. In some examples, the video decoder may perform up to four operations, each improving the quality of the motion vector, such as the quality of the prediction block. These four operations could include, for example, two motion vector search operations based on minimizing the cost of bilateral matching between two reference blocks in different reference images, and two additional operations applying BDOF to the blocks to determine refined motion vectors. However, for blocks with certain characteristics, these multiple operations may introduce additional computational complexity into the video decoding process without producing a corresponding improvement in the quality of the motion vectors.

[0006] According to the technology disclosed herein, a video decoder can be configured to determine whether to apply multiple iterative BDOF or a single BDOF to an initial motion vector based on the size of the current block. By determining whether to apply multiple iterative BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder can utilize multiple iterative BDOF in decoding scenarios where multiple iterative BDOF improves prediction quality, and perform single BDOF for decoding scenarios where multiple iterative BDOF does not significantly improve prediction quality. By performing single BDOF for decoding scenarios where multiple iterative BDOF does not significantly improve prediction quality, the computational complexity of video decoding can be reduced in a way that does not significantly affect decoding quality. Reducing computational complexity may reduce latency, improve battery life of battery-powered devices, and lead to other improvements in device functionality.

[0007] According to one example of this disclosure, a method for decoding video data includes: deriving an initial motion vector for a current block of the video data; determining the application of a single bidirectional optical flow (BDOF) based on the size of the current block; determining a modified motion vector for the current block using the single BDOF in response to determining that the single BDOF is applied to the initial motion vector; determining a predicted block corresponding to the modified motion vector for the current block; and using the predicted block to determine a decoded version of the current block.

[0008] According to one example of this disclosure, an apparatus for decoding video data includes: a memory configured to store video data; one or more processors implemented in a circuit and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; determine, in response to determining to apply the single BDOF to the initial motion vector, a modified motion vector for the current block using the single BDOF; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0009] A computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to: derive an initial motion vector for a current block of video data; determine, based on the size of the current block, to apply a single BDOF to the initial motion vector; determine, in response to determining to apply the single BDOF to the initial motion vector, using the single BDOF to determine a modified motion vector for the current block; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0010] According to one example of this disclosure, an apparatus for encoding video data includes: a memory configured to store video data; one or more processors implemented in a circuit and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; determine a modified motion vector for the current block using the single BDOF in response to determining that the single BDOF is applied to the initial motion vector; determine a prediction block corresponding to the modified motion vector for the current block; use the prediction block to determine a decoded version of the current block; store a copy of a decoded image of the video data including the decoded version of the current block in a decoded image buffer; and use the stored copy of the decoded image of the video data to predict subsequent blocks of the video data.

[0011] According to one example of this disclosure, a method for encoding video data includes: deriving an initial motion vector for a current block of the video data; determining, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; determining, in response to determining to apply the single BDOF to the initial motion vector, using the single BDOF to determine a modified motion vector for the current block; determining a prediction block corresponding to the modified motion vector for the current block; using the prediction block to determine a decoded version of the current block; storing a copy of a decoded image of the video data including the decoded version of the current block in a decoded image buffer; and using the stored copy of the decoded image of the video data to predict subsequent blocks of the video data.

[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 This is a conceptual diagram illustrating spatially adjacent motion vector candidates for merging patterns.

[0015] Figure 2B This is a conceptual diagram illustrating spatially adjacent motion vector candidates for an Advanced Motion Vector Prediction (AMVP) pattern.

[0016] Figure 3A Example Temporal Motion Vector Predictor (TMVP) candidates for the block are shown.

[0017] Figure 3B An example motion vector scaling process is shown.

[0018] Figure 4 This is an example of the template matching process.

[0019] Figure 5 and Figure 6 An example of a bilateral matching process is shown.

[0020] Figure 7 An example search pattern with bilateral matching is shown.

[0021] Figure 8 An example of decoder-side motion vector refinement is shown.

[0022] Figure 9 An example of a diamond-shaped search region that can be used for sub-block-based bilateral matching motion vector refinement is shown.

[0023] Figure 10 An example of the extended decoding unit (CU) region used in bidirectional optical flow (BDOF) is shown.

[0024] Figure 11 An example of control point motion vector inheritance is shown.

[0025] Figure 12 The locations of candidate locations for the affine merging pattern used for construction are shown.

[0026] Figure 13 Search for non-nearest affine CUs and use motion information to derive examples of non-refined candidates.

[0027] Figure 14 An example is shown for deriving the sub-block motion information for refining the candidates.

[0028] Figure 15 This is a flowchart illustrating the AMVP merging mode for non-LDC images.

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

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

[0031] Figure 18 This is a flowchart illustrating an example process for encoding the current block according to the technology of this disclosure.

[0032] Figure 19 This is a flowchart illustrating an example process for decoding the current block according to the technology of this disclosure.

[0033] Figure 20 This is a flowchart illustrating an example process for decoding the current block according to the technology of this disclosure. Detailed Implementation

[0034] Video decoding (e.g., video encoding and / or video decoding) typically involves predicting video data blocks based on decoded video data blocks within the same frame (e.g., intra-frame prediction) or based on decoded video data blocks in different frames (e.g., inter-frame prediction). In some cases, the video encoder also computes residual data by comparing the predicted block to the original block. Therefore, the residual data represents the difference between the predicted block and the original block. To reduce the number of bits required to signal the residual data, the video encoder transforms and quantizes the residual data and signals the transformed and quantized residual data in the encoded bitstream. Compression achieved through the transformation and quantization process can be lossy, meaning that the transformation and quantization process may introduce distortion into the decoded video data.

[0035] The video decoder decodes the residual data and adds it to the predicted blocks to produce a reconstructed video block that more closely matches the original video block compared to individual predicted blocks. Due to losses introduced by the transformation and quantization of the residual data, the first reconstructed block may have distortion or artifacts. A common type of artifact or distortion is called block artifacts, where the boundaries of the blocks used to decode the video data are visible.

[0036] To further improve the quality of the decoded video, the video decoder can perform one or more filtering operations on the reconstructed video blocks. Examples of these filtering operations include deblocking filtering, Sample Adaptive Offset (SAO) filtering, and Adaptive Loop Filtering (ALF). The parameters of these filtering operations can be determined by the video encoder and explicitly signaled in the encoded video bitstream, or they can be implicitly determined by the video decoder without needing to be explicitly signaled in the encoded video bitstream.

[0037] The technology disclosed herein relates generally to decoder-side motion vector derivation techniques (e.g., template matching, bilateral matching, decoder-side MV thinning, bidirectional optical flow (BDOF)), and more specifically to BDOF. Video decoders typically apply multiple operations of BDOF to blocks to determine refined motion vectors that produce potentially better prediction blocks (e.g., prediction blocks that more closely resemble the corresponding original blocks of the video data). For example, as discussed in more detail below, in a first operation, the video decoder may search a first sub-region for a modified motion vector that minimizes the bilateral matching cost between two reference blocks in different reference images to determine a first modified motion vector. For a second operation, the video decoder may search a second modified motion vector in different (e.g., smaller) sub-regions around the prediction block of the first modified motion vector that minimizes the bilateral matching cost between two reference blocks in different reference images. In some examples, the video decoder may perform up to four operations, each improving the quality of the motion vector, such as the quality of the prediction block. These four operations could include, for example, two motion vector search operations based on minimizing the cost of bilateral matching between two reference blocks in different reference images, and two additional operations applying BDOF to the blocks to determine refined motion vectors. However, for blocks with certain characteristics, these multiple operations may introduce additional computational complexity into the video decoding process without producing a corresponding improvement in the quality of the motion vectors.

[0038] According to the technology disclosed herein, a video decoder can be configured to determine whether to apply multiple iterative BDOF or a single BDOF to an initial motion vector based on the size of the current block. By determining whether to apply multiple iterative BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder can utilize multiple iterative BDOF in decoding scenarios where multiple iterative BDOF improves prediction quality, and perform single BDOF for decoding scenarios where multiple iterative BDOF does not significantly improve prediction quality. By performing single BDOF for decoding scenarios where multiple iterative BDOF does not significantly improve prediction quality, the computational complexity of video decoding can be reduced in a way that does not significantly affect decoding quality. Reducing computational complexity may reduce latency, improve battery life of battery-powered devices, and lead to other improvements in device functionality.

[0039] These techniques can be combined with existing video codecs, such as High Efficiency Video Decoding (HEVC), Multi-Functional Video Decoding (VVC), Basic Video Decoding (EVC), or become efficient decoding tools in any future video decoding standard. Unless otherwise stated, it should be assumed that the techniques described herein can be performed by a video encoder or a video decoder. Some aspects of this disclosure will be described only with respect to the video decoder; however, it should be understood that in many cases, such techniques can also be performed by the video decoding loop of a video encoder or other aspects of the video encoder.

[0040] As used in this disclosure, the term video decoding generally refers to video encoding or video decoding. Similarly, the term "video decoder" generally refers to a video encoder or a video decoder. Furthermore, some of the techniques described in this disclosure with respect to video decoding can also be applied to video encoding, and vice versa. For example, video encoders and video decoders are often configured to perform the same or opposite processes. Moreover, video encoders generally perform video decoding (also known as reconstruction) as part of a process of determining how to encode video data. For example, a video encoder may perform deblocking filtering on decoded video blocks to determine whether a particular encoding scheme produces a desired rate-distortion tradeoff and also allows the video encoder to perform motion estimation using the same blocks available to the video decoder when the video decoder performs motion compensation.

[0041] 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. Therefore, video data may include unencoded raw video, encoded video, decoded (e.g., reconstructed) video, and video metadata, such as signaling data.

[0042] like Figure 1As shown, in this example, system 100 includes a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116. Specifically, source device 102 provides the video data to destination device 116 via computer-readable medium 110. Source device 102 and destination device 116 can be or may include any of a wide range of devices, such as desktop computers, laptops (e.g., notebook 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.

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

[0044] like Figure 1 The system 100 shown is merely an example. Typically, any digital video encoding and / or decoding device can perform techniques for decoder-side motion vector derivation (such as BDOF). 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.

[0045] Typically, video source 104 represents a source of video data (e.g., unencoded raw 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.

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

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

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

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

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

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

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

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

[0054] The input interface 122 of the destination device 116 receives an encoded video bitstream from a computer-readable medium 110 (e.g., a communication medium, storage device 112, file server 114, etc.). The encoded video bitstream may include signaling information defined by the video encoder 200 and also used by the video decoder 300, such as syntax elements having values ​​describing the characteristics and / or processing of video blocks or other decoded units (e.g., slices, pictures, picture groups, sequences, etc.). The display device 118 displays a decoded picture of the decoded video data to the user. The display device 118 may represent any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or another type of display device.

[0055] Despite Figure 1Not 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 (e.g., audio codec), 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. Example audio codecs may include AAC, AC-3, AC-4, ALAC, ALS, AMBE, AMR, AMR-WB (G.722.2), AMR-WB+, aptX (various versions), ATRAC, BroadVoice (BV16, BV32), CELT, Enhanced AC-3 (E-AC-3), EVS, FLAC, G.711, G.722, G.722.1, G.722.2 (AMR-WB), G.723.1, G.726, G.728, G.729, G.729.1, GSM-FR, HE-AAC, iLBC, iSAC, LA Lyra, Monkey's Audio, MP1, MP2 (MPEG-1, 2 Audio Layer II), MP3, Musepack, Nellymoser Asao, OptimFROG, Opus, Sac, Satin, SBC, SILK, Siren 7, Speex, SVOPC, True Audio (TTA), TwinVQ, USAC, Vorbis (Ogg), WavPack and Windows Media Aud.

[0056] Both the video encoder 200 and the video decoder 300 can be implemented as any of a variety of suitable encoder and / or decoder circuits comprising a processing system, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the technology is implemented in part in software, the device may store instructions for the software in a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the technology of this disclosure. Each of the video encoder 200 and the video decoder 300 may be included in one or more encoders or decoders, either of which may be integrated as part of a combined encoder / decoder (CODEC) in the respective device. Devices including the video encoder 200 and / or the video decoder 300 may implement the video encoder 200 and / or the video decoder 300 in processing circuitry such as integrated circuits and / or microprocessors. Such devices may be wireless communication devices (such as cellular phones) or any other type of device described herein.

[0057] 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 HEVC) or its extensions such as MultiView 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 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 techniques disclosed herein are not limited to any particular decoding standard or format. Generally, the video encoder 200 and video decoder 300 may be configured to perform the techniques of this disclosure in combination with any video decoding technique using decoder-side motion vector derivation.

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

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

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

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

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

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

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

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

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

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

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

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

[0070] This disclosure uses "NxN" and "N by N" interchangeably to refer to the sample size of a block (such as a CU or other video block) in the vertical and horizontal dimensions, for example, 16x16 samples or 16 by 16 samples. Typically, a 16x16 CU will have 16 samples in the vertical direction (y=16) and 16 samples in the horizontal direction (x=16). Similarly, an NxN 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 NxM samples, where M is not necessarily equal to N.

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

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

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

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

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

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

[0077] 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 residual blocks) represents the sample-wise difference between the predicted blocks of the block, which are formed using the corresponding prediction mode. The video encoder 200 can apply one or more transforms to the residual blocks 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 Mode Correlated Inseparable Quadratic Transform (MDNSST), Signal Correlation Transform, Karhunen-Loeve Transform (KLT), etc. The video encoder 200 produces transform coefficients after applying one or more transforms.

[0078] As noted above, after any transformation that produces the transform coefficients, the video encoder 200 may perform quantization on the transform coefficients. Quantization generally refers to 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.

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

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

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

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

[0083] 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, the CABAC encoding process of the video encoder 200. Syntax elements can define partitioning information for dividing a picture into CTUs and for partitioning each CTU according to a corresponding partitioning structure such as a QTBT structure to define the CUs of the CTU. Syntax elements can further define prediction and residual information for video data blocks (e.g., CUs).

[0084] 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 (sample-by-sample) 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.

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

[0086] As described above, the video encoder 200 and video decoder 300 can be configured to perform motion vector prediction. In HEVC, there are two inter-frame prediction modes for the PU, named Merge Mode (skipping special cases considered as merges) and AMVP Mode. In both AMVP and Merge Modes, the video encoder 200 and video decoder 300 maintain a candidate list of motion vectors (MVs) for multiple motion vector predictors. The motion vector of the current PU in Merge Mode, along with its reference index, is generated by selecting a candidate from the MV candidate list.

[0087] In a specific implementation of HEVC, the MV candidate list includes up to five merge mode candidates and two AMVP mode candidates. The merge candidates may contain a set of motion information, such as motion vectors corresponding to both the reference image list (list 0 and list 1) and the reference index. By receiving the merge candidates identified by the merge index, the video decoder 300 determines the reference image and associated motion vector for prediction of the current block. On the other hand, in AMVP mode, for each possible prediction direction from list 0 or list 1, the video decoder 300 receives the MV predictor factor (MVP) index of the MV candidate list, since the AMVP candidates only include motion vectors. The video decoder 300 additionally receives the motion vector difference (MVD) and the reference index to explicitly identify the reference image. In AMVP mode, the predicted motion vectors can be further refined.

[0088] Candidates for both patterns are similarly derived from adjacent blocks with the same spatial and temporal characteristics. For example... Figure 2A and Figure 2B As shown, in HEVC, for a specific PU (PU0), the video encoder 200 and the video decoder 300 can derive spatial MV candidates from adjacent blocks, although the techniques for generating candidates from blocks differ for merge mode and AMVP mode.

[0089] Figure 2A This is a conceptual diagram showing the spatial adjacency candidates for the merging pattern of block 140. Figure 2B This is a conceptual diagram illustrating the spatial adjacency candidates for block 142 in AMVP mode. In merge mode, video encoder 200 and video decoder 300 can, according to... Figure 2A The order shown is derived to up to four spatial MV candidates. The order is as follows: left block (0, A1), top block (1, B1), top right block (2, B0), bottom left block (3, A0), and top left block (4, B2).

[0090] In AMVP mode, the video encoder 200 and video decoder 300 can divide adjacent blocks into two groups: such as Figure 2B As shown, the left group includes blocks 0 and 1, and the upper group includes blocks 2, 3, and 4. For each group, potential candidates in adjacent blocks that reference the same reference image indicated by a reference index emitted by a signal have the highest priority to be selected to form the final candidate for that group. All adjacent blocks may not contain motion vectors pointing to the same reference image. Therefore, if no such candidate can be found, the video encoder 200 and video decoder 300 can scale the first available candidates to form the final candidate. Thus, temporal distance differences can be compensated.

[0091] Temporal motion vector prediction in HEVC will now be discussed. The video encoder 200 and video decoder 300 can be configured to add Temporal Motion Vector Predictor (TMVP) candidates (if enabled and available) to the MV candidate list following the spatial motion vector candidates. The motion vector derivation process for TMVP candidates is the same for both merge and AMVP modes. However, in HEVC, the target reference index of the TMVP candidate is set to 0 in merge mode.

[0092] Figure 3A Example TMVP candidates for block 154 (PU0) are shown, and Figure 3B The motion vector scaling process 156 is shown. The principal block position in the TMVP candidate derivation is the lower right block outside the PU. This candidate is in Figure 3A The block is designated as "T". The position of block T is used to compensate for the deviation of the upper and left blocks used to generate spatially adjacent candidates. However, if the block is located outside the current CTB line or motion information is unavailable, the block is replaced by the center block of the PU.

[0093] The video encoder 200 and video decoder 300 can derive the motion vectors of TMVP candidates from the co-located PUs of the co-located images indicated in the slice level. The motion vectors of the co-located PUs are called co-located MVs. Similar to the temporal direct mode in AVC, such as... Figure 3B As shown, in order to derive the TMVP candidate motion vector, the co-located MV can be scaled to compensate for the time distance difference.

[0094] Further aspects of motion prediction in HEVC, the technique described herein, will now be described. The video encoder 200 and video decoder 300 are configured to perform motion vector scaling. It is assumed that the value of a motion vector is proportional to the distance between images during rendering. The motion vector associates a reference image and 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.

[0095] For a motion vector to be predicted, the associated containment image may differ from the reference image. Therefore, the video encoder 200 and video decoder 300 can compute a new distance based on the point of view (POC). The video encoder 200 and video decoder 300 can then scale the motion vector based on these two POC distances. For spatially adjacent candidates, the containment images of the two motion vectors are the same, while the reference images are different. In HEVC, motion vector scaling is applied to both TMVP and AMVP for spatially and temporally adjacent candidates.

[0096] The video encoder 200 and video decoder 300 can be configured to perform artificial motion vector candidate generation. If the list of motion vector candidates is incomplete, artificial motion vector candidates are generated and inserted at the end of the list until the list is full.

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

[0098] The video encoder 200 and video decoder 300 can be configured to perform a pruning process for candidate insertion. Candidates from different blocks may happen to be the same, which reduces the efficiency of merging / AMVP candidate lists. A pruning process is applied to address this issue. When implementing the pruning process, the video encoder 200 or video decoder 300 compares a candidate with other candidates in the current candidate list to avoid inserting the same candidate to some extent. To reduce complexity, only a limited number of pruning processes are applied, rather than comparing every potential pruning process with all other existing pruning processes.

[0099] The video encoder 200 and video decoder 300 can be configured to perform template matching prediction. Template matching prediction is a special merging mode based on Frame Rate Boosting Conversion (FRUC) technology. Using this mode, partial motion information of a block is signaled but derived at the decoder side. Template matching can be applied to both AMVP mode and regular merging mode. In AMVP mode, MVP candidate selection is determined based on template matching to select a candidate that achieves the minimum difference between the current block template and the reference block template. In regular merging mode, a template matching mode flag is signaled to indicate the use of template matching. The video encoder 200 and video decoder 300 can then apply template matching to the merging candidates indicated by the merging index for MV refinement.

[0100] like Figure 4As shown, template matching is used to derive motion information of the current CU 160 by finding the closest match between the current template 162 in the current image and the reference template 164 in the reference image (which may have the same size as the current template 162). Using AMVP candidates selected based on the initial matching error, the video encoder 200 and video decoder 300 can refine the MVP using template matching. Utilizing the merging candidates indicated by the signaled merging index, the video encoder 200 and video decoder 300 can be configured to independently refine the MV corresponding to L0 and L1 via template matching, and then further refine the less accurate MV based on the more accurate MV.

[0101] The video encoder 200 and video decoder 300 can be configured to implement the cost function. Motion-compensated interpolation is required when motion vectors are localized to fractional samples. To reduce complexity, bilinear interpolation is used instead of conventional 8-tap DCT-IF interpolation for template matching to generate a template on the reference image. The matching cost of template matching... The calculation is as follows:

[0102]

[0103] in, It is a weighting factor set to 4 based on experience. 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), respectively. SAD is used as the matching cost for template matching.

[0104] 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-frame prediction. After determining MV, the final MC is performed using an 8-tap interpolation filter for luma and a 4-tap interpolation filter for chroma.

[0105] The video encoder 200 and video decoder 300 can be configured to implement the search process. MV refinement is a pattern-based MV search criterioned by template matching cost, supporting two search modes: diamond search and cross search. The MV is searched directly with MVD accuracy at one-quarter luminance sample level of the diamond pattern, then with MVD accuracy at one-quarter luminance sample level of the cross pattern, and finally refined with MVD accuracy at one-eighth luminance sample level of the cross pattern. The search range for MV refinement is set to be equal to the (-8, +8) luminance samples surrounding the initial MV.

[0106] Video encoder 200 and video decoder 300 can be configured to perform bilateral matching prediction. Bilateral matching (BM), also known as bilateral merge prediction, is another merging mode based on FRUC technology. When the BM mode is applied to a block, video encoder 200 and video decoder 300 can use signaled merge candidate indices to derive two initial motion vectors MV0 and MV1 to select merge candidates from a constructed merge list. When bilateral matching is performed, video encoder 200 and video decoder 300 search around MV0 and MV1 and derive the final MV0' and MV1' based on the minimum bilateral matching cost.

[0107] The motion vector differences MVD0 (denoted by MV0'-MV0) and MVD1 (denoted by MV1'-MV1) pointing to two reference blocks can be proportional to the temporal distance (TD) between the current image and the two reference images (e.g., TD0 and TD1). Figure 5 Examples of MVD0 and MVD1 are shown, where the distance (TD1) between the current image 170 and the reference image 172 is 4 times the distance (TD0) between the current image 170 and the reference image 174. Figure 5 An example of MVD0 and MVD1 being proportional based on time distance is shown.

[0108] However, there is an alternative design in which MVD0 and MVD1 are mirrored regardless of the time distance between TD0 and TD1. Figure 6 An example of MVD0 and MVD1 being mirrored is shown, regardless of the time distance (TD1) between the current image 176 and the reference image 178 and the time distance (TD0) between the current image 176 and the reference image 180. Figure 6 An example of mirrored MVD0 and MVD1 is shown, where TD1 is 4 times that of TD0.

[0109] Figure 7 An example of a 3×3 square search pattern within a search range of [-8, 8] is shown for implementing bilateral matching. When implementing bilateral matching, the video encoder 200 and video decoder 300 can be configured to perform a local search around the initial MV0 and MV1 to derive the final MV0' and MV1'. Figure 7In the example, the initial MV points to sample 182, and the final MV points to sample 184. The local search applies a 3×3 square search pattern to cycle within the search range [-8, 8]. Sample 186 represents a sample example within the search range surrounding samples 182, 184, and 188. Sample 188 represents a sample example corresponding to the MV determined during an intermediate iteration of the search process. In each search iteration, the bilateral matching cost of the eight surrounding MVs in the search pattern is calculated and compared to 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 local search terminates 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.

[0110] Video encoder 200 and video decoder 300 can be configured to perform decoder-side motion vector refinement (DMVR). In VVC, DMVR can be applied to increase the accuracy of the MV in the merged mode. In bidirectional prediction operation, a refined MV is searched around the initial MV in reference image lists L0 and L1. The DMVR process calculates the distortion between two candidate blocks in reference image lists L0 and L1.

[0111] Figure 8 An example of decoder-side motion vector refinement is shown. For example... Figure 8 As illustrated, the video encoder 200 and video decoder 300 can be configured to calculate the SAD between blocks 190 and 192 based on each MV candidate surrounding the initial MV. The MV candidate with the lowest SAD becomes the refined MV and is used to generate the bidirectional prediction signal.

[0112] The refined MV derived from the DMVR process is used to generate inter-frame prediction samples and also for temporal motion vector prediction in future image decoding. The original MV is used in the deblocking process and also for spatial motion vector prediction in 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.

[0113] The video encoder 200 and video decoder 300 can be configured to implement a search scheme. In DVMR, the search point is around the initial MV and the MV offset follows the MV difference mirroring rule. In other words, any point checked by DMVR, represented by the candidate MV pair (MV0, MV1), follows the following two equations:

[0114]

[0115]

[0116] in, This represents the refinement offset between the initial MV and the refined MV in one of the reference images. In DMVR, the refinement search range is two integer luminance samples from the initial MV. The search includes an integer sample offset search phase and a fractional sample refinement phase.

[0117] The video encoder 200 and video decoder 300 can be configured to apply a 25-point full search for integer sample offset search. First, the SAD of the initial MV pair is calculated. If the SAD of the initial MV pair is less than a threshold, the integer sample offset search phase of the DMVR terminates. Otherwise, the SAD of the remaining 24 points is calculated and checked according to the raster scan order. The point with the minimum SAD is selected as the output of the integer sample offset search phase. To reduce the loss of 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 reference is reduced by 1 / 4 of the SAD value.

[0118] Following the integer sample search, the video encoder 200 and video decoder 300 can be configured to perform fractional sample refinement. To save computational complexity, fractional sample refinement is derived using parametric error surface equations 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 search.

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

[0120]

[0121] in( This corresponds to the fractional location with the minimum cost, and C corresponds to the minimum cost value. The above equation is solved by using the cost values ​​of the five search points. The calculation is as follows:

[0122]

[0123]

[0124] and The value is automatically constrained between -8 and 8 because all cost values ​​are positive and the minimum value is 8. This corresponds to a half-pixel offset with 1 / 16 pixel MV precision in VVC. The calculated score ( Added to integer distance thinning MV to obtain subpixel accurate thinning increment MV.

[0125] Video encoder 200 and video decoder 300 can be configured to perform bilinear interpolation and sample padding. In VVC, the maximum 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 samples at those fractional localizations need to be interpolated for 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, given 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 padded from those available samples.

[0126] The video encoder 200 and video decoder 300 can be configured to implement one or more enabling conditions for DMVR. In one example, the video encoder 200 and video decoder 300 can be configured to enable DMVR when all of the following conditions are met (e.g., present or true).

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

[0128] • A reference image is in the past, while another reference image is in the future, relative to the current image.

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

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

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

[0132] • BCW weight index indicates equal weights

[0133] • WP is not enabled in the current block

[0134] • The current block does not use the combined intra-frame and inter-frame prediction (CIIP) mode.

[0135] The video encoder 200 and video decoder 300 can be configured to perform multiple operations, such as decoder-side motion vector refinement, as in ECM. In the first operation, the video decoder 300 may apply bilateral matching (BM) to the decoded block. In the second operation, the video decoder 300 may apply BM to each 16×16 sub-block within the decoded block. In the third operation, the video decoder 300 may refine the motion vectors (MVs) in each 8×8 sub-block by applying bidirectional optical flow (BDOF). The refined MVs are stored for spatial motion vector prediction and temporal motion vector prediction.

[0136] For the first operation, the video decoder 300 performs block-based bilateral matching MV refinement. In the first operation, the refined MV is derived by applying the BM to the decoded block. Similar to DMVR, in the bidirectional prediction operation, a refined MV is searched around the two initial MVs (MV0 and MV1) in the reference picture lists L0 and L1. The refined MV (MV0_pass1 and MV1_pass1) is derived around the initial MVs based on the minimum bilateral matching cost between the two reference blocks in L0 and L1.

[0137] For BM, the video decoder 300 performs a local search to derive the integer sample precision intDeltaMV. The local search applies a 3×3 square search pattern to cycle through the horizontal search range [–sHor, sHor] and the vertical search range [–sVer, sVer], where the values ​​of sHor and sVer are determined by the block dimension, and the maximum value of sHor and sVer is 8.

[0138] The cost of bilateral matching can be calculated as follows: bilCost = mvDistanceCost + sadCost. When the block size is cbW... When cbH is greater than 64, the MRSAD cost function is applied to eliminate the DC effect of distortion between reference blocks. The local search for intDeltaMV terminates when bilCost at the center point of the 3×3 search pattern has the minimum cost. Otherwise, the current minimum cost search point becomes the new center point of the 3×3 search pattern, and the search for the minimum cost continues until the end of the search range is reached.

[0139] Video decoder 300 is encountering an error! Reference source not found. The current fractional sample refinement is used to derive the final deltaMV. Then, the refined MV after the first operation can be derived as follows:

[0140] • MV0_pass1 = MV0 + deltaMV

[0141] • MV1_pass1 = MV1 – deltaMV

[0142] For the second operation, the video decoder 300 performs sub-block-based bilateral matching MV refinement. In the second operation, the refined MV is derived by applying the BM to 16×16 grid sub-blocks. For each sub-block, the refined MV is searched around the two MVs (MV0_pass1 and MV1_pass1) obtained in the first operation in the reference image lists L0 and L1. The refined MV (MV0_pass2(sbIdx2) and MV1_pass2(sbIdx2)) is derived based on the minimum bilateral matching cost between the two reference sub-blocks in L0 and L1.

[0143] For each sub-block, the video decoder 300 implements BM by performing a full search to derive integer sample precision intDeltaMV. The full search has a search range of [-sHor, sHor] in the horizontal direction and a search range of [-sVer, sVer] in the vertical direction, where the values ​​of sHor and sVer are determined by the block size, and the maximum value of sHor and sVer is 8.

[0144] The bilateral matching cost is calculated by applying a cost factor to the sum of absolute transformation differences (SATD) cost between the two reference subblocks, as follows: bilCost = satdCost costFactor. Figure 9 An example diamond search region 193 is shown for multiple decoder-side motion refinement. The search region (2...) sHor + 1) (2 sVer + 1) is divided into 5 diamond-shaped search areas, such as Figure 9 As shown. Each search region is assigned a costFactor, which is determined by the distance (intDeltaMV) between each search point and the starting MV. Each diamond-shaped region is processed sequentially, starting from the center of the search region. Within each region, search points are processed in raster scan order from the top left corner to the bottom right corner. When the minimum bilCost within the current search region is less than a threshold (which is equal to sbW), the search is considered successful. If sbH is reached, the integer pixel full search terminates. Otherwise, the integer pixel full search continues to the next search area until all search points have been checked.

[0145] The video decoder 300 can apply existing VVC DMVR fractional sample refinement to derive the final deltaMV(sbIdx2). The refined MV from the second operation is then derived as follows:

[0146] • MV0_pass2(sbIdx2) = MV0_pass1 + deltaMV(sbIdx2)

[0147] • MV1_pass2(sbIdx2) = MV1_pass1 – deltaMV(sbIdx2)

[0148] For the third operation, the video decoder 300 performs sub-block-based BDOF MV thinning. In the third operation, the thinned MV is derived by applying BDOF to 8×8 raster sub-blocks. For each 8×8 sub-block, BDOF thinning is applied to derive scaled Vx and Vy, without truncating from the thinned MV of the parent-child block from the second operation. The derived bioMv(Vx,Vy) is rounded to 1 / 16 sample precision and truncated to between -32 and 32.

[0149] The video decoder 300 can derive the refined MV (MV0_pass3(sbIdx3) and MV1_pass3(sbIdx3)) during the third operation as follows:

[0150] • MV0_pass3(sbIdx3) = MV0_pass2(sbIdx2) + bioMv

[0151] • MV1_pass3(sbIdx3) = MV0_pass2(sbIdx2) – bioMv.

[0152] The video encoder 200 and video decoder 300 can be configured to implement bidirectional optical flow (BDOF). Bidirectional optical flow (BDOF) is used to refine bidirectional prediction signals of luminance samples in the CU at the 4×4 sub-block level. As its name suggests, the BDOF mode is based on the optical flow concept, which assumes that the motion of the object is smooth. For each 4×4 sub-block, motion refinement is calculated by minimizing the difference between the L0 and L1 prediction samples. Then, motion refinement is used to adjust the bidirectional prediction sample values ​​in the 4x4 sub-blocks. The following steps are applied during the BDOF process.

[0153] First, the video encoder 200 and the video decoder 300 calculate the horizontal gradient of the two predicted signals by directly calculating the difference between two adjacent samples. and vertical gradient ),Right now,

[0154]

[0155] in, It is a list Coordinates of the predicted signal in ) The sample value at that location is used to calculate shift1 based on the luminance bit depth bitDepth, since shift1 is set to equal to 6.

[0156] Then, the video encoder 200 and the video decoder 300 can calculate the gradient. , , , and The autocorrelation and cross-correlation terms are as follows:

[0157]

[0158] in

[0159]

[0160] in It is a 6x6 window surrounding a 4x4 sub-block, with shift2 set to 4 and shift3 set to 1.

[0161] Then, the video encoder 200 and the video decoder 300 can derive motion refinement using cross-correlation and autocorrelation terms as follows. :

[0162]

[0163] in, . It is the floor function.

[0164] Based on motion refinement and gradients, the video encoder 200 and video decoder 300 can compute the following adjustments for each sample in a 4×4 sub-block:

[0165]

[0166] Finally, the video encoder 200 and the video decoder 300 calculate the BDOF samples of the CU by adjusting the bidirectional prediction samples as follows:

[0167]

[0168] In this context, shift5 is set to equal Max(3, 15 - BitDepth), and the variable... It is set to equal to (1 << (shift5 - 1)).

[0169] These values ​​were chosen to ensure that the multiplier in the BDOF process does not exceed 15 bits, and that the maximum bit width of the intermediate parameters in the BDOF process remains within 32 bits.

[0170] To derive the gradient value, some prediction samples need to be generated. These predicted samples are in the list () is located outside the current CU boundary. For example... Figure 10 As depicted, the BDOF process uses an extended row and column around the CU boundary. Figure 10 In the diagram, the CU is shown as a 4×4 block 194, and an extended row and column are shown as a 6×6 surrounding region 196. To control the computational complexity of generating prediction samples outside the boundaries, prediction samples in the extended region (white positioning) are generated by directly taking reference samples at nearby integer locations (using floor() operations on the coordinates) without interpolation, and prediction samples within the CU (grayscale positioning) are generated using a standard 8-tap motion-compensated interpolation filter. These extended sample values ​​are used only for gradient calculation. For the remaining steps in the BDOF process, if any sample values ​​and gradient values ​​outside the CU boundaries are needed, these sample values ​​and gradient values ​​are filled in from the nearest neighbors (e.g., repeated).

[0171] The video encoder 200 and video decoder 300 can use BDOF to refine the bidirectional prediction signal of the CU at a 4×4 sub-block level. BDOF is applied to the CU if all of the following conditions are met:

[0172] • Decode the CU using a "true" bidirectional prediction mode, where one of the two reference images is displayed before the current image, and the other reference image is displayed after the current image.

[0173] • Do not use affine mode or ATMVP merge mode to decode CU.

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

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

[0176] • BCW weight index indicates equal weights

[0177] • WP is not currently enabled in the CU.

[0178] • CIIP mode is not used in the current CU

[0179] The video encoder 200 and video decoder 300 can be configured to perform BDOF using multi-interactive MV refinement. JVET-AE0065 proposes a procedure for "Iterative BDOF sub-operations in multi-operation DMVR" and includes it in the ECM. This procedure proposes to extend the multi-operation DMVR by adding a fourth BDOF MV refinement sub-operation. The maximum sub-block size of the third BDOF MV refinement sub-operation is always 8×8, and when the decoded block size is less than 1024, the maximum sub-block size of the fourth BDOF MV refinement sub-operation is adaptively set to 4×4; otherwise, it is set to 8×8. The fourth BDOF MV refinement sub-operation is skipped when the sub-block derivation in the third BDOF MV refinement sub-operation derives an incremental motion where Vx equals 0 and Vy equals 0.

[0180] The video encoder 200 and video decoder 300 can be configured to implement an affine motion model. The affine motion model can be described as follows:

[0181]

[0182] in( ) is the coordinate ( The motion vectors at positions (a, b, c, d, e, and f) are given, and a, b, c, d, e, and f are six affine parameters. This affine motion model is called a 6-parameter affine motion model. In a typical video decoder, images are divided into blocks for block-based decoding. A block-based affine motion model can also consist of three motion vectors (MVs) at three different positions not on the same line. , and These three locations are typically referred to as control points, and these three motion vectors are called control point motion vectors (CPMVs). When these three control points are located at the three corners of the block, the affine motion can be described as follows:

[0183]

[0184] in, and These are the width and height of the block.

[0185] In the affine mode, video encoder 200 and video decoder 300 can derive different motion vectors for each pixel in a block according to an associated affine motion model. Thus, motion compensation can be performed pixel-by-pixel. However, to reduce complexity, sub-block-based motion compensation is usually adopted, where a block is divided into multiple sub-blocks (which have a smaller block size), and each sub-block is associated with a motion vector for block-based motion compensation. The representative coordinates of the sub-blocks are used to derive the motion vectors of each sub-block. Usually, center positioning is used. In one example, the block is divided into non-overlapping sub-blocks. If the block width is blkW, the block height is blkH, the sub-block width is sbW, and the sub-block height is sbH, then there are blkH / sbH rows of sub-blocks and blkW / sbW sub-blocks in each row. For a six-parameter affine motion model, the motion vector (referred to as sub-block MV) for the sub-block at the i-th row (0 <= i < blkW / sbW) and the j-th (0 <= j < blkH / sbH) column is derived as follows:

[0186]

[0187] The sub-block MV is rounded to a predefined precision and stored in a motion buffer for motion compensation and motion vector prediction.

[0188] The simplified four-parameter affine model (for scaling and rotation motions) is described as follows:

[0189]

[0190] Similarly, the four-parameter affine model for a block can be described by two CPMVs and at two corners (usually the upper left corner and the upper right corner) of the block. Then, the motion field is described as follows:

[0191]

[0192] The sub-block MV at the i-th row and the j-th column is derived as follows:

[0193]

[0194] Video encoder 200 and video decoder 300 can be configured to perform prediction refinement for the affine mode. After performing sub-block-based affine motion compensation, the prediction signal can be refined by adding an offset derived from the gradient of the per-pixel motion and the prediction signal. The offset at position can be calculated as follows:

[0195]

[0196] where respectively, It is the horizontal gradient of the predicted signal, and It is the vertical gradient of the predicted signal. and At the position pixel location The difference between the x and y components of the motion vector at point MV and the sub-block MV is calculated. The coordinates of the top-left sample of the sub-block are defined as follows: ), and the center of the sub-block is Given affine motion parameters a, b, c, and d, and It can be derived as follows:

[0197]

[0198]

[0199] In the affine motion model based on control points, the affine motion parameters a, b, c, and d are calculated according to CPMV as follows:

[0200]

[0201]

[0202]

[0203]

[0204] The video encoder 200 and video decoder 300 can be configured to implement an affine merging mode. In the affine merging mode of VVC, the CPMV of the current CU is generated based on the motion information of spatially adjacent CUs. Up to five candidates can exist, and an index is signaled to indicate the candidate to be used for the current CU. The following three types of candidates are used to form the affine merging candidate list:

[0205] – Affine merging candidates inherited from CPMV extrapolated from adjacent CUs

[0206] – Affine merging candidate constructed using translational MV of adjacent CUs

[0207] – Zero MV

[0208] In VVC, when identifying adjacent affine CUs, the video encoder 200 and / or video decoder 300 can use the CPMV of the adjacent affine CUs to deduce inherited affine merge candidates in the affine merge list of the current CU. For example... Figure 11 As shown, if the adjacent lower-left block A of the current (cur) CU 400 is decoded in affine mode, then the motion vectors of the upper-left, upper-right, and lower-left corners of CU 402, including block A, are obtained. , and When block A is decoded using a 4-parameter affine model, the video encoder 200 and / or video decoder 300 determine the motion vectors. and To calculate the two CPMVs of the current CU 400. In the case of decoding using a 6-parameter affine model in block A, the video encoder 200 and / or video decoder 300, according to... , and To calculate the three CPMVs of the current CU 400.

[0209] The constructed affine candidate means building the candidate by combining the adjacent translational motion information of each control point. Figure 12 The motion information of the control point is derived from the specified spatial neighbors (A0, A1, A2, B0, B1, B2, and B3) and temporal neighbors (T) of the current block 410. CPMV k (k=1, 2, 3, 4) represents the k-th control point. For CPMV1, the video encoder 200 and / or video decoder 300 check the B2->B3->A2 blocks in this order and use the motion vector of the first available block. For CPMV2, the video encoder 200 and / or video decoder 300 check the B1->B0 blocks in this order. For CPMV3, the video encoder 200 and / or video decoder 300 check the A1->A0 blocks in this order. A TMVP candidate can be used as CPMV4 (if available).

[0210] After obtaining the motion vectors of the four control points, the video encoder 200 and / or video decoder 300 construct affine merging candidates based on this motion information. The following combinations of CPMV are used in sequence to construct the affine candidates:

[0211] {CPMV1, CPMV2, CPMV3}, {CPMV1, CPMV2, CPMV4}, {CPMV1, CPMV3, CPMV4}, {CPMV2, CPMV3, CPMV4}, { CPMV1, CPMV2}, { CPMV1, CPMV3}

[0212] Combining three CPMVs constructs a 6-parameter affine merging candidate, while combining two CPMVs constructs a 4-parameter affine merging candidate. To avoid motion scaling, the video encoder 200 and / or video decoder 300 can discard relevant combinations of CPMVs if the reference indices of the control points are different.

[0213] After checking the inherited affine merge candidates and the constructed affine merge candidates, if the list is still not full, the video encoder 200 and / or the video decoder 300 may insert a zero motion vector at the end of the list (e.g., until the list reaches a predetermined number of candidates).

[0214] The video encoder 200 and video decoder 300 can be configured to implement an affine AMVP mode. In VVC, an affine flag is signaled in the bitstream at the CU level to indicate whether affine AMVP mode is used, and then another flag is signaled to indicate whether it is a 4-parameter affine or a 6-parameter affine. In affine AMVP mode, the motion vector difference (MVD) between the current CU's CPMV and its predictor CPMVP is signaled in the bitstream along with the index of the predictor and the index of the selected reference picture for each applicable prediction direction. In the case of 4-parameter affine, two MVDs are signaled for each applicable prediction direction. In the case of 6-parameter affine, three MVDs are signaled for each available prediction direction. During decoding, the second and third (in the case of 6-parameter affine) MVDs are further predicted from the first MVD. Therefore, for a 6-parameter affine, the difference between the second and first MVDs is signaled in the bit stream instead of the second MVD, and the difference between the third and first MVDs is signaled in the bit stream instead of the third MVD. Note that the inter-frame prediction direction is signaled in advance to indicate whether it is a bidirectional prediction, a unidirectional prediction based on reference picture list 0, or a unidirectional prediction based on reference picture list 1.

[0215] In VVC, the size of the affine AVMP candidate list is generated by sequentially using the following four types of CPMVP candidates:

[0216] – Affine AMVP candidates inherited from CPMV extrapolated from adjacent CUs

[0217] – Affine AMVP candidate CPMVP constructed using translational MV derivation of adjacent CUs

[0218] – Translation MV from adjacent CU

[0219] – Zero MV

[0220] The checking order for inherited affine AMVP candidates is the same as that for inherited affine merge candidates. The only difference is that, for AVMP candidates, only affine CUs with the same reference image as those in the current block are considered. No pruning process is applied when inserting inherited affine motion predictors into the candidate list.

[0221] The constructed AMVP candidate is derived from specified spatial neighbors. The same checking order as used for constructing the affine merge candidate is employed. Additionally, the reference picture indices of adjacent blocks are checked. The first block in the checking order, which is inter-frame decoded and has the same reference picture as the current CU, is used. When the current CU decodes using a 4-parameter affine mode, only one candidate exists, and and Both are available, and both are added as candidates in the affine AMVP list. They are added as candidates in the affine AMVP list when the current CU uses a 6-parameter affine mode for decoding and all three CPMVs are available. Otherwise, the constructed AMVP candidates are set to unavailable.

[0222] If the list of affine AMVP candidates is still less than the maximum number after inserting valid inherited and constructed AMVP candidates, then they can be added in order. , and As a translation MV, predict all control point MVs of the current CU (if available). Finally, if the affine AMVP list is still not full, use zero MV to fill the affine AMVP list.

[0223] The video encoder 200 and video decoder 300 can be configured to utilize affine merging candidates based on linear regression. ECM 6.0 employs the derivation process for affine merging candidates based on linear regression proposed in JVET-AA0107. This proposal derives two types of affine merging candidates based on linear regression: non-refined candidates and refined candidates. The derivation process is identical for both types of candidates, differing only in the use of different sub-block motion information as input.

[0224] Figure 13 This is a conceptual diagram illustrating an example of a non-neighboring spatially adjacent block used to derive non-neighboring affine candidates. For non-refined candidates, only the sub-block motion information of the non-neighboring affine CUs is used as input to the linear regression process. Figure 3 shows an example of the input for the linear regression process used to derive affine merging candidates based on non-refined linear regression. As described above regarding BDOF, certain scanning patterns can be used to search for non-neighboring affine CUs. Once the non-neighboring affine CUs are identified, such as... Figure 13 As shown in the example, it includes {(mv x0 , mv y0 ), (mv x1 , mv y1 ), …, (mv xN-1 , mv yN-1 The sub-block motion vectors are represented by {(x0, y0), (x1, y1), …, (x)} and are derived from {(x0, y0), (x1, y1), …, (x)}.N-1 , y N-1 The motion information of each sub-block in the sub-block motion information of the center coordinates represented by )} is input into the linear regression process to derive the non-refined affine merging candidate.

[0225] The scanning order can be followed Figure 13 The order in which they are depicted. For example, non-nearest affine CUs may follow... Figure 13 The scanning order is determined by the distance (e.g., from near to far) between the current block 420 and its non-nearest neighbor blocks. At specific distances, the video encoder 200 or video decoder 300 can scan horizontally from right to left and vertically from bottom to top.

[0226] By using scanning patterns such as those described above or different scanning patterns, non-nearby affine CUs can be identified, and their corresponding motion vector fields can potentially be used as inputs to a linear regression process to derive the affine model of the current CU.

[0227] Figure 14 An example is shown for deriving sub-block motion information for refinement candidates. For refinement candidates, in addition to motion information from sub-block 430 in non-neighboring affine CUs (such as...), Figure 12 In addition to (as shown), motion information from template sub-block 432 may be additionally included as input to the linear regression process.

[0228] The linear regression process used to derive both the non-refined and refined candidates is the same, following the mathematical derivation discussed in Chapter 1.6. The only difference lies in which sub-block information is used as input to the linear regression process.

[0229] Video encoder 200 and video decoder 300 can be configured to perform a bilateral matching AMVP merging mode, such as in ECM. The bilateral predictor consists of an AMVP predictor in one direction and a merging predictor in the other. When the selected merging predictor and AMVP predictor satisfy the DMVR condition, the mode can be enabled in the decoding block, where there is at least one reference image from the past and one reference image from the future relative to the current image, and both reference images are equidistant from the current image. Bilateral matching MV refinement is applied starting from the merging MV candidate and the AMVP MVP. Otherwise, if template matching functionality is enabled, template matching MV refinement is applied to the merging predictor or AMVP predictor with the higher template matching cost. The pipeline for the AMVP merging mode is as follows: Figure 15 exemplified.

[0230] exist Figure 15In the AMVP merging pattern, the process begins at 500. Then, the video encoder 200 and video decoder 300 can construct reference image pairs for the AMVP merging pattern (502). The video encoder 200 and video decoder 300 can generate an AMVP candidate list for one prediction direction (504) and a merge candidate list for another prediction direction (506). In some examples, the video encoder 200 and video decoder 300 can perform a bilateral matching-based merge candidate list reordering on the AMVP candidate list and / or merge candidate list (508). The video encoder 200 and video decoder 300 can perform bilateral matching-based refinement (510) if the candidates have equal POC distances and template matching-based refinement (512) if the candidates have unequal POC distances. The term "true bilateral equal POC distance" refers to a case where one reference image has a POC smaller than the current image's POC and another reference image has a POC larger than the current image's POC.

[0231] The AMVP part of the signaling notification pattern is a regular one-way AMVP, i.e., the signaling notification reference index and MVD, and it has the derived MVP index if template matching is used or when template matching is disabled.

[0232] For the AMVP direction LX, where X can be 0 or 1, the merging portion in the other direction (1-LX) is implicitly derived by minimizing the bilateral matching cost between the AMVP predictor and the merging predictor (i.e., a pair of AMVP and merging motion vectors). For each merging candidate in the merging candidate list that has a motion vector in the other direction (1-LX), the bilateral matching cost is computed using the merging candidate MV and the AMVP MV. The merging candidate with the minimum cost is selected. Starting with the selected merging candidate MV and AMVP MV, bilateral matching refinement is applied to the decoded block.

[0233] The third operation of the multiple DMVR is the refinement of the 8x8 sub-PU BDOF of the multiple DMVR, which enables the AMVP merge mode decoder block. This mode is indicated by a flag, and if this mode is enabled, the AMVP direction LX is further indicated by another flag.

[0234] Existing techniques may present several problems. In the current version of ECM, a bidirectional optical flow (BDOF) process is used to refine motion vectors at the 8×8 or 4×4 sub-block level. Motion refinement is derived by minimizing the difference between L0 and L1 prediction samples in the extended brightness sample region. Motion refinement This is then used to adjust each predicted sample in the 4×4 sub-block. The initial motion vector for each sub-block can be the motion vector of the current block or a bilaterally matched DMVR-refined motion vector at the 16×16 sub-block level. The BDOF-refined motion vector is stored and used for motion vector prediction of future blocks. The BDOF-refined motion vector is used to derive the bidirectional prediction signal for the luminance and chrominance samples in the current block.

[0235] BDOF is also used to refine the bidirectional prediction signal of luminance samples in the decoded block at the pixel level. Motion refinement is derived by minimizing the difference between the L0 and L1 prediction samples in the extended luminance sample region. Motion refinement Then it is used to adjust each predicted sample of the current block.

[0236] When the current block is an affine block, sub-block motion vectors are derived from the affine model. These sub-block motion vectors are used to derive the bidirectional prediction signals for the luminance and chrominance samples in the current block. However, BDOF sub-block motion vector refinement is not applied to affine decoded blocks or TMVP decoded blocks in which the block or sub-regions of the block satisfy the BDOF condition.

[0237] This disclosure describes the process of applying BDOF subblock motion vector (MV) refinement when deriving the initial MV of a subblock from an affine model, where the current block is an affine block and the subblock MV is derived by applying the affine model at M×N subblock levels, for example, M=4 and N=4. Subsets of subblocks sharing the same MV can be refined by applying BDOF subblock MV refinement. This disclosure also describes the process of applying BDOF subblock motion vector (MV) refinement when deriving the initial MV of a subblock from a time-coordinated block, where the current block has one or more subblocks. Subsets of subblocks sharing the same MV can be refined by applying BDOF subblock MV refinement.

[0238] The sub-block MV refined by BDOF can be stored for future block motion prediction. The BDOF-refined sub-block MV can be used to derive the current block's bidirectional prediction signal for luminance samples. BDOF can also be used to refine the bidirectional prediction signal for the current block's luminance samples.

[0239] In some examples, the BDOF-refined subblock MV can be used to derive the current block bidirectional prediction signal for the luminance sample.

[0240] In some examples, BDOF can also be used to refine the bidirectional prediction signal of the chroma samples of the current block.

[0241] In the first example, the video encoder 200 and video decoder 300 can be configured to perform BDOF sub-block refinement on affine blocks. In this example, when a W×H decoding block is determined to be an affine model decoding block and the current block satisfies the conditions for applying Bidirectional Optical Flow (BDOF), the video encoder 200 and video decoder 300 can apply the BDOF process to refine the sub-block motion vectors (MVs) of the decoded block and apply BDOF to refine the bidirectional prediction signal. The initial MV of each sub-block is derived by applying an affine model at the M×N sub-block level. One or more M×N sub-blocks sharing the same MV can be grouped to apply BDOF sub-block refinement at the P×Q sub-block level. The BDOF-refined MVs can be stored for future block motion prediction. The BDOF-refined MVs can be used for the derivation of the current block's bidirectional prediction signal, such as known motion compensation.

[0242] BDOF can also be used to refine the bidirectional prediction signal of luminance samples. BDOF can also be used to refine the bidirectional prediction signal of chrominance samples.

[0243] The example BDOF procedure for an affine block is as follows.

[0244] The current block is determined to be decoded as an affine block. The current decoded block has a size of W×H. The current block is divided into K1 sub-blocks (denoted as AffineSubPu), where each AffineSubPu has a size of M×N, for example, M equals 4 and N equals 4.

[0245] Each sub-block has an MV derived from the affine model and sub-block positioning.

[0246] The proposed BDOF process begins with an input block (named S1), where S1 has a size W_1 × H_1, where the size of S1 is equal to or less than the size of the decoded block, and equal to or greater than the size of AffineSubPu. For example, M ≤ W_1 ≤ W and N ≤ H_1 ≤ H. For MV in reference images 0 and 1, the initial motion vectors of S1 are denoted as MV_S1_L0 and MV_S1_L1, respectively.

[0247] In some examples, when S1 has only one AffineSubPu, the MV of AffineSubPu is used as MV_S1_L0 and MV_S1_L1.

[0248] In some examples, when S1 has more than one AffineSubPu, each AffineSubPu has the same MV. The MV of the AffineSubPu is used as MV_S1_L0 and MV_S1_L1.

[0249] In some examples, when S1 has more than one AffineSubPu, the maximum MV difference between two AffineSubPu is less than a threshold. For example, the sum of the absolute differences of the two MVs in the horizontal and vertical directions is less than the threshold. In one example, the average MV of each AffineSubPu is used as MV_S1_L0 and MV_S1_L1. In another example, the MV of one AffineSubPu is used as MV_S1_L0 and MV_S1_L1, for example, when the AffineSubPu is located at the top left corner of S1, or at the center of S1.

[0250] The input block S1 is divided into K2 sub-blocks (named S2), where S2 has a size W_2 × H_2, and the size of S2 is equal to or less than the size of S1. For example, W_2 ≤ W_1 and H_2 ≤ H_1.

[0251] In some examples, for each S2 (determined by a condition), it is decided whether BDOF should be applied to S2. In some examples, the condition is to check whether the SAD between the two predicted signals in reference image 0 and reference image 1 is less than a threshold. The sub-blocks in this step define basic units to determine whether BDOF should be applied to all samples within that unit.

[0252] When deciding to apply BDOF to S2, the BDOF procedure is used to derive the incremental MV represented as bioMvS2. The MV of S2 is derived as MV_S2_L0 = MV_S1_L0 + bioMvS2, MV_S2_L1 = MV_S1_L1 -bioMvS2. The predicted signal of S2 is derived by using motion compensation of the MV of S2.

[0253] S2 is divided into K3 sub-blocks (named S3), where S3 has a size of W_3 × H_3, and the size of S3 is equal to or smaller than the size of S2. When per-pixel BDOF thinning is applied, W_3 equals H_3 equals 1. For each S3, a BDOF process is applied to derive the thinning motion vector. The refined motion vector is then used to derive the offset for each sample in S3. The predicted signal of S3 is derived by applying the offset to each sample of the predicted signal of S2, corresponding to the location of S3 in S2. In some examples, the offset is applied only to the luminance samples. In some examples, the offset is applied to every available color component.

[0254] The video encoder 200 and video decoder 300 can be configured to perform one-time iterative sub-block MV refinement. In this example, the BDOF process is applied only once to derive the incremental MV of S2. In some examples, S2 has a predetermined size of 4×4, for example, W_2 equals 4 and H_2 equals 4. In some examples, S2 has an adaptive size, with a maximum size of 8×8 and a minimum size of 4×4, which is determined by examining the input block size of S1. A subset of the following conditions can be used to determine the size of S2:

[0255] • When W_1 is greater than 8 but not an integer multiple of 8, or H_1 is greater than 8 but not a multiple of 8, the size of S2 is determined to be 4×4.

[0256] • When W_1 When H_1 is greater than the threshold, W_1 is greater than 8, and H_1 is greater than 8, the size of S2 is determined to be 8×8.

[0257] • When W_1 When H_1 is greater than the threshold, W_1 is greater than 8 and is an integer multiple of 8, and H_1 equals 4, then the size of S2 is determined to be 8×4.

[0258] • When W_1 When H_1 is greater than the threshold, H_1 is greater than 8 and is an integer multiple of 8, and W_1 equals 4, then the size of S2 is determined to be 4×8.

[0259] • When W_1 When H_1 is less than the threshold, the size of S2 is determined to be 4×4.

[0260] The video encoder 200 and video decoder 300 can be configured to perform multiple iterations of sub-block MV refinement. In this example, the BDOF process is applied multiple times.

[0261] The video encoder 200 and video decoder 300 can be configured to perform multiple iterative BDOF processes for the same sub-block size. In some examples, the sub-block size of S2 is determined as described above regarding the refinement of an iterative sub-block MV. Each S2 can be refined by applying the BDOF process multiple times to derive the final incremental MV. For example, in the first application of the BDOF process, the initial MV is MV_S1_L0 and MV_S1_L1, which is then deduced as bioMvS2_1 after the BDOF process. In the second application of the BDOF process, the initial MV is (MV_S1_L0 + bioMvS2_1) and (MV_S1_L1 - bioMvS2_1), which is then deduced as bioMvS2_2 after the BDOF process. When the BDOF process is applied for the Kth time, the initial MV is (MV_S1_L0 + bioMvS2_(K-1)) and (MV_S1_L1 - bioMvS2_(K-1)). After the BDOF process, bioMvS2_K is derived. The final MV of S2 is (MV_S1_L0 + bioMvS2_1 + bioMvS2_2 + … + bioMvS2_K) and (MV_S1_L1 - bioMvS2_1 - bioMvS2_2 - … - bioMvS2_K).

[0262] The video encoder 200 and video decoder 300 can be configured to perform a multi-iterative BDOF process for the reduced sub-block size. In some examples, given an affine decoder block with size W×H, BDOF refinement starts with a sub-block size W_iter1×H_iter1, and the BDOF process is repeated iteratively multiple times, with the sub-block size decreasing after each preceding iteration. The sub-block at the Kth iteration has size W_iterK×H_iterK, where W_iterK ≤ W_iter(K-1) and H_iterK ≤ H_iter(K-1). Where W_iter1 ≤ W and H_iter1 ≤ H. For example, when the decoder block is a 64×64 affine decoder block, the sub-block size at the first iteration is 16×16, at the second iteration it is 8×8, and at the third iteration it is 4×4.

[0263] In the Kth iteration of the BDOF process, given the affine sub-block MV, it is derived from the block affine model and the sub-block location corresponds to the top-left corner location of the block. For example, the center location of the sub-block is used to derive the sub-block MV. The initial MV derivation for each sub-block is as follows:

[0264] Affine_subblock_K_MV_L0 + bioMvIter(K-1) + bioMvIter(K-2) + ...+bioMvIter1

[0265] Affine_subblock_K_MV_L1 - bioMvIter(K-1) - bioMvIter(K-2) - ...-bioMvIter1

[0266] Among them, Affine_subblock_MV_L0 and Affine_subblock_MV_L1 are derived based on the subblock size corresponding to the block and its location (e.g., center position) and the block affine model.

[0267] Here, bioMvIterK is the incremental MV derived from the Kth iteration of the sub-block corresponding to the current sub-block. In other words, the current sub-block is a sub-block of the previous iteration sub-block.

[0268] In the first iteration of the BDOF process, only Affine_subblock_MV_L0 and Affine_subblock_MV_L1 are used as the initial MVs.

[0269] The final MV derivation after K iterations of the BDOF process is as follows:

[0270] Affine_subblock_K_MV_L0 + bioMvIterK + bioMvIter(K-1) + ...+bioMvIter1

[0271] Affine_subblock_K_MV_L1 - bioMvIterK - bioMvIter(K-1) - ...-bioMvIter1

[0272] For example, when the decoding block is a 64×64 affine decoding block, the BDOF process is as follows:

[0273] In the first iteration, the sub-block size is 16×16, and there are 4 sub-blocks that need to be refined using BDOF. Each of these 4 sub-blocks has the following initial MV:

[0274] • Subblock0: Affine_subblock0_1_MV_L0 and Affine_subblock0_1_MV_L1, after the BDOF process, derive the incremental MV bioMvIter1_subblock0.

[0275] • Subblock1: Affine_subblock1_1_MV_L0 and Affine_subblock1_1_MV_L1, after the BDOF process, derive the incremental MV bioMvIter1_subblock1

[0276] • Subblock2: Affine_subblock2_1_MV_L0 and Affine_subblock2_1_MV_L1, after the BDOF process, derive the incremental MV bioMvIter1_subblock2.

[0277] • Subblock3: Affine_subblock3_1_MV_L0 and Affine_subblock3_1_MV_L1, after the BDOF process, derive the incremental MV bioMvIter1_subblock3.

[0278] In the second iteration, the subblock size is 8×8, and subblock0 from the first iteration is divided into 4 subblocks, each of which has the following initial MV:

[0279] • Subblock0: (Affine_subblock0_2_MV_L0 + bioMvIter1_subblock0) and (Affine_subblock0_2_MV_L1 - bioMvIter1_subblock0), after the BDOF process, has its derived increment MVbioMvIter2_subblock0.

[0280] • Subblock1: (Affine_subblock1_2_MV_L0 + bioMvIter1_subblock0) and (Affine_subblock1_2_MV_L1 - bioMvIter1_subblock0), after the BDOF process, have their derived increments MVbioMvIter2_subblock1.

[0281] • Subblock2: (Affine_subblock2_2_MV_L0 + bioMvIter1_subblock0) and (Affine_subblock2_2_MV_L1 - bioMvIter1_subblock0), after the BDOF process, its derivation increment MVbioMvIter2_subblock2

[0282] • Subblock3: (Affine_subblock3_2_MV_L0 + bioMvIter1_subblock0) and (Affine_subblock3_2_MV_L1 - bioMvIter1_subblock0), after the BDOF process, have their derived increments MVbioMvIter2_subblock3.

[0283] In the third iteration, the subblock size is 4×4, and subblock0 from the second iteration is divided into 4 subblocks, each of which has the following initial MV:

[0284] • Subblock0: (Affine_subblock0_3_MV_L0 + bioMvIter1_subblock0 + bioMvIter2_subblock0) and (Affine_subblock0_3_MV_L1 - bioMvIter1_subblock0 - bioMvIter2_subblock0), after the BDOF process, its derived incremental MV bioMvIter3_subblock0

[0285] • Subblock1: (Affine_subblock1_3_MV_L0 + bioMvIter1_subblock0 + bioMvIter2_subblock0) and (Affine_subblock1_3_MV_L1 - bioMvIter1_subblock0 - bioMvIter2_subblock0), after the BDOF process, its derived incremental MV bioMvIter3_subblock0

[0286] • Subblock2: (Affine_subblock2_3_MV_L0 + bioMvIter1_subblock0 + bioMvIter2_subblock0) and (Affine_subblock2_3_MV_L1 - bioMvIter1_subblock0 - bioMvIter2_subblock0), after the BDOF process, its derived incremental MV bioMvIter3_subblock0

[0287] • Subblock3: (Affine_subblock3_3_MV_L0 + bioMvIter1_subblock0 + bioMvIter2_subblock0) and (Affine_subblock3_3_MV_L1 - bioMvIter1_subblock0 - bioMvIter2_subblock0), after the BDOF process, its derived incremental MV bioMvIter3_subblock0

[0288] After three iterations of BDOF refinement, the final MV of the top-left 4×4 sub-block is then derived as follows:

[0289]

[0290]

[0291] The video encoder 200 and video decoder 300 can be configured to perform refined MV storage and affine model storage. When the current block is an affine decoding block, the MV information of each M×N sub-block (e.g., M=N=4) can be stored and used for future blocks, such as future block MV prediction. The affine model of the current block is also stored and used for future block affine model prediction. Here, the affine model is the control point motion vector (CPMV) of the current block.

[0292] In some examples, after BDOF refinement, the final MV of the BDOF refinement for each sub-block can be stored and used for future blocks, e.g., future block MV prediction. In some examples, the block affine model is stored invariantly and used for future block affine model prediction. In some examples, the block affine model is derived from the BDOF-refined sub-block MVs. The derived affine model is stored and used for future block affine model prediction. In one example, as described above regarding linear regression-based affine merging candidates, the affine model is derived using linear regression-based affine model candidate derivation.

[0293] The video encoder 200 and video decoder 300 can be configured to perform high-level syntax control. The proposed process can be controlled by the same BDOF high-level syntax. Alternatively, the proposed process can be controlled by a separate high-level syntax, `affine_bdof_enabled_flag`, which signals at the SPS, VPS, picture header, slice header, or CU level, etc. `affine_bdof_enabled_flag` can conditionally signal according to the BDOF high-level syntax. For example, if BDOF is disabled, `affine_bdof_enabled_flag` will not be signaled in the bitstream and will be inferred as 0 (indicating not enabled).

[0294] The video encoder 200 and video decoder 300 can be configured to implement enable conditions. The techniques of this disclosure can be implemented when the current block is an affine decoding block and satisfies all or a subset of the following conditions:

[0295] • The proposed process is enabled (indicated by the high-level syntax).

[0296] • This block is a bidirectional prediction block.

[0297] • Both reference images have the same resolution as the current image.

[0298] Neither of the two reference images is a long-term reference image.

[0299] • At least one predictor lies on a past reference image relative to the current image, and at least one predictor lies on a future reference image relative to the current image.

[0300] • The two reference images have equal point of origin (POC) distances relative to the current image.

[0301] • The two predictors have equal weights; for example, the parameter value of BCW is equal to BCW_DEFAULT.

[0302] • Local illumination compensation (LIC) is not applied to the current block.

[0303] Enabling conditions may also require meeting one of the following conditions:

[0304] • In some examples, the proposed process is applied when the current block is determined to apply sub-block-based affine motion compensation.

[0305] • In some examples, the proposed procedure is applied when Overlapping Block Motion Compensation (OBMC) is applied to the current block.

[0306] • In some examples, the proposed procedure is applied when the current block is not determined for applying pixel-based affine motion compensation.

[0307] Enabling conditions may also require meeting one or more of the following condition checks:

[0308] • This block is an affine merge decoding block.

[0309] • This block is the AMVP merge mode decoding block.

[0310] • This block is a bilateral matching affine merge code block.

[0311] • This block was not decoded using MVD.

[0312] In some examples, the video encoder 200 and video decoder 300 can be configured to perform BDOF sub-block refinement on Temporal Motion Vector Prediction (TMVP) blocks. In this example, when the current block is a TMVP decoding block, the aforementioned BDOF sub-block refinement is applied to the current block or sub-region. In this case, the initial MV of the BDOF process is the MV of the co-occurring blocks in the time picture.

[0313] In some examples, the sub-region includes blocks that meet the enable conditions described above. In some examples, if a block does not meet the enable conditions described above, it is replaced with the MV of a spatial block, another temporal block, or a default block.

[0314] In some examples, after BDOF refinement, the final MV with BDOF refinement can be stored and used for future blocks, such as future block MV prediction.

[0315] In some examples, the video encoder 200 and video decoder 300 can be configured to perform a simplified BDOF process with respect to motion compensation in extended regions. In this example, a process that reduces the complexity of the BDOF process is implemented. These techniques are applicable to the techniques proposed in this disclosure and also to existing BDOF processes in current ECMs.

[0316] In the current ECM, the sub-block BDOF process requires MC (Modular Conversion) of the extended luma block to derive gradient information. The extended luma block is a block with 3 lines / 3 columns surrounding the sub-block on each side. When the sub-block size is 4×4, the extended luma block size is 10×10, requiring a 10×10 luma area MC. When the minimum MC area design is 4×4, the extended luma block requires a 12×12 luma area MC.

[0317] To reduce the computational complexity of the MC (Motion Block) while considering a design with a minimum 4×4 MC area, the video encoder 200 and video decoder 300 can derive partially expanded luminance blocks via pixel padding. The padding pixels are derived from the nearest pixel derived from the MC.

[0318] Given a sub-block of size subW × subH, the size of the extended luma block is (subW + 6) × (subH + 6), where subW is an integer multiple of 4 and subH is an integer multiple of 4.

[0319] In some examples, the MC region of the sub-block is subW×subH and the surrounding area of ​​3 lines / 3 columns on each side is derived by pixel filling.

[0320] In some examples, the MC region of the sub-block is (subW+4)×(subH+4) and the surrounding area of ​​1 line / 1 column on each side is derived by pixel filling.

[0321] In some examples, when the sub-block size is subW When subH is less than the threshold, the pixel filling process is applied.

[0322] In some examples, when a multi-iteration BDOF process is applied to a decoding block, pixel padding is applied to one or more iterations.

[0323] In the current version of ECM, BDOF MV refinement can be applied to the decoded block in two iterations. As described above, the third operation can have a maximum sub-block size of 8×8, and the fourth operation can have an adaptive sub-block size of 4×4 or 8×8. However, when the decoded block has a block size of 4×4, the same block can be refined twice by BDOF. The complexity may not outweigh the decoding benefits. Similar problems may occur when the decoded block size is 4×N or N×4.

[0324] BDOF MV refinement can also be applied to affine decoding blocks. After 2D grouping of 4×4 subblocks with the same motion, the MV of the grouped affine subblocks can be refined by applying BDOF. In the proposed process, the size of the grouped affine subblocks is likely to be 4×N or N×4. Therefore, applying two BDOF refinements to such grouped affine subblocks may be too complex to demonstrate decoding benefits. Therefore, this disclosure also describes techniques for reducing the complexity associated with affine subblock BDOF refinement and the AMVP merging pattern of affine decoding blocks.

[0325] In some examples, video encoder 200 and video decoder 300 may be configured to determine whether to apply multiple iterations of BDOF or a single BDOF. In such examples, video decoder 300 may determine, by applying a BDOF process, whether to refine the MV of a decoded block, a sub-block of a decoded block, or a group of affine sub-blocks. The block (e.g., a decoded block, a sub-block of a decoded block, or a group of affine sub-blocks) is the input to the BDOF process and may be referred to herein as bdofInitialBlock. Given W×HbdofInitialBlock, video decoder 300 may be configured to determine whether to apply multiple iterations of BDOF or a single BDOF MV refinement by one or a subset of the following conditions:

[0326] • When W×H equals 4×4, 4×8 or 8×4.

[0327] • When W×H is less than TH, where TH is a predetermined value, such as 256.

[0328] • When W×H is less than TH, where TH is equal to the threshold that determines the maximum BDOF sub-block size to be 4×4.

[0329] • When W is equal to or less than TH, for example, TH equals 4.

[0330] • When H is equal to or less than TH, for example, TH equals 4.

[0331] • When W is not an integer multiple of 8, for example, W equals 4, 12, 20, 28, 36, 44...124, 132...252.

[0332] • When H is not an integer multiple of 8, for example, H equals 4, 12, 20, 28, 36, 44...124, 132...252.

[0333] • When an affine decoded block has at least two sub-Pu (with different MVs), for example, the CU CPMV is not a translation CPMV, for example, at least one CPMV is different from the other CPMVs.

[0334] • Combine some of the above conditions to determine bdofInitialBlock for single-time BDOF MV refinement.

[0335] In some examples, when it is determined to perform a single BDOF MV refinement, the video decoder 300 may use a maximum BDOF sub-block size that is predetermined to be M×N (e.g., 4×4).

[0336] In some examples, when determining to perform a single BDOF MV refinement, the video decoder 300 may adaptively set the maximum BDOF sub-block size to M×N (e.g., 4×4) or S×T (e.g., 8×8). For example, the maximum sub-block size is set to 4×4 when the decoded block size is less than a threshold (e.g., 1024), and otherwise set to 8×8. For example, the maximum sub-block size is set to 4×4 when the affine sub-block size of a group is less than a threshold (e.g., 256), and otherwise set to 8×8.

[0337] In some examples, the process may be applied only to affine decoding blocks, or in other examples to both affine decoding blocks and non-affine decoding blocks.

[0338] In some examples, the video encoder 200 and video decoder 300 can be configured to perform an AMVP merging pattern for affine candidate selection. When the AMVP merging pattern for affine selection is applied to a block, the block is predicted using two video parameters (MVs) from two reference images. In some examples, the two reference images meet the following conditions: one reference image is located in the future relative to the current image, and the other reference image is located in the past relative to the current image, and both reference images have equal point-of-concept (POC) distances to the current image. This may be referred to herein as the EqualPocDistDiffDirection condition.

[0339] In some examples, the affine flag value is determined to be 0 when the decoded block is determined to be an AMVP merge mode decoded block and the reference pictures in list 0 and list 1 do not have a pair that satisfies the EqualPocDistDiffDirection condition.

[0340] In some examples, the number of reference picture indices is reduced by checking the `EqualPocDistDiffDirection`. For instance, when the current picture has N reference pictures in list X, and only M reference pictures in list X have a pair of reference pictures that satisfy the condition `EqualPocDistDiffDirection`, the number of reference picture indices is reduced from N to M when the block is determined to be used for AMVP merging in affine decoding. Here, list X is indicated by a flag indicating that the AMVP predictor comes from list X and the merge predictor comes from list (1-X).

[0341] In some examples, the reference image index is deduced to be K when only the Kth reference image in list X has a paired reference image in list (1-X) that satisfies the condition EqualPocDistDiffDirection. List X is indicated by the flags that the AMVP predictors come from list X and the merged predictors come from list (1-X).

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

[0343] exist Figure 16In 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.

[0344] Video data storage 230 is an example of a storage system capable of storing video data to be encoded by components of video encoder 200. Video encoder 200 can receive data from, for example, video source 104 (…). Figure 1 The video data memory 230 receives video data stored in the video data memory 230. The DPB 218 is an example of a memory system that can act as a reference picture memory, storing reference video data for use when the video encoder 200 predicts subsequent video data. The video data memory 230 and DPB 218 can each be formed from any of one or more memory devices or memory cells, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The video data memory 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.

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

[0346] Examples Figure 16 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. A fixed-function circuit is a circuit that provides specific functionality and is pre-defined for the operations that can be performed. A programmable circuit is a circuit that can be programmed to perform various tasks and provides 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. A fixed-function circuit 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.

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

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

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

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

[0351] 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".

[0352] Typically, mode selection unit 202 also controls its components (e.g., motion estimation unit 222, motion compensation unit 224, and intra-frame prediction unit 226) to generate predicted 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.

[0353] 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. Motion estimation unit 222 can then provide the motion vectors to motion compensation unit 224. For example, for unidirectional inter-frame prediction, motion estimation unit 222 can provide a single motion vector, while for bidirectional inter-frame prediction, motion estimation unit 222 can provide two motion vectors. Motion compensation unit 224 can then use the motion vectors to generate a prediction block. For example, motion compensation unit 224 can use the motion vectors to retrieve data for the reference block. As another example, where the motion vectors have fractional sample precision, motion compensation unit 224 can interpolate the values ​​of the prediction block 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.

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

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

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

[0357] Mode selection unit 202 provides the prediction block to residual generation unit 204. Residual generation unit 204 receives the uncoded raw 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 of 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.

[0358] 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 the luma decoding block of the CU, while the size of a PU can refer to the size of the luma prediction unit of the PU. Assuming a particular CU size is 2Nx2N, video encoder 200 can support PU sizes of 2Nx2N or NxN for intra-frame prediction, and symmetric PU sizes of 2Nx2N, 2NxN, Nx2N, NxN, or similar for inter-frame prediction. Video encoder 200 and video decoder 300 can also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N, and nRx2N for inter-frame prediction.

[0359] 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 2Nx2N, 2NxN, or Nx2N.

[0360] 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 of 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.

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

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

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

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

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

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

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

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

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

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

[0371] 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 using an update factor based on the alphabet size to update the context.

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

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

[0374] Video encoder 200 represents an example of a device configured to encode video data, the device including a memory configured to store video data and one or more processing units implemented in circuitry and configured to: derive an initial motion vector based on an affine model of a current block; refine a bidirectional optical flow sub-block motion vector and apply it to the initial motion vector to determine a modified motion vector for the current block; determine a prediction block for the current block based on the modified motion vector; and use the prediction block to determine a decoded version of the current block. Video encoder 200 also represents an example of a device configured to encode video data, the device including a memory configured to store video data and one or more processing units implemented in circuitry and configured to: derive an initial motion vector for the current block from a temporally co-located block of the current block; refine a bidirectional optical flow sub-block motion vector and apply it to the initial motion vector to determine a modified motion vector for the current block; determine a prediction block for the current block based on the modified motion vector; and use the prediction block to determine a decoded version of the current block.

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

[0376] exist Figure 17 In 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 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.

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

[0378] 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, IBC, and / or palette mode, as described above.

[0379] CPB memory 320 is an example of a memory system capable of storing video data (such as encoded video bitstreams) to be decoded by components of video decoder 300. For example, it can be stored from computer-readable medium 110 ( Figure 1 The video data stored in the CPB memory 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 image, such as temporary data representing the output from various units of the video decoder 300. The DPB 314 is an example of a memory system that typically stores a decoded image that the video decoder 300 can output, and / or uses as reference video data when decoding subsequent data or images from the encoded video bitstream. The CPB memory 320 and the DPB 314 may each be formed from any of various memory devices or memory cells, such as DRAM (including SDRAM), MRAM, RRAM, or other types of memory devices. The CPB memory 320 and the DPB 314 may be provided by the same memory device or separate memory devices. In various examples, the CPB memory 320 may be on-chip with other components of the video decoder 300, or off-chip relative to those components.

[0380] Additionally or alternatively, in some examples, the video decoder 300 may be from the memory 120 ( Figure 1The decoded video data can be retrieved from the memory. 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.

[0381] Examples Figure 17 The various units shown help to understand the operations performed by the video decoder 300. The units can be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Similar to... Figure 16 Fixed-function circuits are circuits that provide specific functionality and are predefined 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 usually immutable. In some examples, one or more units in a cell can be different circuit blocks (fixed-function or programmable), and in some examples, one or more units in a cell can be integrated circuits.

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

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

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

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

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

[0387] 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 can generally be configured according to the parameters relative to the motion compensation unit 224 ( Figure 16 The method described is essentially the same as the method used to perform the inter-frame prediction process.

[0388] 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 16 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.

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

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

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

[0392] In this manner, video decoder 300 represents an example of a video decoding device, which includes a memory configured to store video data and one or more processing units implemented in a circuit and configured to perform the following operations: deriving an initial motion vector based on an affine model of the current block; refining a bidirectional optical flow sub-block motion vector and applying it to the initial motion vector to determine a modified motion vector for the current block; determining a prediction block for the current block based on the modified motion vector; and using the prediction block to determine a decoded version of the current block. Video decoder 300 represents an example of a video decoding device, which includes a memory configured to store video data, one or more processing units implemented in a circuit and configured to store video data, and one or more processing units implemented in a circuit and configured to perform the following operations: deriving an initial motion vector for the current block from a temporally co-located block of the current block; refining a bidirectional optical flow sub-block motion vector and applying it to the initial motion vector to determine a modified motion vector for the current block; determining a prediction block for the current block based on the modified motion vector; and using the prediction block to determine a decoded version of the current block.

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

[0394] In this example, the video encoder 200 initially predicts the current block (520). For example, the video encoder 200 may form a prediction block for the current block. Then, the video encoder 200 may compute a residual block for the current block (522). To compute the residual block, the video encoder 200 may compute the difference between the unencoded original block used for the current block and the prediction block. Then, the video encoder 200 may transform the residual block and quantize the transform coefficients of the residual block (524). Next, the video encoder 200 may scan the quantized transform coefficients of the residual block (526). During or after the scan, the video encoder 200 may entropy encode the transform coefficients (528). For example, the video encoder 200 may use CAVLC or CABAC to encode the transform coefficients. Then, the video encoder 200 may output the entropy-encoded data for the block (530).

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

[0396] 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 (540). 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 (542). The video decoder 300 may, for example, use an intra-frame prediction mode or inter-frame prediction mode indicated by the prediction information of the current block to predict the current block (544) to compute a prediction block for the current block. The video decoder 300 may then perform an inverse scan on the reproduced transform coefficients (546) to create a block of quantized transform coefficients. The video decoder 300 may then inverse quantize the transform coefficients and apply the inverse transform to the transform coefficients to produce a residual block (548). The video decoder 300 may finally decode the current block by combining the prediction block and the residual block (550).

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

[0398] exist Figure 20 In the example, video decoder 300 derives the initial motion vector for the current block of video data (560). Based on the size of the current block, video decoder 300 determines whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector (562). For example, the video decoding loop of video encoder 200 can also perform... Figure 20 The technology.

[0399] To determine whether to apply a multi-iteration BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder 300 may be configured, for example, to apply a single BDOF to the initial motion vector in response to the block's width not being an integer multiple of 8. To determine whether to apply a multi-iteration BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder 300 may be configured, for example, to apply a single BDOF to the initial motion vector in response to the block's height not being an integer multiple of 8. To determine whether to apply a multi-iteration BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder 300 may be configured, for example, to apply a single BDOF to the initial motion vector in response to the block's width being equal to 4. To determine whether to apply a multi-iteration BDOF or a single BDOF to the initial motion vector based on the size of the current block, the video decoder 300 may be configured, for example, to apply a single BDOF to the initial motion vector in response to the block's height being equal to 4. In order to determine whether to apply the multi-iteration BDOF or the single BDOF to the initial motion vector based on the size of the current block, the video decoder 300 may be configured, for example, to determine to apply the single BDOF to the initial motion vector in response to the block size being one of 4×4, 4×8, or 8×4.

[0400] In response to determining that the single BDOF is applied to the initial motion vector, the video decoder 300 uses the single BDOF to determine the modified motion vector of the current block (564). The video decoder 300 determines that the current block corresponds to the prediction block of the modified motion vector (566). The video decoder 300 may also store the modified motion vector for decoding subsequent blocks of video data.

[0401] The video decoder 300 uses the prediction block to determine the decoded version (568) of the current block. The video decoder 300 may, for example, output a decoded image including the decoded version of the current block. The video decoder 300 may, for example, output the decoded image for display, transmission, or storage. When Figure 20When the process is performed as part of the video encoding process, the decoded images can be stored for use in encoding other images of the video data.

[0402] The following numbered clauses illustrate one or more aspects of the devices and technologies described in this disclosure.

[0403] Clause 1A: A method for decoding video data, the method comprising: deriving an initial motion vector based on an affine model of a current block; determining whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; determining a modified motion vector of the current block using the single BDOF in response to determining that the single BDOF should be applied to the initial motion vector; determining a predicted block of the current block based on the modified motion vector; and using the predicted block to determine a decoded version of the current block.

[0404] Clause 2A: A method for decoding video data, the method comprising: deriving an initial motion vector of the current block from a temporally co-located block; determining whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; determining a modified motion vector of the current block using the single BDOF in response to determining that the single BDOF is applied to the initial motion vector; determining a prediction block of the current block based on the modified motion vector; and using the prediction block to determine a decoded version of the current block.

[0405] Clause 3A: The method according to Clause 1A or 2A, wherein the block has a width (W) and a height (H), and determining to apply the single BDOF to the initial motion vector includes determining to apply the single BDOF to the initial motion vector in response to one or more of the following: the size of the block is equal to 4×4, 4×8A, or 8×4; W×H is less than a threshold (TH), where TH is a predetermined value; W×H is less than TH, where TH is equal to a threshold determining the maximum BDOF sub-block size to be 4×4; W is equal to or less than TH; H is equal to or less than TH; W is not an integer multiple of 8; H is not an integer multiple of 8; or the block is an affine decoded block having at least two sub-prediction units that have different motion vectors.

[0406] Clause 4A: A method for decoding video data, the method comprising: determining a block of video data in a current image to be encoded in an Advanced Motion Vector Prediction (AMVP) mode; maintaining an AMVP candidate list for the block; determining that the AMVP candidate list does not include two candidates having an equal picture order count (POC) distance relative to the current image, wherein the POC distance corresponds to a magnitude of the difference between the POC value of a reference image of the candidate and the POC value of the current image; and determining that affine prediction is disabled for the block of video data in response to determining that the AMVP candidate list does not include the two candidates having an equal POC distance.

[0407] Clause 5A: A method for decoding video data, the method comprising: determining that a block of video data in a current image is encoded in an Advanced Motion Vector Prediction (AMVP) mode; maintaining an AMVP candidate list for the block; determining that all candidates in the AMVP candidate list have different Picture Order Count (POC) distances relative to the current image, wherein the POC distance corresponds to the magnitude of the difference between the POC value of a reference image of the candidate and the POC value of the current image; and determining that affine prediction is disabled for the block of video data in response to determining that all candidates in the AMVP candidate list have different POC distances relative to the current image.

[0408] Clause 6A: The method according to Clause 4A or 5A, wherein determining that the affine prediction is disabled for the block of video data includes inferring the value of a syntax element, the value being set to a value in the case where no instance of the syntax element is received in the bitstream including the video data.

[0409] Clause 7A: The method according to any one of Clauses 1A to 6A, wherein decoding includes decoding.

[0410] Clause 8A: The method according to any one of Clauses 1A to 7A, wherein decoding includes encoding.

[0411] Clause 9A: An apparatus for decoding video data, the apparatus comprising one or more components for performing a method according to any one of Clauses 1A to 8A.

[0412] Clause 10A: The device pursuant to Clause 9A, wherein the one or more components include one or more processors implemented in a circuit.

[0413] Clause 11A: The device according to any one of Clauses 9A and 10A, further comprising a memory for storing the video data. Clause 12A: The device according to any one of Clauses 9A to 11A, further comprising a display configured to display decoded video data.

[0414] Clause 13A: The device pursuant to any one of Clauses 9A to 12A, wherein the device includes one or more of a camera, computer, mobile device, broadcast receiver device or set-top box.

[0415] Clause 14A: A device pursuant to any one of Clauses 9A to 13A, wherein said device includes a video decoder.

[0416] Clause 15A: A device pursuant to any one of Clauses 9A to 14A, wherein said device includes a video encoder.

[0417] Clause 16A: A computer-readable storage medium having instructions stored thereon, which, when executed, cause one or more processors to perform the method according to any one of Clauses 1A to 8A.

[0418] Clause 1B: A method for decoding video data, the method comprising: deriving an initial motion vector for a current block of the video data; determining, based on the size of the current block, whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; in response to determining that the single BDOF should be applied to the initial motion vector, using the single BDOF to determine a modified motion vector for the current block; determining a prediction block corresponding to the modified motion vector for the current block; and using the prediction block to determine a decoded version of the current block.

[0419] Clause 2B: The method according to Clause 1B, wherein determining whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block comprises: determining to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0420] Clause 3B: The method according to Clause 1B or 2B, wherein determining whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block includes: determining to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0421] Clause 4B: The method according to Clause 1B, wherein determining whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block comprises: determining to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0422] Clause 5B: The method according to Clause 1B or 4B, wherein determining whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block includes: determining to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0423] Clause 6B: The method according to Clause 1B, wherein determining whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block comprises: determining to apply the single BDOF to the initial motion vector in response to the current block size being one of 4×4, 4×8, or 8×4.

[0424] Clause 7B: The method according to any one of Clauses 1B to 6B, the method further comprising: storing the modified motion vector for decoding subsequent blocks of video data.

[0425] Clause 8B: The method according to any one of Clauses 1B to 7B, wherein the current block includes an affine decoded block.

[0426] Clause 9B: The method according to any one of Clauses 1B to 8B, wherein the method of decoding is performed as part of the video encoding process.

[0427] Clause 10B: An apparatus for decoding video data, the apparatus comprising: a memory configured to store video data; one or more processors implemented in a circuit and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; in response to determining that the single BDOF should be applied to the initial motion vector, use the single BDOF to determine a modified motion vector for the current block; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0428] Clause 11B: The device according to Clause 10B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0429] Clause 12B: The device according to Clause 10B or 11B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0430] Clause 13B: The device according to Clause 10B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0431] Clause 14B: The device according to Clause 10B or 13B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0432] Clause 15B: The device according to Clause 10B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the current block size being 4×4, 4×8B, or 8×4.

[0433] Clause 16B: A device according to any one of Clauses 10B to 15B, wherein the one or more processors are further configured to: store the modified motion vectors for decoding subsequent blocks of video data.

[0434] Clause 17B: A device pursuant to any one of Clauses 10B to 16B, wherein the current block comprises an affine decoded block.

[0435] Clause 18B: The device according to any one of Clauses 10B to 17B, the device further comprising a display configured to display decoded video data.

[0436] Clause 19B: The device pursuant to any one of Clauses 10B to 18B, wherein the device includes one or more of a camera, computer, mobile device, broadcast receiver device or set-top box.

[0437] Clause 20B: A device pursuant to any one of Clauses 10B to 19B, wherein the device includes a video decoder.

[0438] Clause 21B: The device pursuant to any one of Clauses 10B to 19B, wherein the device includes a video encoder.

[0439] Clause 22B: A computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to: derive an initial motion vector for a current block of video data; determine, based on the size of the current block, whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; in response to determining that the single BDOF should be applied to the initial motion vector, use the single BDOF to determine a modified motion vector for the current block; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0440] Clause 23B: An apparatus for encoding video data, the apparatus comprising: a memory configured to store video data; one or more processors implemented in circuitry and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, whether to apply multiple iterations of bidirectional optical flow (BDOF) or a single BDOF to the initial motion vector; determine a modified motion vector for the current block using the single BDOF in response to determining that the single BDOF should be applied to the initial motion vector; determine a predicted block corresponding to the modified motion vector; use the predicted block to determine a decoded version of the current block; store in a decoded image buffer a copy of a decoded image of the video data including the decoded version of the current block; and use the stored copy of the decoded image of the video data to predict subsequent blocks of the video data.

[0441] Clause 24B: The device according to Clause 23B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0442] Clause 25B: The device according to Clause 23B or 24B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0443] Clause 26B: The device according to Clause 23B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0444] Clause 27B: The device according to Clause 23B or 26B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0445] Clause 28B: The device according to Clause 23B, wherein, in order to determine whether to apply the multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine to apply the single BDOF to the initial motion vector in response to the current block size being 4×4, 4×8B, or 8×4.

[0446] Clause 29B: A device pursuant to any one of Clauses 23B to 28B, wherein the one or more processors are further configured to: store the modified motion vectors for decoding subsequent blocks of video data.

[0447] Clause 30B: A device pursuant to any one of Clauses 23B to 29B, wherein the current block comprises an affine decoded block.

[0448] Clause 1C: A method for decoding video data, the method comprising: deriving an initial motion vector for a current block of the video data; determining, based on the size of the current block, to apply a single bidirectional optical flow (BDOF); in response to determining to apply the single BDOF to the initial motion vector, using the single BDOF to determine a modified motion vector for the current block; determining a prediction block corresponding to the modified motion vector for the current block; and using the prediction block to determine a decoded version of the current block.

[0449] Clause 2C: The method according to Clause 1C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0450] Clause 3C: The method according to Clause 1C or 2C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0451] Clause 4C: The method according to Clause 1C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0452] Clause 5C: The method according to Clause 1C or 4C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0453] Clause 6C: The method according to Clause 1C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the current block size being one of 4×4, 4×8B, or 8×4.

[0454] Clause 7C: The method according to any one of Clauses 1C to 6C, the method further comprising: storing the modified motion vector for decoding subsequent blocks of video data.

[0455] Clause 8C: The method according to any one of Clauses 1C to 7C, wherein the current block includes an affine decoded block.

[0456] Clause 9C: The method according to any one of Clauses 1C to 8C, wherein the method of decoding is performed as part of the video encoding process.

[0457] Clause 10C: An apparatus for decoding video data, the apparatus comprising: a memory configured to store video data; one or more processors implemented in a circuit and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; in response to determining to apply the single BDOF to the initial motion vector, use the single BDOF to determine a modified motion vector for the current block; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0458] Clause 11C: The apparatus according to Clause 10C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0459] Clause 12C: The apparatus according to Clause 10C or 11C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0460] Clause 13C: The apparatus according to Clause 10C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0461] Clause 14C: The apparatus according to Clause 10C or 13C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0462] Clause 15C: The apparatus according to Clause 10C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the size of the current block being 4×4, 4×8B, or 8×4.

[0463] Clause 16C: A device according to any one of Clauses 10C to 16C, wherein the one or more processors are further configured to: store the modified motion vectors for decoding subsequent blocks of video data.

[0464] Clause 17C: A device according to any one of Clauses 10C to 17C, wherein the current block comprises an affine decoding block.

[0465] Clause 18C: The device according to any one of Clauses 10C to 17C, the device further comprising a display configured to display decoded video data.

[0466] Clause 19C: Equipment pursuant to any one of Clauses 10C to 18C, wherein said equipment includes one or more of a camera, computer, mobile device, broadcast receiver equipment, or set-top box.

[0467] Clause 20C: A device pursuant to any one of Clauses 10C to 19C, wherein said device includes a video decoder.

[0468] Clause 21C: The device pursuant to any one of Clauses 10C to 19C, wherein the device includes a video encoder.

[0469] Clause 22C: A computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to: derive an initial motion vector for a current block of video data; determine, based on the size of the current block, to apply a single BDOF to the initial motion vector; in response to determining to apply the single BDOF to the initial motion vector, use the single BDOF to determine a modified motion vector for the current block; determine a prediction block corresponding to the modified motion vector for the current block; and use the prediction block to determine a decoded version of the current block.

[0470] Clause 23C: An apparatus for encoding video data, the apparatus comprising: a memory configured to store video data; one or more processors implemented in circuitry and configured to: derive an initial motion vector for a current block of the video data; determine, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; determine, in response to determining to apply the single BDOF to the initial motion vector, a modified motion vector for the current block using the single BDOF; determine a predicted block corresponding to the modified motion vector for the current block; use the predicted block to determine a decoded version of the current block; store in a decoded image buffer a copy of a decoded image of the video data including the decoded version of the current block; and use the stored copy of the decoded image of the video data to predict subsequent blocks of the video data.

[0471] Clause 24C: The apparatus according to Clause 23C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the width of the block not being an integer multiple of 8.

[0472] Clause 25C: The apparatus according to Clause 23C or 24C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the block height not being an integer multiple of 8.

[0473] Clause 26C: The apparatus according to Clause 23C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the width of the block being equal to 4.

[0474] Clause 27C: The apparatus according to Clause 23C or 26C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the block height being equal to 4.

[0475] Clause 28C: The apparatus according to Clause 23C, wherein, in order to determine whether to apply the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: determine whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determine to apply the single BDOF to the initial motion vector in response to the size of the current block being 4×4, 4×8B, or 8×4.

[0476] Clause 29C: A device pursuant to any one of Clauses 23C to 28C, wherein the current block comprises an affine decoding block.

[0477] Clause 30C: Device pursuant to any one of Clauses 23C to 29C, wherein said device includes one or more of a camera, a computer, or a mobile device.

[0478] Clause 31C: A method for encoding video data, the method comprising: deriving an initial motion vector for a current block of the video data; determining, based on the size of the current block, to apply a single bidirectional optical flow (BDOF) to the initial motion vector; determining, in response to determining to apply the single BDOF to the initial motion vector, a modified motion vector of the current block using the single BDOF; determining a prediction block corresponding to the modified motion vector of the current block; using the prediction block to determine a decoded version of the current block; storing in a decoded picture buffer a copy of a decoded picture of the video data including the decoded version of the current block; and using the stored copy of the decoded picture of the video data to predict subsequent blocks of the video data.

[0479] Clause 32C: The method according to Clause 31C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the block's height or width not being an integer multiple of 8.

[0480] Clause 33C: The method according to Clause 31C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the block's height or width being equal to 4.

[0481] Clause 34C: The method according to Clause 31C, wherein determining whether to apply the single BDOF to the initial motion vector based on the size of the current block includes: determining whether to apply multiple iterations of BDOF or the single BDOF to the initial motion vector based on the size of the current block; and determining to apply the single BDOF to the initial motion vector in response to the size of the current block being 4×4, 4×8B, or 8×4.

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

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

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

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

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

[0487] 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: Derive the initial motion vector of the current block of the video data; The application of single bidirectional optical flow (BDOF) is determined based on the size of the current block. In response to determining that the single BDOF should be applied to the initial motion vector, the modified motion vector of the current block is determined using the single BDOF; Determine that the current block corresponds to the prediction block with the modified motion vector; and The predicted block is used to determine the decoded version of the current block.

2. The method of claim 1, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as The single BDOF is applied to the initial motion vector in response to the block width not being an integer multiple of 8.

3. The method of claim 1, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as The initial motion vector is determined to be applied in response to the block height not being an integer multiple of 8.

4. The method of claim 1, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as In response to the block width being equal to 4, it is determined that the single BDOF will be applied to the initial motion vector.

5. The method of claim 1, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as In response to the block height being equal to 4, the single BDOF is determined to be applied to the initial motion vector.

6. The method of claim 1, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as The single BDOF is applied to the initial motion vector in response to the current block size being 4×4, 4×8, or 8×4.

7. The method according to claim 1, wherein the method further comprises: The modified motion vectors are stored for decoding subsequent blocks of video data.

8. The method of claim 1, wherein the current block comprises an affine decoded block.

9. The method of claim 1, wherein the decoding method is performed as part of a video encoding process.

10. An apparatus for decoding video data, the apparatus comprising: A memory configured to store video data; One or more processors, said one or more processors being implemented in a circuit and configured to: Derive the initial motion vector of the current block of the video data; The application of a single bidirectional optical flow (BDOF) to the initial motion vector is determined based on the size of the current block. In response to determining that the single BDOF should be applied to the initial motion vector, the modified motion vector of the current block is determined using the single BDOF; Determine that the current block corresponds to the prediction block with the modified motion vector; and The predicted block is used to determine the decoded version of the current block.

11. The device of claim 10, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The single BDOF is applied to the initial motion vector in response to the block width not being an integer multiple of 8.

12. The device of claim 10, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The initial motion vector is determined to be applied in response to the block height not being an integer multiple of 8.

13. The device of claim 10, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and In response to the block width being equal to 4, it is determined that the single BDOF will be applied to the initial motion vector.

14. The device of claim 10, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and In response to the block height being equal to 4, the single BDOF is determined to be applied to the initial motion vector.

15. The device of claim 10, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The single BDOF is applied to the initial motion vector in response to the current block size being 4×4, 4×8, or 8×4.

16. The device of claim 10, wherein the one or more processors are further configured to: The modified motion vectors are stored for decoding subsequent blocks of video data.

17. The apparatus of claim 10, wherein the current block comprises an affine decoding block.

18. The device of claim 10, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

19. A method for encoding video data, the method comprising: Derive the initial motion vector of the current block of the video data; The application of a single bidirectional optical flow (BDOF) to the initial motion vector is determined based on the size of the current block. In response to determining that the single BDOF should be applied to the initial motion vector, the modified motion vector of the current block is determined using the single BDOF; Determine that the current block corresponds to the predicted block with the modified motion vector; The predicted block is used to determine the decoded version of the current block; A copy of a decoded image, including the decoded version of video data of the current block, is stored in the decoded image buffer; as well as The stored copy of the decoded image of the video data is used to predict subsequent blocks of the video data.

20. The method of claim 19, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as The initial motion vector is determined to be applied in response to the block's height or width not being an integer multiple of 8.

21. The method of claim 19, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as In response to the block's height or width being equal to 4, the single BDOF is determined to be applied to the initial motion vector.

22. The method of claim 19, wherein determining the application of the single BDOF to the initial motion vector based on the size of the current block comprises: The size of the current block determines whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector. as well as The single BDOF is applied to the initial motion vector in response to the current block size being 4×4, 4×8, or 8×4.

23. An apparatus for encoding video data, the apparatus comprising: A memory configured to store video data; One or more processors, said one or more processors being implemented in a circuit and configured to: Derive the initial motion vector of the current block of the video data; The application of a single bidirectional optical flow (BDOF) to the initial motion vector is determined based on the size of the current block. In response to determining that the single BDOF should be applied to the initial motion vector, the modified motion vector of the current block is determined using the single BDOF; Determine that the current block corresponds to the predicted block with the modified motion vector; The predicted block is used to determine the decoded version of the current block; A copy of a decoded image, including the decoded version of video data of the current block, is stored in the decoded image buffer; as well as The stored copy of the decoded image of the video data is used to predict subsequent blocks of the video data.

24. The device of claim 23, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The single BDOF is applied to the initial motion vector in response to the block width not being an integer multiple of 8.

25. The device of claim 23, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The initial motion vector is determined to be applied in response to the block height not being an integer multiple of 8.

26. The device of claim 23, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and In response to the block width being equal to 4, it is determined that the single BDOF will be applied to the initial motion vector.

27. The device of claim 23, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and In response to the block height being equal to 4, the single BDOF is determined to be applied to the initial motion vector.

28. The device of claim 23, wherein, in order to determine the application of the single BDOF to the initial motion vector based on the size of the current block, the one or more processors are further configured to: Based on the size of the current block, determine whether to apply multiple iterations of BDOF or a single BDOF to the initial motion vector; and The single BDOF is applied to the initial motion vector in response to the current block size being 4×4, 4×8, or 8×4.

29. The device of claim 23, wherein the current block comprises an affine decoding block.

30. The device of claim 23, wherein the device comprises one or more of a camera, a computer, or a mobile device.

Images