System, method and program for sub-block motion vector coding

Abstract

Various embodiments described herein include methods and systems for encoding and decoding video. In one aspect, the method includes receiving a video bitstream including a plurality of blocks, including a first block, the first block including a plurality of sub-blocks. The method also includes determining, based on a syntax element value in the video bitstream, that the first block is predicted in sub-block mode. The method further includes, in response to the first block being predicted in sub-block mode, deriving a set of motion vector predictors (MVPs) corresponding to the plurality of sub-blocks of the first block; deriving a set of motion vector differentials (MVDs) for the plurality of sub-blocks; determining a set of motion vectors for the plurality of sub-blocks by applying the set of MVDs to the set of MVPs; and reconstructing the first block using the set of motion vectors.

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 405,274, filed September 9, 2022, entitled "Sub-Block MVD Transform Coding," and is a continuation of and claims priority to U.S. Patent Application No. 18 / 209,822, filed June 14, 2023, entitled "System and Method for Sub-Block Motion Vector Coding."

[0002] Technical Field The disclosed embodiments relate generally to video encoding and decoding, including, but not limited to, systems and methods for sub-block motion vector coding. [Background technology]

[0003] Digital video is supported by a variety of electronic devices, including digital televisions, laptop or desktop computers, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video teleconferencing devices, and video streaming devices. The electronic devices transmit, receive, or otherwise communicate digital video data over communication networks and / or store the digital video data on storage devices. Due to the limited bandwidth capacity of communication networks and the limited memory resources of storage devices, video coding may be used to compress the video data according to one or more video coding standards before it is communicated or stored.

[0004] Several video codec standards have been developed. For example, video coding standards include AOMedia Video 1 (AV1), Versatile Video Coding (VVC), Joint Exploration and Experimental Model (JEM), High Efficiency Video Coding (HEVC / H.265), Advanced Video Coding (AVC / H.264), and Moving Picture Experts Group (MPEG) coding. Video coding generally uses prediction methods (e.g., inter-prediction, intra-prediction, etc.) that exploit the redundancy inherent in video data. The goal of video coding is to compress video data into a form that uses a lower bitrate while avoiding or minimizing degradation of video quality.

[0005] HEVC, also known as H.265, is a video compression standard designed as part of the MPEG-H project. ITU-T and ISO / IEC published the HEVC / H.265 standard in 2013 (Version 1), 2014 (Version 2), 2015 (Version 3), and 2016 (Version 4). Versatile Video Coding (VVC), also known as H.266, is a video compression standard intended as the successor to HEVC. ITU-T and ISO / IEC published the VVC / H.266 standard in 2020 (Version 1) and 2022 (Version 2). AV1 is an open video coding format designed as a replacement for HEVC. Validated version 1.0.0, accompanied by errata 1, was released on January 8, 2019. Summary of the Invention [Problem to be solved by the invention]

[0006] As previously described, a video stream is encoded (including compressed) into a bitstream and then transmitted to a decoder that can decode / decompress the video stream in preparation for viewing or further processing. Compression of the video stream can exploit spatial and temporal correlation in the video signal through spatial and / or motion-compensated prediction. Motion-compensated prediction can include inter-prediction. Inter-prediction can use one or more motion vectors to generate an encoded block using previously encoded and decoded pixels. A decoder that receives the encoded signal can reconstruct the block. As used herein, the term block can be interpreted as a predictive block, a coding block, or a coding unit (CU), depending on the context.

[0007] In conventional sub-block motion modes, sub-block motion vectors may be estimated based on assumptions about the coded motion vector field or a particular motion model. However, optimal sub-block motion vectors may not follow the assumptions about the motion model. Therefore, these sub-block motion modes do not allow customized assignment of motion vectors for each sub-block by the encoder or decoder. [Means for solving the problem]

[0008] According to some embodiments, a method for video decoding is performed in a computing system having a memory and one or more processors, the method including: (i) receiving, from a video bitstream, video data including a plurality of blocks including a first block; (ii) obtaining a set of motion vector predictors (MVPs) corresponding to a plurality of sub-blocks of the first block; (iii) obtaining a set of motion vector differentials (MVDs) for the plurality of sub-blocks; (iv) obtaining a set of motion vectors for the plurality of sub-blocks by applying the set of MVDs to the set of MVPs; and (v) reconstructing the first block using the set of motion vectors.

[0009] According to some embodiments, a video encoding method is performed in a computing system having a memory and one or more processors, and includes: (i) obtaining video data including a plurality of blocks including a first block; (ii) obtaining a set of motion vector predictors (MVPs) corresponding to a plurality of sub-blocks of the first block; (iii) obtaining a set of motion vectors for the plurality of sub-blocks; (iv) obtaining a set of motion vector differentials (MVDs) for the plurality of sub-blocks by comparing the set of MVPs with the set of motion vectors; and (v) signaling the set of MVDs in a video bitstream.

[0010] According to some embodiments, a computing system, such as a streaming system, server system, personal computer system, or other electronic device, is provided. The computing system includes control circuitry and memory that stores one or more instruction sets. The one or more instruction sets include instructions for performing any of the methods described herein. In some embodiments, the computing system includes an encoder component and / or a decoder component.

[0011] According to some embodiments, a non-transitory computer-readable storage medium is provided that stores one or more sets of instructions for execution by a computing system, the one or more sets of instructions including instructions for performing any of the methods described herein.

[0012] Thus, disclosed are methods, devices, and systems for encoding and decoding video, which may complement or replace conventional methods, devices, and systems for video encoding and / or decoding.

[0013] The features and advantages described herein are not necessarily all-inclusive. Some additional features and advantages will become apparent to those skilled in the art, particularly in light of the drawings, specification, and claims provided in this disclosure. Furthermore, it should be noted that the language used herein has been selected primarily for ease of reading and educational purposes, and not necessarily to define or limit the subject matter described herein. [Brief explanation of the drawings]

[0014] In order that the present disclosure may be more fully understood, a more particular description may be had by reference to features of various embodiments, some of which are illustrated in the accompanying drawings. However, the accompanying drawings merely illustrate relevant features of the present disclosure and therefore should not be considered necessarily limiting, as the description may acknowledge other useful features that those skilled in the art will appreciate upon reading the present disclosure.

[0015] [Figure 1] 1 is a block diagram illustrating an exemplary communication system according to some embodiments.

[0016] [Figure 2A] FIG. 1 is a block diagram illustrating exemplary elements of an encoder component according to some embodiments.

[0017] [Figure 2B] FIG. 1 is a block diagram illustrating exemplary elements of a decoder component according to some embodiments.

[0018] [Figure 3] FIG. 1 is a block diagram illustrating an exemplary server system according to some embodiments.

[0019] [Figure 4A] 1 illustrates exemplary locations of spatial block candidates according to some embodiments.

[0020] [Figure 4B] 1 illustrates an example sub-block motion field according to some embodiments.

[0021] [Figure 4C] 1 illustrates an exemplary motion vector refinement according to some embodiments.

[0022] [Figure 4D] 1 illustrates an exemplary affine model according to some embodiments. [Figure 4E]1 illustrates an exemplary affine model according to some embodiments.

[0023] [Figure 5] AB show exemplary sub-block motion vector differentials according to some embodiments.

[0024] [Figure 6] 8A-8B are flow diagrams illustrating exemplary methods for encoding and decoding video according to some embodiments.

[0025] In accordance with common practice, the various features illustrated in the drawings are not necessarily drawn to scale and like reference numerals may be used to denote like features throughout the specification and drawings. DETAILED DESCRIPTION OF THE INVENTION

[0026] This disclosure describes the derivation and use of sub-block motion vector difference (MVD) for motion coding. For example, deriving a sub-block motion vector (MV) may include deriving a sub-block motion vector predictor (MVP), then deriving a sub-block MVD, and then deriving an MV by adding the sub-block MVP to the associated sub-block MVD. Deriving and using MVD for sub-block motion can improve accuracy and coding efficiency and reduce encoding / decoding loss.

[0027] Exemplary Systems and Devices 1 is a block diagram illustrating a communication system 100 according to some embodiments. Communication system 100 includes a source device 102 and multiple electronic devices 120 (e.g., electronic devices 120-1 through 120-m) communicatively coupled to each other via one or more networks. In some embodiments, communication system 100 is a streaming system for use with video-enabled applications, such as, for example, video conferencing applications, digital TV applications, and media storage and / or distribution applications.

[0028] Source device 102 includes a video source 104 (e.g., a camera component or media storage) and an encoder component 106. In some embodiments, video source 104 is a digital camera (e.g., configured to create an uncompressed video sample stream). Encoder component 106 generates one or more encoded video bitstreams from the video stream. The video stream from video source 104 may be of a higher data volume than encoded video bitstream 108 generated by encoder component 106. Because encoded video bitstream 108 has a lower data volume (less data) than the video stream from the video source, encoded video bitstream 108 requires less bandwidth to transmit and less storage space to store compared to the video stream from video source 104. In some embodiments, source device 102 does not include encoder component 106 (e.g., configured to transmit uncompressed video data to network(s) 110).

[0029] The one or more networks 110 represent any number of networks that carry information between the source device 102, the server system 112, and / or the electronic device 120, including, for example, wireline and / or wireless communication networks. The one or more networks 110 may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet.

[0030] The one or more networks 110 include a server system 112 (e.g., a distributed / cloud computing system). In some embodiments, the server system 112 is or includes a streaming server (e.g., configured to store and / or distribute video content, such as an encoded video stream from the source device 102). The server system 112 includes a coder component 114 (e.g., configured to encode and / or decode video data). In some embodiments, the coder component 114 includes an encoder component and / or a decoder component. In various embodiments, the coder component 114 is instantiated as hardware, software, or a combination thereof. In some embodiments, the coder component 114 is configured to decode the encoded video bitstream 108 and re-encode the video data using a different encoding standard and / or method to generate encoded video data 116. In some embodiments, the server system 112 is configured to generate multiple video formats and / or encodings from the encoded video bitstream 108.

[0031] In some embodiments, server system 112 functions as a Media-Aware Network Element (MANE). For example, server system 112 may be configured to prune encoded video bitstream 108 to tailor potentially different bitstreams to one or more of electronic devices 120. In some embodiments, a MANE is provided separately from server system 112.

[0032] Electronic device 120-1 includes a decoder component 122 and a display 124. In some embodiments, decoder component 122 is configured to decode encoded video data 116 to generate an outgoing video stream that can be rendered on a display or other type of rendering device. In some embodiments, one or more of electronic devices 120 do not include a display component (e.g., are communicatively coupled to an external display device and / or include media storage). In some embodiments, electronic device 120 is a streaming client. In some embodiments, electronic device 120 is configured to access server system 112 to obtain encoded video data 116.

[0033] The source device and / or the plurality of electronic devices 120 are sometimes referred to as “terminal devices” or “user devices.” In some embodiments, the source device 102 and / or one or more of the electronic devices 120 are instances of a server system, a personal computer, a portable device (e.g., a smartphone, tablet, or laptop), a wearable device, a videoconferencing device, and / or other types of electronic devices.

[0034] In an exemplary operation of the communication system 100, the source device 102 transmits an encoded video bitstream 108 to the server system 112. For example, the source device 102 may encode a stream of pictures captured by the source device. The server system 112 may receive the encoded video bitstream 108 and decode and / or encode the encoded video bitstream 108 using a coder component 114. For example, the server system 112 may apply a more optimal encoding to the video data for network transmission and / or storage. The server system 112 may transmit the encoded video data 116 (e.g., one or more coded video bitstreams) to one or more of the electronic devices 120. Each electronic device 120 may decode the encoded video data 116 to recover, and optionally display, video pictures.

[0035] In some embodiments, the transmissions discussed above are one-way data transmissions. One-way data transmissions may be utilized in media serving applications, etc. In some embodiments, the transmissions discussed above are two-way data transmissions. Two-way data transmissions may be utilized in video conferencing applications, etc. In some embodiments, the encoded video bitstream 108 and / or the encoded video data 116 are encoded and / or decoded according to any of the video encoding / compression standards described herein, such as HEVC, VVC, and / or AV1.

[0036] FIG. 2A is a block diagram illustrating exemplary elements of encoder component 106, according to some embodiments. Encoder component 106 receives a source video sequence from video source 104. In some embodiments, the encoder component includes a receiver (e.g., transceiver) component configured to receive the source video sequence. In some embodiments, encoder component 106 receives a video sequence from a remote video source (e.g., a video source that is a component of a device different from encoder component 106). Video source 104 may provide the source video sequence in the form of a digital video sample stream that may be of any suitable bit depth (e.g., 8-bit, 10-bit, or 12-bit), any color space (e.g., BT.601 Y CrCb, or RGB), and any suitable sampling structure (e.g., YCrCb 4:2:0 or YCrCb 4:4:4). In some embodiments, video source 104 is a storage device that stores previously captured / prepared video. In some embodiments, video source 104 is a camera that captures local image information as a video sequence. The video data may be provided as multiple individual pictures that, when viewed sequentially, impart motion. The pictures themselves may be organized as a spatial array of pixels, each of which may contain one or more samples depending on the sampling structure, color space, etc. used. Those skilled in the art will readily understand the relationship between pixels and samples. The following discussion will focus on samples.

[0037] The encoder component 106 is configured to encode and / or compress pictures of a source video sequence into an encoded video sequence 216 in real time or under other time constraints required by the application. Enforcing an appropriate encoding rate is one function of the controller 204. In some embodiments, the controller 204 controls and is operatively coupled to other functional units, as described below. Parameters set by the controller 204 may include rate control-related parameters (e.g., picture skip, quantizer, and / or lambda value for rate-distortion optimization techniques), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. Those skilled in the art will readily identify other functions of the controller 204 as they may be relevant to the encoder component 106 being optimized for certain system designs.

[0038] In some embodiments, the encoder component 106 is configured to operate in an encoding loop. In a simplified example, the encoding loop includes a source coder 202 (e.g., responsible for creating symbols, such as a symbol stream, based on an input picture to be encoded and reference picture(s)) and a (local) decoder 210. The decoder 210 reconstructs the symbols to create sample data in a manner similar to a (remote) decoder (when the compression between the symbols and the encoded video bitstream is lossless). The reconstructed sample stream (sample data) is input to a reference picture memory 208. Because decoding the symbol stream produces bit-for-bit accurate results that are independent of the location of the decoder (local or remote), the contents of the reference picture memory 208 are also bit-for-bit accurate between the local and remote encoders. In this way, the predictive portion of the encoder interprets the same sample values ​​as reference picture samples as a decoder would when using prediction during decoding. This principle of reference picture synchronization (and the resulting drift if synchronization cannot be maintained, eg, due to channel errors) is known to those skilled in the art.

[0039] The operation of decoder 210 may be the same as that of a remote decoder, such as decoder component 122, described in detail below in connection with Figure 2B. However, referring briefly to Figure 2B, because symbols are available and the encoding / decoding of symbols into a coded video sequence by entropy encoder 214 and parser 254 may be lossless, the entropy decoding portion of decoder component 122, including buffer memory 252 and parser 254, may not be fully implemented in local decoder 210.

[0040] An observation that can be made at this point is that any decoder technology, with the exception of parsing / entropy decoding, that exists in the decoder necessarily needs to exist in substantially identical functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on decoder operation. A description of the encoder technology may be omitted, as it is the reverse of the decoder technology, which is described generically. Only in certain areas is more detailed explanation required, and is provided below.

[0041] As part of its operation, the source coder 202 may perform motion-compensated predictive coding, which predictively codes an input frame with reference to one or more previously coded frames from the video sequence designated as reference frames. In this manner, the coding engine 212 encodes differences between pixel blocks of the input frame and pixel blocks of reference frame(s) that may be selected as prediction reference(s) for the input frame. The controller 204 may manage the coding operations of the source coder 202, including, for example, setting parameters and subgroup parameters used to encode the video data.

[0042] The decoder 210 decodes the coded video data of frames that may be designated as reference frames based on symbols created by the source coder 202. The operation of the coding engine 212 may advantageously be a lossy process. When the coded video data is decoded in a video decoder (not shown in FIG. 2A ), the reconstructed video sequence may be a replica of the source video sequence with some errors. The decoder 210 may replicate the decoding process that may be performed by a remote video decoder on the reference frames and store the reconstructed reference frames in the reference picture memory 208. In this way, the encoder component 106 locally stores copies of reconstructed reference frames that have content in common with the reconstructed reference frames that would be obtained by the remote video decoder (in the absence of transmission errors).

[0043] The predictor 206 may perform a prediction search for the coding engine 212. That is, for a new frame to be encoded, the predictor 206 may search the reference picture memory 208 for sample data (as candidate reference pixel blocks) or certain metadata, such as reference picture motion vectors, block shapes, etc., that can serve as a suitable prediction reference for the new picture. The predictor 206 may operate on a sample block / pixel block basis to find a suitable prediction reference. In some cases, as determined by the search results obtained by the predictor 206, the input picture may have prediction references drawn from multiple reference pictures stored in the reference picture memory 208.

[0044] The output of all the aforementioned functional units may be entropy coded in entropy coder 214. Entropy coder 214 converts the symbols produced by the various functional units into an encoded video sequence by losslessly compressing the symbols according to techniques known to those skilled in the art (e.g., Huffman coding, variable length coding, and / or arithmetic coding).

[0045] In some embodiments, the output of the entropy encoder 214 is coupled to a transmitter. The transmitter may be configured to buffer the coded video sequences created by the entropy encoder 214 and prepare them for transmission over a communication channel 218, which may be a hardware / software link to a storage device that will store the encoded video data. The transmitter may be configured to merge the coded video data from the source coder 202 with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown). In some embodiments, the transmitter may transmit additional data along with the encoded video. The source coder 202 may include such data as part of the coded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, Supplemental Enhancement Information (SEI) messages, Visual Usability Information (VUI) parameter set fragments, etc.

[0046] The controller 204 may manage the operation of the encoder component 106. During encoding, the controller 204 may assign each coded picture a coding picture type, which may affect the coding technique applied to the respective picture. For example, a picture may be assigned as an intra picture (I picture), a predicted picture (P picture), or a bidirectionally predicted picture (B picture). An intra picture may be coded and decoded without using other frames in the sequence as a source of prediction. Some video codecs allow different types of intra pictures, including, for example, Independent Decoder Refresh (IDR) pictures. Those skilled in the art will recognize these variations of I pictures and their respective uses and characteristics, and therefore, they will not be repeated here. A predicted picture may be coded and decoded using intra prediction or inter prediction, which uses at most one motion vector and reference index to predict sample values ​​for each block. A bidirectionally predicted picture may be coded and decoded using intra prediction or inter prediction, which uses at most two motion vectors and reference indexes to predict sample values ​​for each block. Similarly, a multi-predictive picture can use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0047] A source picture is typically spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks, as determined by the coding assignment applied to the block's respective picture. For example, blocks of an I picture may be nonpredictively coded or predictively coded with reference to previously coded blocks of the same picture (spatial prediction or intra-prediction). Pixel blocks of a P picture may be coded nonpredictively via spatial prediction or via temporal prediction with reference to one previously coded reference picture. Blocks of a B picture may be coded nonpredictively via spatial prediction or via temporal prediction with reference to one or two previously coded reference pictures.

[0048] Video may be captured as multiple source pictures (video pictures) in a time sequence. Intra-picture prediction (often abbreviated as intra-prediction) exploits spatial correlation within a given picture, while inter-picture prediction exploits correlation (temporal or otherwise) between pictures. In one example, a particular picture being encoded / decoded, called the current picture, is partitioned into blocks. When a block in the current picture is similar to a reference block in a previously coded, yet buffered, reference picture in the video, the block in the current picture may be coded by a vector called a motion vector. A motion vector points to a reference block within the reference picture and may have a third dimension that identifies the reference picture if multiple reference pictures are used.

[0049] The encoder component 106 may perform encoding operations according to a given video encoding technique or standard, such as any of those described herein. In doing so, the encoder component 106 may perform various compression operations, including predictive encoding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the encoded video data may conform to a syntax specified by the video encoding technique or standard being used.

[0050] 2B is a block diagram illustrating exemplary elements of the decoder component 122, according to some embodiments. The decoder component 122 of FIG. 2B is coupled to the channel 218 and the display 124. In some embodiments, the decoder component 122 includes a transmitter coupled to the loop filter unit 256 and configured to transmit data to the display 124 (e.g., via a wired or wireless connection).

[0051] In some embodiments, decoder component 122 includes a receiver coupled to channel 218 and configured to receive data from channel 218 (e.g., via a wired or wireless connection). The receiver may be configured to receive one or more coded video sequences to be decoded by decoder component 122. In some embodiments, the decoding of each coded video sequence is independent of the other coded video sequences. Each coded video sequence may be received from channel 218, which may be a hardware / software link to a storage device that stores the encoded video data. The receiver may receive the encoded video data along with other data, such as coded audio data and / or auxiliary data streams, which may be forwarded to a respective using entity (not shown). The receiver may separate the coded video sequence from the other data. In some embodiments, the receiver receives additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence(s). The additional data may be used by the decoder component 122 to decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or SNR enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0052] According to some embodiments, the decoder component 122 includes a buffer memory 252, a parser 254 (sometimes referred to as an entropy decoder), a scaler / inverse transform unit 258, an intra-picture prediction unit 262, a motion compensated prediction unit 260, an aggregator 268, a loop filter unit 256, a reference picture memory 266, and a current picture memory 264. In some embodiments, the decoder component 122 is implemented as an integrated circuit, a series of integrated circuits, and / or other electronic circuitry. In some embodiments, the decoder component 122 is implemented at least partially in software.

[0053] Buffer memory 252 is coupled between channel 218 and parser 254 (e.g., to address network jitter). In some embodiments, buffer memory 252 is separate from decoder component 122. In some embodiments, a separate buffer memory is provided between the output of channel 218 and decoder component 122. In some embodiments, in addition to buffer memory 252 within decoder component 122 (e.g., configured to handle playout timing), a separate buffer memory is provided external to decoder component 122 (e.g., to address network jitter). When receiving data from a storage / forwarding device with sufficient bandwidth and controllability or from an isochronous network, buffer memory 252 may not be required or may be small. For use over best-effort packet networks such as the Internet, buffer memory 252 may be required, may be relatively large, may advantageously be adaptively sized, and may be implemented, at least in part, in an operating system or similar element (not shown) external to decoder component 122.

[0054] The parser 254 is configured to reconstruct symbols 270 from the coded video sequence. The symbols may include, for example, information used to manage the operation of the decoder component 122 and / or information for controlling a rendering device such as the display 124. The control information for the rendering device may be in the form of, for example, a Supplemental Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser 254 parses (entropy decodes) the coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow principles well known to those skilled in the art, including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser 254 may extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroups may include groups of pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. Parser 254 may also extract information from the coded video sequence, such as transform coefficients, quantizer parameter values, motion vectors, etc.

[0055] The reconstruction of symbols 270 may involve several different units, depending on the type of coded video picture or portion thereof (e.g., inter-picture and intra-picture, inter-block and intra-block, etc.), as well as other factors. Which units are involved and how they are involved may be controlled by subgroup control information parsed from the coded video sequence by parser 254. The flow of such subgroup control information between parser 254 and the following units is not shown for clarity.

[0056] In addition to the functional blocks already mentioned, the decoder component 122 can be conceptually subdivided into a number of functional units, as described below. In a practical implementation operating under commercial constraints, many of these units will interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the conceptual subdivision into the following functional units will be maintained.

[0057] The scaler / inverse transform unit 258 receives the quantized transform coefficients as well as control information (such as which transform to use, block size, quantization factor, and / or quantization scaling matrix) from the parser 254 as symbol(s) 270. The scaler / inverse transform unit 258 may output blocks containing sample values ​​that may be input to the aggregator 268.

[0058] In some cases, the output samples of the scalar / inverse transform unit 258 relate to intra-coded blocks, i.e., blocks that do not use prediction information from a previously reconstructed picture but may use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by the intra picture prediction unit 262, which may generate blocks of the same size and shape as the block being reconstructed using surrounding already reconstructed information retrieved from the current (partially reconstructed) picture from the current picture memory 264. The aggregator 268 may add, on a sample-by-sample basis, the prediction information generated by the intra picture prediction unit 262 to the output sample information provided by the scalar / inverse transform unit 258.

[0059] In other cases, the output samples of the scalar / inverse transform unit 258 relate to an inter-coded, potentially motion-compensated block. In such cases, the motion-compensated prediction unit 260 can access the reference picture memory 266 to fetch samples used for prediction. After motion-compensating the fetched samples according to the symbols 270 for that block, these samples can be added by the aggregator 268 to the output of the scalar / inverse transform unit 258 (in this case, referred to as residual samples or a residual signal) to generate output sample information. The addresses in the reference picture memory 266 from which the motion-compensated prediction unit 260 fetches the prediction samples can be controlled by a motion vector. The motion vector can be available to the motion-compensated prediction unit 260 in the form of a symbol 270, which can have, for example, X, Y, and reference picture components. Motion compensation can also include interpolation of sample values ​​fetched from the reference picture memory 266 when sub-sample-accurate motion vectors are used, motion vector prediction mechanisms, and the like.

[0060] The output samples of aggregator 268 may be subjected to various loop filtering techniques in loop filter unit 256. The in-loop filter techniques, which may include video compression techniques, are controlled by parameters contained in the coded video bitstream and made available to loop filter unit 256 as symbols 270 from parser 254, but may also be responsive to meta-information obtained during decoding of a previous portion (in decoding order) of the coded picture or coded video sequence, or may be responsive to previously reconstructed loop-filtered sample values.

[0061] The output of the loop filter unit 256 may be a sample stream that may be output to a rendering device such as the display 124 or stored in a reference picture memory 266 for use in future inter-picture prediction.

[0062] Certain coded pictures, once fully reconstructed, may be used as reference pictures for future predictions. Once a coded picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by parser 254), the current reference picture may become part of reference picture memory 266, and a fresh current picture memory may be reallocated before beginning reconstruction of a subsequent coded picture.

[0063] Decoder component 122 may perform decoding operations according to a given video compression technique, which may be documented in a standard, such as any of the standards described herein. A coded video sequence may conform to the syntax specified by the video compression technique or standard being used, in the sense that it conforms to the syntax of the video compression technique or standard, as specified in the video compression technique document or standard, particularly the profile document therein. To comply with some video compression techniques or standards, the complexity of the coded video sequence may also be within a range defined by the level of the video compression technique or standard. In some cases, the level constrains the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may, in some cases, be further constrained through a Hypothetical Reference Decoder (HRD) specification and metadata for HRD buffer management signaled in the coded video sequence.

[0064] 3 is a block diagram illustrating a server system 112 according to some embodiments. The server system 112 includes a control circuit 302, one or more network interfaces 304, a memory 314, a user interface 306, and one or more communication buses 312 for interconnecting these components. In some embodiments, the control circuit 302 includes one or more processors (e.g., a CPU, a GPU, and / or a DPU). In some embodiments, the control circuit includes one or more field programmable gate arrays (FPGAs), hardware accelerators, and / or one or more integrated circuits (e.g., application specific integrated circuits).

[0065] The network interface 304 may be configured to interface with one or more communications networks (e.g., wireless, wireline, and / or optical networks). The communications networks may be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, etc. Examples of communications networks include local area networks such as Ethernet; cellular networks including WLAN, GSM, 3G, 4G, 5G, LTE, etc.; TV wired or wireless wide-area digital networks including cable TV, satellite TV, and terrestrial broadcast TV; vehicular and industrial networks including CANbus; and the like. Such communications may be one-way, receive only (e.g., broadcast TV), one-way transmit only (e.g., CANbus to certain CANbus devices), or bidirectional (e.g., to other computer systems using local or wide-area digital networks). Such communications may include communications to one or more cloud computing networks.

[0066] The user interface 306 includes one or more output devices 308 and / or one or more input devices 310. The input devices 310 may include one or more of a keyboard, a mouse, a trackpad, a touchscreen, a data glove, a joystick, a microphone, a scanner, a camera, etc. The output devices 308 may include one or more of an audio output device (e.g., a speaker), a visual output device (e.g., a display or monitor), etc.

[0067] Memory 314 may include high-speed random-access memory (such as DRAM, SRAM, DDR RAM, and / or other random-access solid-state memory devices) and / or non-volatile memory (such as one or more magnetic storage devices, optical disk storage devices, flash memory devices, and / or other non-volatile solid-state storage devices). Memory 314 optionally includes one or more storage devices located remotely from control circuitry 302. Memory 314, or alternatively, a non-volatile solid-state memory device within memory 314, comprises a non-transitory computer-readable storage medium. In some embodiments, memory 314 or the non-transitory computer-readable storage medium of memory 314 stores the following programs, modules, instructions, and data structures, or a subset or superset thereof: • an operating system 316 that handles various basic system services and contains procedures for performing hardware-dependent tasks; • a network communications module 318 used to connect the server system 112 to other computing devices via one or more network interfaces 304 (e.g., via wired and / or wireless connections); • An encoding module 320 for performing various functions related to encoding and / or decoding data, such as video data. In some embodiments, the encoding module 320 is an instance of the coder component 114. The encoding module 320 may include, but is not limited to: a decoding module 322 for performing various functions related to decoding the encoded data, such as those previously described with respect to the decoder component 122; An encoding module 340 for performing various functions related to encoding data, such as those previously described with respect to the encoder component 106. including one or more of the following; ● Picture memory 352 for storing pictures and picture data, e.g., for use with encoding module 320. In some embodiments, picture memory 352 includes one or more of reference picture memory 208, buffer memory 252, current picture memory 264, and reference picture memory 266.

[0068] In some embodiments, the decode module 322 includes a parsing module 324 (e.g., configured to perform various functions previously described with respect to the parser 254), a transform module 326 (e.g., configured to perform various functions previously described with respect to the scalar / inverse transform unit 258), a prediction module 328 (e.g., configured to perform various functions previously described with respect to the motion compensated prediction unit 260 and / or the intra picture prediction unit 262), and a filter module 330 (e.g., configured to perform various functions previously described with respect to the loop filter unit 256).

[0069] In some embodiments, the encoding module 340 includes a code module 342 (e.g., configured to perform various functions previously described with respect to the source coder 202, the coding engine 212, and / or the entropy coder 214) and a prediction module 344 (e.g., configured to perform various functions previously described with respect to the predictor 206). In some embodiments, the decoding module 322 and / or the encoding module 340 include a subset of the modules shown in FIG. 3. For example, a shared prediction module is used by both the decoding module 322 and the encoding module 340.

[0070] Each of the above-identified modules stored in memory 314 corresponds to a set of instructions for performing functions described herein. The above-identified modules (e.g., sets of instructions) need not be implemented as separate software programs, procedures, or modules; thus, various subsets of these modules may be combined or otherwise rearranged in various embodiments. For example, encoding module 320 optionally does not include separate decoding and encoding modules, but rather uses the same set of modules to perform both sets of functionality. In some embodiments, memory 314 stores a subset of the above-identified modules and data structures. In some embodiments, memory 314 stores additional modules and data structures not described above, such as an audio processing module.

[0071] In some embodiments, the server system 112 includes a web or Hypertext Transfer Protocol (HTTP) server, a File Transfer Protocol (FTP) server, and web pages and applications implemented using Common Gateway Interface (CGI) scripts, the PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), Hypertext Markup Language (HTML), Extensible Markup Language (XML), Java, JavaScript, Asynchronous JavaScript and XML (AJAX), XHP, Javelin, Wireless Universal Resource Files (WURFL), etc.

[0072] While FIG. 3 illustrates a server system 112 according to some embodiments, FIG. 3 is not intended as an architectural schematic of the embodiments described herein, but rather as a functional description of various features that may be present in one or more server systems. In practice, items shown separately may be combined, and some items may be separated, as will be recognized by those skilled in the art. For example, some items shown separately in FIG. 3 may be implemented on a single server, and a single item may be implemented by one or more servers. The actual number of servers used to implement server system 112, and how functionality is allocated among them, will vary from implementation to implementation and, optionally, will depend in part on the amount of data traffic the server system handles during peak usage periods as well as during average usage periods.

[0073] Examples of encoding techniques As mentioned above, an inter-predicted block is a block in a video compression stream that is represented using one or more neighboring blocks. For each inter-predicted coding unit (CU), motion parameters such as a motion vector, a reference picture index, and a reference picture list usage index may be used to generate inter-predicted samples. The motion parameters can be signaled explicitly or implicitly. If a CU is coded in skip mode, the CU may be associated with a prediction unit (PU) and may not have significant residual coefficients, for example, no coded motion vector delta or reference picture index. A merge mode may be specified, in which case motion parameters for the current CU are obtained from neighboring CUs, including spatial and temporal candidates. The merge mode can be applied to any inter-predicted CU, not just for skip mode. An alternative to the merge mode is explicit transmission of motion parameters, in which a motion vector, a corresponding reference picture index for each reference picture list, and a reference picture list usage flag are explicitly signaled for each CU.

[0074] 4A illustrates exemplary positions of spatial block candidates according to some embodiments. For example, up to four merge candidates are selected from among candidates located at positions A0, A1, B0, B1, and / or B2. In some embodiments, the derivation (scanning) order is B1, A1, B0, A0, and B2. In some embodiments, position B2 is considered only if the CUs at positions A0, B0, B1, and / or A1 are unavailable (e.g., because they belong to another slice or tile) or are intra-coded. In some embodiments, other spatial neighboring blocks are scanned.

[0075] To improve coding efficiency and reduce motion vector transmission overhead, subblock-level motion vector refinement can be applied to extend CU-level temporal motion vector prediction (TMVP). Subblock-based TMVP (SbTMVP) allows subblock-level motion information inheritance from co-located reference pictures. Each subblock of a large-sized CU can have its own motion information without explicitly transmitting block partition structure or motion information. For example, the SbTMVP process can obtain motion information for each subblock in three steps. In this example, the first step is to derive the displacement vector (DV) of the current CU. The second step is to check the availability of SbTMVP candidates and derive the center motion vector. The third step is to derive subblock motion information from the corresponding subblocks via DV. Unlike TMVP candidate derivation, which always derives temporal motion vectors from co-located blocks in a reference frame, SbTMVP can apply DVs derived from the MVs of the current CU's left neighboring CU to find the corresponding sub-block in the co-located picture for each sub-block of the current CU. If the corresponding sub-block is not inter-coded, the motion information of the current sub-block can be set to the central motion.

[0076] In this way, SbTMVP uses motion fields in the co-located picture to improve the motion vector prediction and merge mode for the CU in the current picture. For example, the same co-located picture used by the TMVP process can be used for SbTMVP. SbTMVP differs from TMVP in two main aspects: First, TMVP predicts motion at the CU level, while SbTMVP predicts motion at the sub-CU level. Second, TMVP fetches temporal motion vectors from a co-located block in the co-located picture (e.g., the co-located block is the bottom-right or center block relative to the current CU), whereas SbTMVP applies a motion shift before fetching temporal motion information from the co-located picture. Here, the motion shift is derived from a motion vector from one of the spatial neighboring blocks of the current CU. In this way, sub-block MVP can be inherited from the co-located picture.

[0077] FIG. 4B shows an exemplary sub-block motion field according to some embodiments. The SbTMVP process is illustrated in FIG. 4B. For example, SbTMVP predicts motion vectors of sub-CUs within a current CU in two stages. The first stage examines the spatial neighborhood A1 in FIG. 4B. If A1 has a motion vector that uses a co-located picture as its reference picture, this motion vector is selected as the motion shift (or displacement vector) to be applied. If no such motion is identified, the motion shift can be set to (0,0).

[0078] In the second stage, the motion shift identified in stage 1 is applied (e.g., added to the coordinates of the current block) to obtain sub-CU-level motion information (e.g., motion vectors and reference indexes) from the co-located picture, as shown in FIG. 4B. In the example of FIG. 4B, it is assumed that the motion shift is set to the motion of block A1. Then, for each sub-CU, the motion information of the corresponding block in the co-located picture (e.g., the smallest motion grid covering the center sample) is used to derive motion information for the sub-CU. After the motion information of the co-located sub-CU is identified, it is converted into the motion vector and reference index of the current sub-CU. This conversion is followed by temporal motion scaling to align the reference picture of the temporal motion vector with that of the current CU, in a manner similar to the TMVP process (e.g., in HEVC).

[0079] In some embodiments, a combined subblock-based merge list containing SbTMVP candidates and affine merge candidates is used to signal the subblock-based merge mode. In some embodiments, the SbTMVP mode is enabled / disabled by a sequence parameter set (SPS) flag. For example, when the SbTMVP mode is enabled, the SbTMVP predictor is added as the first entry in the list of subblock-based merge candidates, followed by the affine merge candidates. The size of the subblock-based merge list is signaled in the SPS.

[0080] The sub-CU size used in SbTMVP can be fixed at 8x8 (e.g., in VVC), and like the affine merge mode, SbTMVP mode may only be applicable to CUs whose width and height are both 8 or greater. In some embodiments, the sub-block size may be configurable to other sizes, such as 4x4. As an example, two co-located frames can be used to provide temporal motion information for SbTMVP and TMVP in AMVP mode.

[0081] FIG. 4C illustrates an exemplary motion vector refinement according to some embodiments. In some embodiments, decoder-side motion vector refinement (DMVR) is applied to CUs coded in normal merging mode. MV pairs resulting from normal merging candidates can be used as input for the DMVR process. DMVR applies bilateral matching (BM) to refine the input MV pairs (mv L0 , mv L1 ) and use the refined MV pair for motion compensated prediction of both luma and chroma components (e.g., as shown in FIG. 4C ). In some embodiments, the output MVs of the DMVR are called refined MV pairs and obey the following equation: MV refinedL0 =mv L0 +Δmv MV refinedL1 =mv L1 -Δmv Equation 1

[0082] The motion vector difference,Δmv,can be applied to the input MV pair to obtain a refined,MV pair using the mirror symmetry property of MVD.,For example, the input MV pair refers to two different reference,pictures that have equal difference with the current picture in picture order,count (POC), and these two reference pictures are in different,temporal directions.

[0083] In DMVR, a luma coding block can be divided into 16x16 sub-blocks for the MV refinement process. Δmv can be derived independently for each sub-block by performing integer precision motion search followed by fractional precision motion search. Finally, the refined MV pair {mv refinedL0 ,mv refinedL1 Sub-block motion compensation (MC) can be applied using {}. In this way, the system can compare the differences and select the motion vector with the smallest difference.

[0084] In some embodiments, bidirectional optical flow (BDOF) is utilized. BDOF is used to refine the bi-predictive signal of a CU at the 4x4 sub-block level. For example, BDOF is applied to a CU if the CU satisfies all of the following conditions: (i) the CU is coded using a "true" bi-predictive mode. For example, one of two reference pictures precedes the current picture in display order, and the other follows the current picture in display order; (ii) the distances (e.g., POC difference) from the two reference pictures to the current picture are the same; (iii) both reference pictures are short-term reference pictures; (iv) the CU is not coded using affine mode or SbTMVP merge mode; (v) the CU has more than 64 luma samples; (vi) both the CU height and CU width are equal to or greater than 8 luma samples; (vii) the BCW weight index indicates equal weights; (viii) WP is not enabled for the current CU; and (ix) CIIP mode is not used for the current CU.

[0085] BDOF is only applied to the luma component. The BDOF mode is based on the concept of optical flow, which assumes smooth object motion. For each 4x4 sub-block, motion refinement (v) is achieved by minimizing the difference between the L0 and L1 prediction samples. x ,v y ) is calculated. Then, motion refinement is used to adjust the bi-predicted sample values ​​within the 4x4 sub-block. In the BDOF process, the following procedures are applied:

[0086] First, the horizontal and vertical gradients of the two predicted signals, ∂I, are calculated by directly calculating the difference between two nearby samples. (k) (i,j) / ∂x and ∂I (k) (i,j) / ∂y, k=0,1 is calculated.

number

[0087] Next, the autocorrelation and cross-correlation of the gradients S1, S2, S3, S5, and S6

number

[0088] The cross-correlation and auto-correlation terms are then used to refine the motion (v x ,v y ) is derived.

number

[0089] Based on the motion refinement and gradients, the following adjustments are calculated for each sample in the 4x4 sub-block:

number

[0090] The BDOF samples of a CU are calculated by adjusting the bi-predictive samples as follows:

number

[0091] In some embodiments, these values ​​are selected so that the multiplier of the BDOF process does not exceed 15 bits, and the maximum bit width of the intermediate parameters of the BDOF process is kept within 32 bits.

[0092] To derive the gradient value, we select some predicted samples I in list k (k=0,1) that are outside the current CU boundary. (k) (i,j) is generated. As an example, BDOF in VVC uses one extended row / column around the boundary of the CU. To control the computational complexity of generating out-of-bounds predicted samples, predicted samples within the extended area (white locations) can be generated directly by taking reference samples at nearby integer locations (e.g., using the floor() operation on the coordinates) without interpolation, and a regular 8-tap motion compensation interpolation filter is used to generate predicted samples within the CU. These extended sample values ​​are only used in gradient calculations. For the remaining stages of the BDOF process, samples and gradient values ​​outside the CU boundary can be padded (e.g., repeated) from their nearest neighbors if needed.

[0093] In sample-based BDOF, motion refinement (v x ,v y ), but is performed sample by sample. For example, a coding block is divided into 8x8 sub-blocks. For each sub-block, whether to apply BDOF is determined by checking the SAD between two reference sub-blocks against a threshold. For example, when applying BDOF to a sub-block, a sliding 5x5 window is used and the existing BDOF process is applied for every sample in the sub-block, v x and v y The derived motion refinement (v x ,v y ) to adjust the bi-predicted sample value for the center sample of the window.

[0094] There are many types of motion, such as zoom in / out, rotation, perspective motion, and other irregular motions. Therefore, block-based affine transformation motion compensation prediction can be applied. As shown in Figure 4D, the affine motion field of a block is described by motion information of two control points (e.g., four parameters) as shown in (a) or three control point motion vectors (e.g., six parameters) as shown in (b).

[0095] For a four-parameter affine motion model, the motion vector at a sample position (x,y) within a block is derived as follows:

number

[0096] For a six-parameter affine motion model, the motion vector at a sample position (x,y) within a block is derived as follows:

number

[0097] To simplify motion-compensated prediction, block-based affine transformation prediction can be applied. To derive the motion vector for each 4x4 luma sub-block, the motion vector of the center sample of each sub-block, as shown in Figure 4E, is calculated according to the above formula and rounded to 1 / 16 fractional precision. A motion-compensated interpolation filter is then applied to generate a prediction for each sub-block using the derived motion vector. The sub-block size for the chroma components is also set to 4x4. For example, the motion vector (MV) of a 4x4 chroma sub-block is calculated as the average of the motion vectors of the four corresponding 4x4 luma sub-blocks.

[0098] In the above sub-block motion modes (e.g., sub-block TMVP, sub-block DMVR, and affine motion), sub-block motion vectors are implicitly derived based on assumptions about the coded MV field or a specific motion model. However, the optimal sub-block MVs may not follow the assumptions of the respective motion models, which reduces encoding / decoding accuracy (coding efficiency).

[0099] Figures 5A-B show exemplary sub-block motion vector differentials according to some embodiments. Figure 5A shows the respective motion vectors (MVs), motion vector predictors (MVPs), and motion vector differentials (MVDs) for each sub-block of a current block 502. Figure 5B shows the respective MVDs for each sub-block.

[0100] 6A is a flow diagram illustrating a method 600 for encoding video according to some embodiments. Method 600 may be performed in a computing system (e.g., server system 112, source device 102, or electronic device 120) having control circuitry and memory storing instructions for execution by the control circuitry. In some embodiments, method 600 is performed by executing instructions stored in memory (e.g., memory 314) of the computing system.

[0101] The system obtains video data including a plurality of blocks, including a first block (602). The system derives a set of motion vector predictors (MVPs) corresponding to a plurality of sub-blocks of the first block (604). The system derives a set of motion vectors for the plurality of sub-blocks (606). The system determines a set of motion vector differentials (MVDs) for the plurality of sub-blocks by comparing the set of MVPs with the set of motion vectors (608). The system signals the set of MVDs in a video bitstream (610).

[0102] In some embodiments, at the encoder, the sub-block MVD is put into an M×N block (e.g., M and N equal 4 luma samples in the example of FIG. 5B), as shown in the example of FIG. 5B, and a transform process is applied to this MVD block to derive one or more MVD coefficient blocks. In some embodiments, the MVD block is further divided into two MVD blocks, one having only horizontal components and the other having only vertical components. In some embodiments, each of the two MVD blocks is input into a transform process to derive a transform coefficient block for the associated MVD block. In some embodiments, if the block or sub-block is in inter-prediction mode, the sub-block MVD for each reference list is derived and transformed independently.

[0103] In some embodiments, if a reference list of a sub-block's MVP is not available, a zero MVD is used for the reference list of the sub-block. In some embodiments, if a reference list of that MVP is not available, the sub-block is identified as unavailable and a shape-adaptive transform is applied to the sub-blocks with an available MVD in their reference list.

[0104] In some embodiments, the MVD coefficients derived in the transform domain are further quantized, and the quantized MVD coefficients are further input to an entropy coder to encode the values ​​of the quantized MVD coefficients.

[0105] 6B is a flow diagram illustrating a method 650 for decoding video according to some embodiments. Method 650 may be performed in a computing system (e.g., server system 112, source device 102, or electronic device 120) having control circuitry and memory storing instructions for execution by the control circuitry. In some embodiments, method 650 is performed by executing instructions stored in memory (e.g., memory 314) of the computing system.

[0106] The system receives (652) a video bitstream including a plurality of blocks, including a first block, where the first block includes a plurality of sub-blocks. The system determines (654) that the first block is predicted in sub-block mode based on a syntax element value in the video bitstream. In response to (656) that the first block is predicted in sub-block mode, the system derives (658) a set of motion vector predictors (MVPs) corresponding to a plurality of sub-blocks of the first block. The system derives (660) a set of motion vector differentials (MVDs) for the plurality of sub-blocks. The system determines (662) a set of motion vectors for the plurality of sub-blocks by applying the set of MVDs to the set of MVPs. The system reconstructs (664) the first block using the set of motion vectors.

[0107] In some embodiments, the system first derives a subblock MVP for each subblock, then the subblock MVD is further encoded, and a motion vector is derived by adding the subblock MVP and the associated subblock MVD. An example is shown in A of Figure 5, where a motion vector predictor (indicated by a solid black arrow) is derived, then an MVD is applied to each subblock (indicated by a dotted arrow), and then a motion vector for each subblock is derived by adding the subblock MVP and the associated subblock MVD (indicated by a dashed arrow).

[0108] In some embodiments, the sub-block MVP is derived using MVs of spatially neighboring blocks based on a motion model (such as translational, affine, warped, or planar motion model), or is derived by coded motion vectors stored for the sub-block in a temporally co-located picture, or by template matching, or by DMVR.

[0109] In some embodiments, at the decoder, one or more MVD coefficient blocks are first derived, and an inverse transform process is applied to these MVD coefficient blocks to derive an MVD for each sub-block. The sub-block MVD is then added onto the associated sub-block MVP to derive a sub-block MV, which is used to perform sub-block motion compensation.

[0110] In some embodiments, one inverse transform is applied to one of the multiple MVD coefficient blocks to derive a block of horizontal components of the sub-block MVD, and one inverse transform is applied to one of the multiple MVD coefficient blocks to derive a block of vertical components of the sub-block MVD. In some embodiments, the block of horizontal components of the sub-block MVD and the block of vertical components of the sub-block MVD are merged into one block of MVD. In some embodiments, if the block or sub-block is in inter bi-prediction mode, the sub-block MVD for each reference list is processed separately.

[0111] In some embodiments, if a reference list of a sub-block's MVP is not available, a zero MVD is used for the reference list of the sub-block. In some embodiments, if a reference list of that MVP is not available, the sub-block is identified as unavailable and a shape adaptive transform is applied to the sub-block with an available MVD in its reference list.

[0112] In some embodiments, the quantization step size is indicated by a high-level syntax. In some embodiments, the precision of the sub-block MV and / or MVD is determined by the high-level syntax. For example, the high-level syntax corresponds to the sequence level, frame level, slice level, or tile level. In some embodiments, the high-level syntax is higher than the block level. For example, the high-level syntax may include a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, a picture header, a tile header, and / or a CTU header. In some embodiments, the precision of the sub-block MV and / or MVD may be signaled at the coding block level. For example, a block-level AMVR index may be used to indicate the precision of the MV / MVD. In another example, a separate sub-block MV precision syntax may be used.

[0113] 6A and 6B show some logical stages in a particular order, but stages that are not order-dependent may be reordered, and other stages may be combined or separated. Some reordering or other groupings not specifically mentioned will be apparent to those skilled in the art, and therefore the ordering and groupings presented herein are not exhaustive. Furthermore, it should be recognized that the various stages may be implemented in hardware, firmware, software, or any combination thereof.

[0114] We now turn to some exemplary embodiments.

[0115] (A1) In certain aspects, some embodiments include a method of video decoding (e.g., method 650). In some embodiments, the method is performed in a computing system (e.g., server system 112) having memory and control circuitry. In some embodiments, the method is performed in an encoding module (e.g., encoding module 320). In some embodiments, the method is performed in a parser (e.g., parser 254). The method includes: (i) receiving a video bitstream including a plurality of blocks, including a first block, the first block including a plurality of sub-blocks; (ii) determining, based on syntax element values ​​in the video bitstream, that the first block is predicted in sub-block mode; and (iii) in response to the first block being predicted in sub-block mode, (a) deriving a set of motion vector predictors (MVPs) corresponding to the plurality of sub-blocks of the first block; (b) deriving a set of motion vector differentials (MVDs) for the plurality of sub-blocks; (c) determining a set of motion vectors for the plurality of sub-blocks by applying the set of MVDs to the set of MVPs; and (d) reconstructing the first block using the set of motion vectors. For example, a first sub-block MVP is derived, and then a sub-block MVD is derived. Then, for each sub-block, a motion vector is derived by adding the sub-block MVP and the associated sub-block MVD.

[0116] (A2) In some embodiments of A1, the set of MVPs is derived using a motion model and one or more spatially neighboring motion vectors. For example, the sub-block MVPs are derived using MVs of spatially neighboring blocks based on a motion model (such as translational, affine, warped, or planar motion model).

[0117] (A3) In some embodiments of A1 or A2, the set of MVPs is derived based on one or more coded motion vectors corresponding to one or more temporally co-located blocks. For example, the MVPs are derived from coded motion vectors stored for sub-blocks within the temporally co-located picture. In some embodiments, the set of MVPs is obtained using template matching and / or decoder-side motion vector refinement (DMVR).

[0118] (A4) In some embodiments of any of A1-A3, the method further includes obtaining, from the video bitstream, one or more MVD coefficient blocks corresponding to the plurality of sub-blocks of the first block, wherein the set of MVDs is obtained by performing an inverse transform on the one or more MVD coefficient blocks. For example, the one or more MVD coefficient blocks are determined using video data from the video bitstream.

[0119] (A5) In some embodiments of A4, the one or more MVD coefficient blocks include a first MVD coefficient block corresponding to a horizontal MVD component and a second MVD coefficient block corresponding to a vertical MVD component. In some embodiments, a first inverse transform is applied to the first MVD coefficient block to derive a block of horizontal components of the sub-block MVD, and a second inverse transform is applied to the second coefficient block to derive a block of vertical components of the sub-block MVD.

[0120] (A6) In some embodiments of A5, the method further includes (i) obtaining horizontal MVD components from the first MVD coefficient block, and (ii) obtaining vertical MVD components from the second MVD coefficient block. Here, the MVD set is obtained by combining the horizontal MVD components and the vertical MVD components. For example, a block of horizontal components of the sub-block MVD and a block of vertical components of the sub-block MVD are merged into a single block of MVD.

[0121] (A7) In some embodiments of A4 or A5, the one or more MVD coefficient blocks include: (i) a first MVD coefficient block corresponding to a horizontal MVD component for the first prediction; (ii) a second MVD coefficient block corresponding to a vertical MVD component for the first prediction; (iii) a third MVD coefficient block corresponding to a horizontal MVD component for the second prediction; and (iv) a fourth MVD coefficient block corresponding to a vertical MVD component for the second prediction. For example, if a block or sub-block is in inter bi-prediction mode, the sub-block MVD for each reference list may be processed separately.

[0122] (A8) In some embodiments of any of A4-A7, a zero MVD is assigned to one or more of the plurality of sub-blocks that do not have an available MVP. For example, if a reference list of an MVP for a sub-block is not available, a zero MVD is used for the sub-block's reference list.

[0123] (A9) In some embodiments of any of A4 to A8, one or more sub-blocks of the plurality of sub-blocks are designated as unavailable pursuant to a determination that the one or more sub-blocks do not have an available MVP.

[0124] (A10) In some embodiments of A9, a shape adaptive transform is applied to the one or more MVD coefficient blocks to obtain a set of MVDs. For example, a sub-block is identified as unavailable if its MVP reference list is unavailable, and a shape adaptive transform is applied to sub-blocks with available MVPs. In some embodiments, the shape adaptive transform is a four-point transform and / or a two-point transform. In some embodiments, the shape adaptive transform is applied in conjunction with another transform (e.g., a DCT or a Hadamard transform).

[0125] (A11) In some embodiments of any of A4 to A10, quantized MVD coefficients are obtained from the one or more MVD coefficient blocks, and a set of MVDs is derived from the quantized MVD coefficients. For example, the MVD coefficients derived in the transform domain can be further quantized, and the quantized MVD coefficients are further input to an entropy coder to encode the values ​​of the quantized MVD coefficients.

[0126] (A12) In some embodiments of A11, the quantization step size is obtained from high-level syntax in the video bitstream. For example, the high-level syntax corresponds to a sequence level, a frame level, a slice level, or a tile level. In some embodiments, the high-level syntax is higher than the block level. For example, the high-level syntax may include a VPS, an SPS, a PPS, an APS, a slice header, a picture header, a tile header, and / or a CTU header.

[0127] (A13) In some embodiments of any of A1-A12, the precision for the set of MVDs is obtained from a high-level syntax in the video bitstream. In some embodiments, the precision of the sub-block MVs and / or MVDs is determined by the high-level syntax.

[0128] (A14) In some embodiments of any of A1-A12, the precision for the set of MVDs is obtained from block-level syntax in the video bitstream. In some embodiments, the precision of the sub-block MVs and / or MVDs is signaled at the coding block level. For example, a block-level AMVR index may be used to indicate the precision of the MV / MVDs. As another example, a separate sub-block MV precision syntax may be used.

[0129] (A15) In some embodiments of A1-A14, the video bitstream corresponds to video encoded according to any of B1-B8 below.

[0130] (B1) In another aspect, some embodiments include a method of video encoding (e.g., method 600). In some embodiments, the method is implemented in a computing system (e.g., server system 112) having memory and control circuitry. In some embodiments, the method is implemented in an encoding module (e.g., encoding module 320). In some embodiments, the method is implemented in an entropy encoder (e.g., entropy encoder 214). The method includes (i) obtaining video data including a plurality of blocks including a first block; (ii) deriving a set of motion vector predictors (MVPs) corresponding to a plurality of sub-blocks of the first block; (iii) deriving a set of motion vectors for the plurality of sub-blocks; (iv) determining a set of motion vector differentials (MVDs) for the plurality of sub-blocks by comparing the set of MVPs to the set of motion vectors; and (v) signaling the set of MVDs in a video bitstream.

[0131] (B2) In some embodiments of B1, the set of MVPs is derived using a motion model and the motion vectors of one or more spatial neighbors.

[0132] (B3) In some embodiments of B1 or B2, the set of MVPs is derived based on one or more coded motion vectors corresponding to one or more temporally co-located blocks.

[0133] (B4) In some embodiments of any of B1-B3, the method further includes obtaining an MVD coefficient block by applying a transform to the set of MVDs, and signaling the set of MVDs includes signaling the MVD coefficient block. For example, the transform is a discrete cosine transform (DCT), a Hadamard transform, an eigenvector transform, or a Karhunen-Loeve transform (KLT). As an example, in an encoder, the sub-block MVDs are put into an M×N block (e.g., M and N equal 4 luma samples), and a transform process is applied to this block of MVDs to derive one or more MVD coefficient blocks.

[0134] (B5) In some embodiments of B4, obtaining an MVD coefficient block includes assigning a zero MVD to each sub-block of the plurality of sub-blocks for which a reference MVP is unavailable.

[0135] (B6) In some embodiments of B4 or B5, obtaining the MVD coefficient block includes (i) designating a sub-block of the plurality of sub-blocks as unavailable in response to determining that the sub-block does not have an available MVP, and (ii) applying a shape adaptive transform to an available sub-block of the plurality of sub-blocks.

[0136] (B7) In some embodiments of any of B1-B6, the method further includes obtaining, from the set of MVDs, a first MVD block corresponding to a horizontal MVD component and a second MVD block corresponding to a vertical MVD component. For example, the MVD block is further divided into two MVD blocks, one having only a horizontal component and the other having only a vertical component. In some embodiments, a respective first and second MVD block is obtained for each prediction of one or more motion predictions for a particular sub-block of the plurality of sub-blocks.

[0137] (B8) In some embodiments of B7, the method further includes (i) obtaining a first MVD coefficient block by applying a transform to the first MVD block; and (ii) obtaining a second MVD coefficient block by applying a transform to the second MVD block. Here, signaling the set of MVDs includes signaling the first and second MVD coefficient blocks. For example, each block of the MVD is input to a transform process to derive a transform coefficient block for the associated MVD block.

[0138] The methods described herein can be used separately or in any order and combination. Each method may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In some embodiments, the processing circuitry executes a program stored on a non-transitory computer-readable medium.

[0139] In another aspect, some embodiments include a computing system (e.g., server system 112) including control circuitry (e.g., control circuitry 302) and memory (e.g., memory 314) coupled to the control circuitry, the memory storing one or more instruction sets configured to be executed by the control circuitry, the one or more instruction sets including instructions for performing any of the methods described herein (e.g., A1-A15 and B1-B8 above).

[0140] In yet another aspect, some embodiments include a non-transitory computer-readable storage medium storing one or more instruction sets for execution by control circuitry of a computing system, the one or more instruction sets including instructions for performing any of the methods described herein (e.g., A1-A15 and B1-B8 above).

[0141] In this specification, terms such as "first," "second," etc. may be used to describe various elements, but it is understood that these elements are not to be limited by these terms. These terms are used only to distinguish one element from another.

[0142] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the claims. Where used in the description of the embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and / or," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that, as used herein, the terms "having" and / or "including" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0143] As used herein, the term "if..." may be interpreted to mean "when" or "upon" or "in response to determining that..." or "in accordance with the determining that..." or "in response to detecting that...", depending on the context. Similarly, the phrase "if it is determined [that the stated antecedent condition is true]" or "if [the stated antecedent condition is true]" or "when [the stated antecedent condition is true]" may be interpreted to mean "upon determining" or "in response to determining" or "in accordance with the determining that" or "upon detecting" or "in response to detecting" that the stated antecedent condition is true, depending on the context.

[0144] The foregoing description has been described with reference to specific embodiments for purposes of explanation. However, the exemplary discussions above are not intended to be exhaustive or to limit the scope of the claims to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments were chosen and described to best explain the principles of operation and practical applications, thereby enabling others skilled in the art to practice them.

Claims

1. 1. A method of video decoding performed in a computing system having a memory and one or more processors, the method comprising: receiving a video bitstream including a plurality of blocks including a first block, the first block including a plurality of sub-blocks; determining, based on a syntax element value in the video bitstream, that the first block is predicted in sub-block mode; In response to the first block being predicted in sub-block mode: deriving a set of motion vector predictors (MVPs) corresponding to the plurality of sub-blocks of the first block; deriving a set of motion vector differentials (MVDs) for the plurality of sub-blocks; determining a set of motion vectors for the plurality of sub-blocks by applying the set of MVDs to the set of MVPs; and reconstructing the first block using the set of motion vectors. method.

2. The method of claim 1 , wherein the set of MVPs is derived using a motion model and one or more spatially neighboring motion vectors.

3. The method of claim 1 , wherein the set of MVPs is derived based on one or more coded motion vectors corresponding to one or more temporally co-located blocks.

4. obtaining one or more MVD coefficient blocks corresponding to the plurality of sub-blocks of the first block from the video bitstream; the set of MVDs is obtained by performing an inverse transform on the one or more MVD coefficient blocks. The method of claim 1.

5. The method of claim 4 , wherein the one or more MVD coefficient blocks include a first MVD coefficient block corresponding to a horizontal MVD component and a second MVD coefficient block corresponding to a vertical MVD component.

6. obtaining the horizontal MVD component from the first MVD coefficient block; and obtaining the vertical MVD component from the second MVD coefficient block; The set of MVDs is obtained by combining the horizontal and vertical MVD components. The method of claim 5.

7. The one or more MVD coefficient blocks: a first MVD coefficient block corresponding to a horizontal MVD component for the first prediction; a second MVD coefficient block corresponding to a vertical MVD component for the first prediction; a third MVD coefficient block corresponding to a horizontal MVD component for the second prediction; and a fourth MVD coefficient block corresponding to a vertical MVD component for the second prediction; The method of claim 4.

8. The method of claim 4 , wherein one or more of the plurality of sub-blocks that do not have an available MVP are assigned a zero MVD.

9. 5. The method of claim 4, wherein one or more sub-blocks of the plurality of sub-blocks are designated as unavailable pursuant to a determination that the one or more sub-blocks do not have an available MVP.

10. The method of claim 9 , wherein a shape-adaptive transform is applied to the one or more MVD coefficient blocks to obtain the set of MVDs.

11. The method of claim 4 , wherein quantized MVD coefficients are obtained from the one or more MVD coefficient blocks, and the set of MVDs is derived from the quantized MVD coefficients.

12. The method of claim 11 , wherein a quantization step size is obtained from a high-level syntax in the video bitstream.

13. The method of claim 1 , wherein the precision for the set of MVDs is obtained from a high-level syntax in the video bitstream.

14. The method of claim 1 , wherein the precision for the set of MVDs is obtained from a block-level syntax in the video bitstream.

15. Control circuitry; memory; and 1. A computing system having one or more instruction sets stored in the memory, the one or more instruction sets comprising:

15. A method according to claim 1, comprising instructions for carrying out the method according to any one of claims 1 to 14. Computing systems.

16. A computer program product for causing a computer to carry out the method according to any one of claims 1 to 14.

Images