WO2021058498A1 - Extended motion information comparison - Google Patents
Extended motion information comparison Download PDFInfo
- Publication number
- WO2021058498A1 WO2021058498A1 PCT/EP2020/076460 EP2020076460W WO2021058498A1 WO 2021058498 A1 WO2021058498 A1 WO 2021058498A1 EP 2020076460 W EP2020076460 W EP 2020076460W WO 2021058498 A1 WO2021058498 A1 WO 2021058498A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- motion
- motion information
- list
- candidates
- information
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/103—Selection of coding mode or of prediction mode
- H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/103—Selection of coding mode or of prediction mode
- H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/513—Processing of motion vectors
- H04N19/517—Processing of motion vectors by encoding
- H04N19/52—Processing of motion vectors by encoding by predictive encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/117—Filters, e.g. for pre-processing or post-processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/124—Quantisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
- H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
- H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/513—Processing of motion vectors
- H04N19/517—Processing of motion vectors by encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/523—Motion estimation or motion compensation with sub-pixel accuracy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
- H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
- H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
- H04N19/96—Tree coding, e.g. quad-tree coding
Definitions
- the present embodiments generally relate to motion information comparison in video encoding and decoding.
- image and video coding schemes usually employ prediction and transform to leverage spatial and temporal redundancy in the video content.
- intra or inter prediction is used to exploit the intra or inter picture correlation, then the differences between the original block and the predicted block, often denoted as prediction errors or prediction residuals, are transformed, quantized, and entropy coded.
- the compressed data are decoded by inverse processes corresponding to the entropy coding, quantization, transform, and prediction.
- a method of video encoding or decoding comprising: accessing a list of motion candidates for a block; accessing motion information of a neighboring block of said block; comparing said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block being different from said motion information of said motion candidate in said list of motion candidates, adding said neighboring block as a candidate to said list of motion candidates; and encoding or decoding motion information of said block based on said list of motion candidates.
- an apparatus for video encoding or decoding comprising one or more processors, wherein said one or more processors are configured to: access a list of motion candidates for a block; access motion information of a neighboring block of said block; compare said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block being different from said motion information of said motion candidate in said list of motion candidates, add said neighboring block as a candidate to said list of motion candidates; and encode or decode motion information of said block based on said list of motion candidates.
- One or more embodiments also provide a computer program comprising instructions which when executed by one or more processors cause the one or more processors to perform the encoding method or decoding method according to any of the embodiments described above.
- One or more of the present embodiments also provide a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to the methods described above.
- One or more embodiments also provide a computer readable storage medium having stored thereon a bitstream generated according to the methods described above.
- One or more embodiments also provide a method and apparatus for transmitting or receiving the bitstream generated according to the methods described above.
- FIG. 1 illustrates a block diagram of a system within which aspects of the present embodiments may be implemented.
- FIG. 2 illustrates a block diagram of an embodiment of a video encoder.
- FIG. 3 illustrates a block diagram of an embodiment of a video decoder.
- FIG. 4 illustrates interpolation filters with different smoothing characteristics.
- FIG. 5 illustrates the derivation of the interpolation filter based on the value of IFindex
- FIG. 6 illustrates positions for spatial and temporal predictors.
- FIG. 7 illustrates the generation process of a merge list.
- FIG. 1 illustrates a block diagram of an example of a system in which various aspects and embodiments can be implemented.
- System 100 may be embodied as a device including the various components described below and is configured to perform one or more of the aspects described in this application. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia settop boxes, digital television receivers, personal video recording systems, connected home appliances, and servers.
- Elements of system 100 singly or in combination, may be embodied in a single integrated circuit, multiple ICs, and/or discrete components.
- the processing and encoder/decoder elements of system 100 are distributed across multiple ICs and/or discrete components.
- system 100 is communicatively coupled to other systems, or to other electronic devices, via, for example, a communications bus or through dedicated input and/or output ports.
- system 100 is configured to implement one or more of the aspects described in this application.
- the system 100 includes at least one processor 110 configured to execute instructions loaded therein for implementing, for example, the various aspects described in this application.
- Processor 110 may include embedded memory, input output interface, and various other circuitries as known in the art.
- the system 100 includes at least one memory 120 (e.g., a volatile memory device, and/or a non-volatile memory device).
- System 100 includes a storage device 140, which may include non-volatile memory and/or volatile memory, including, but not limited to, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drive, and/or optical disk drive.
- the storage device 140 may include an internal storage device, an attached storage device, and/or a network accessible storage device, as non-limiting examples.
- System 100 includes an encoder/decoder module 130 configured, for example, to process data to provide an encoded video or decoded video, and the encoder/decoder module 130 may include its own processor and memory.
- the encoder/decoder module 130 represents module(s) that may be included in a device to perform the encoding and/or decoding functions. As is known, a device may include one or both of the encoding and decoding modules. Additionally, encoder/decoder module 130 may be implemented as a separate element of system 100 or may be incorporated within processor 110 as a combination of hardware and software as known to those skilled in the art.
- Program code to be loaded onto processor 110 or encoder/decoder 130 to perform the various aspects described in this application may be stored in storage device 140 and subsequently loaded onto memory 120 for execution by processor 110.
- one or more of processor 110, memory 120, storage device 140, and encoder/decoder module 130 may store one or more of various items during the performance of the processes described in this application. Such stored items may include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.
- memory inside of the processor 110 and/or the encoder/decoder module 130 is used to store instructions and to provide working memory for processing that is needed during encoding or decoding.
- a memory external to the processing device (for example, the processing device may be either the processor 110 or the encoder/decoder module 130) is used for one or more of these functions.
- the external memory may be the memory 120 and/or the storage device 140, for example, a dynamic volatile memory and/or a non-volatile flash memory.
- an external non-volatile flash memory is used to store the operating system of a television.
- a fast external dynamic volatile memory such as a RAM is used as working memory for video coding and decoding operations, such as for MPEG-2, HEVC, or VVC.
- the input to the elements of system 100 may be provided through various input devices as indicated in block 105.
- Such input devices include, but are not limited to, (i) an RF portion that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a Composite input terminal, (iii) a USB input terminal, and/or (iv) an HDMI input terminal.
- the input devices of block 105 have associated respective input processing elements as known in the art.
- the RF portion may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a band of frequencies), (ii) down converting the selected signal, (iii) band- limiting again to a narrower band of frequencies to select (for example) a signal frequency band which may be referred to as a channel in certain embodiments, (iv) demodulating the down converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select the desired stream of data packets.
- the RF portion of various embodiments includes one or more elements to perform these functions, for example, frequency selectors, signal selectors, band- limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers.
- the RF portion may include a tuner that performs various of these functions, including, for example, down converting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to baseband.
- the RF portion and its associated input processing element receives an RF signal transmitted over a wired (for example, cable) medium, and performs frequency selection by filtering, down converting, and filtering again to a desired frequency band.
- Adding elements may include inserting elements in between existing elements, for example, inserting amplifiers and an analog- to-digital converter.
- the RF portion includes an antenna.
- the USB and/or HDMI terminals may include respective interface processors for connecting system 100 to other electronic devices across USB and/or HDMI connections.
- various aspects of input processing for example, Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or within processor 110 as necessary.
- aspects of USB or HDMI interface processing may be implemented within separate interface ICs or within processor 110 as necessary.
- the demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 110, and encoder/decoder 130 operating in combination with the memory and storage elements to process the datastream as necessary for presentation on an output device.
- connection arrangement 115 for example, an internal bus as known in the art, including the I2C bus, wiring, and printed circuit boards.
- the system 100 includes communication interface 150 that enables communication with other devices via communication channel 190.
- the communication interface 150 may include, but is not limited to, a transceiver configured to transmit and to receive data over communication channel 190.
- the communication interface 150 may include, but is not limited to, a modem or network card and the communication channel 190 may be implemented, for example, within a wired and/or a wireless medium.
- Data is streamed to the system 100, in various embodiments, using a Wi-Fi network such as IEEE 802.11.
- the Wi-Fi signal of these embodiments is received over the communications channel 190 and the communications interface 150 which are adapted for Wi-Fi communications.
- the communications channel 190 of these embodiments is typically connected to an access point or router that provides access to outside networks including the Internet for allowing streaming applications and other over-the-top communications.
- Other embodiments provide streamed data to the system 100 using a set-top box that delivers the data over the HDMI connection of the input block 105.
- Still other embodiments provide streamed data to the system 100 using the RF connection of the input block 105.
- the system 100 may provide an output signal to various output devices, including a display 165, speakers 175, and other peripheral devices 185.
- the other peripheral devices 185 include, in various examples of embodiments, one or more of a stand-alone DVR, a disk player, a stereo system, a lighting system, and other devices that provide a function based on the output of the system 100.
- control signals are communicated between the system 100 and the display 165, speakers 175, or other peripheral devices 185 using signaling such as AV.Link, CEC, or other communications protocols that enable device-to-device control with or without user intervention.
- the output devices may be communicatively coupled to system 100 via dedicated connections through respective interfaces 160, 170, and 180.
- the output devices may be connected to system 100 using the communications channel 190 via the communications interface 150.
- the display 165 and speakers 175 may be integrated in a single unit with the other components of system 100 in an electronic device, for example, a television.
- the display interface 160 includes a display driver, for example, a timing controller (T Con) chip.
- the display 165 and speaker 175 may alternatively be separate from one or more of the other components, for example, if the RF portion of input 105 is part of a separate set-top box.
- the output signal may be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.
- FIG. 2 illustrates an example video encoder 200, such as a High Efficiency Video Coding (HEVC) encoder.
- FIG. 2 may also illustrate an encoder in which improvements are made to the HEVC standard or an encoder employing technologies similar to HEVC, such as a VVC (Versatile Video Coding) encoder under development by JVET (Joint Video Exploration Team).
- HEVC High Efficiency Video Coding
- the terms “reconstructed” and “decoded” may be used interchangeably, the terms “encoded” or “coded” may be used interchangeably, and the terms “image,” “picture” and “frame” may be used interchangeably.
- the term “reconstructed” is used at the encoder side while “decoded” is used at the decoder side.
- the video sequence may go through pre-encoding processing (201), for example, applying a color transform to the input color picture (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of the input picture components in order to get a signal distribution more resilient to compression (for instance using a histogram equalization of one of the color components).
- Metadata can be associated with the pre-processing, and attached to the bitstream.
- a picture is partitioned (202), for example, into one or more slices where each slice can include one or more slice segments.
- a slice segment is organized into coding units, prediction units, and transform units.
- the HEVC specification distinguishes between “blocks” and “units,” where a “block” addresses a specific area in a sample array (e.g., luma, Y), and the “unit” includes the collocated blocks of all encoded color components (Y, Cb, Cr, or monochrome), syntax elements, and prediction data that are associated with the blocks (e.g., motion vectors).
- a picture is partitioned into coding tree blocks (CTB) of square shape with a configurable size (typically at 64x64, 128x128, or 256x256 pixels), and a consecutive set of coding tree blocks is grouped into a slice.
- a Coding Tree Unit (CTU) contains the CTBs of the encoded color components.
- a CTB is the root of a quadtree partitioning into Coding Blocks (CB), and a Coding Block may be partitioned into one or more Prediction Blocks (PB) and forms the root of a quadtree partitioning into Transform Blocks (TBs).
- CB Coding Tree Unit
- PB Prediction Blocks
- TBs Transform Blocks
- a Transform Block (TB) larger than 4x4 is divided into 4x4 sub-blocks of quantized coefficients called Coefficient Groups (CG).
- a Coding Unit (CU) includes the Prediction Units (PUs) and the tree-structured set of Transform Units (TUs), a PU includes the prediction information for all color components, and a TU includes residual coding syntax structure for each color component.
- the size of a CB, PB, and TB of the luma component applies to the corresponding CU, PU, and TU.
- block can be used to refer, for example, to any of CTU, CU, PU, TU, CG, CB, PB, and TB.
- block can also be used to refer to a macroblock and a partition as specified in H.264/AVC or other video coding standards, and more generally to refer to an array of data of various sizes.
- a picture is encoded by the encoder elements as described below.
- the picture to be encoded is processed in units of, for example, CUs.
- Each coding unit is encoded using either an intra or inter mode.
- intra prediction 260
- inter mode motion estimation (275) and compensation (270) are performed.
- merge lists regular merge, MMVD (Merge with MVD), triangle, CUP (Combined Intra/Inter Prediction), IBC (Intra Block Copy)
- MMVD Merge with MVD
- CUP Combined Intra/Inter Prediction
- IBC Intelligent Block Copy
- the encoder decides (205) which one of the intra mode or inter mode to use for encoding the coding unit, and indicates the intra/inter decision by a prediction mode flag.
- Prediction residuals are calculated by subtracting (210) the predicted block from the original image block.
- the prediction residuals are then transformed (225) and quantized (230).
- the quantized transform coefficients, as well as motion vectors and other syntax elements, are entropy coded (245) to output a bitstream.
- CAB AC context-based adaptive binary arithmetic coding
- the encoder may also skip the transform and apply quantization directly to the non- transformed residual signal, for example, on a 4x4 TU basis.
- the encoder may also bypass both transform and quantization, i.e., the residual is coded directly without the application of the transform or quantization process.
- direct PCM coding no prediction is applied and the coding unit samples are directly coded into the bitstream.
- the encoder decodes an encoded block to provide a reference for further predictions.
- the quantized transform coefficients are de-quantized (240) and inverse transformed (250) to decode prediction residuals.
- In-loop filters (265) are applied to the reconstructed picture, for example, to perform deblocking/SAO (Sample Adaptive Offset) filtering to reduce encoding artifacts.
- the filtered image is stored at a reference picture buffer (280).
- FIG. 3 illustrates a block diagram of an example video decoder 300, such as an HEVC decoder.
- a bitstream is decoded by the decoder elements as described below.
- Video decoder 300 generally performs a decoding pass reciprocal to the encoding pass as described in FIG. 2, which performs video decoding as part of encoding video data.
- FIG. 3 may also illustrate a decoder in which improvements are made to the HEVC standard or a decoder employing technologies similar to HEVC, such as a VVC decoder.
- the input of the decoder includes a video bitstream, which may be generated by video encoder 200.
- the bitstream is entropy decoded (330) to obtain transform coefficients, motion vectors, picture partitioning information, and other coded information.
- CABAC CABAC is used for entropy coding
- the context models are initialized in the same manner as the encoder context models, and syntax elements are decoded from the bitstream based on the context models.
- the construction of the merge lists (regular merge, MMVD, triangle CUP, IBC) is performed (325) by inheritance from neighboring CUs (spatial), collocated CUs (temporal), from HMVP list, or constructed (pairwise and zeros).
- the picture partitioning information indicates how the picture is partitioned, for example, the size of the CTUs, and a manner a CTU is split into CUs, and possibly into PUs when applicable.
- the decoder may therefore divide (335) the picture, for example, into CTUs, and each CTU into CUs, according to the decoded picture partitioning information.
- the transform coefficients are de-quantized (340) and inverse transformed (350) to decode the prediction residuals.
- an image block is reconstructed.
- the predicted block may be obtained (370) from intra prediction (360) or motion- compensated prediction (i.e., inter prediction) (375).
- In-loop filters (365) are applied to the reconstructed image.
- the filtered image is stored at a reference picture buffer (380).
- the decoded picture can further go through post-decoding processing (385), for example, an inverse color transform (e.g., conversion from YCbCr 4:2:0 to RGB 4:4:4) or an inverse remapping performing the inverse of the remapping process performed in the pre-encoding processing (201).
- post-decoding processing may use metadata derived in the pre-encoding processing and signaled in the bitstream.
- the principle of switchable interpolation filter is to improve the motion compensation prediction by selecting the IF to use for each block prediction.
- the IFs may differ with smoothing characteristics typically as shown in FIG. 4, which illustrates an example of interpolation filters proposed in JVET-00057 (see A. Henkel et al., “CE4: Switchable interpolation filter,” document JVET-00057, 15th Meeting: Gothenburg, SE, 3-12 July 2019).
- IFindex can be selected per coding unit (CU) and can be derived from the coded “imv” index indicating the resolution of the coded motion vector difference (MVD).
- MVD coded motion vector difference
- the IF index is not coded explicitly but derived from merge candidate(s).
- IFindex value can be one among two filters (IF-0 or IF- 1), but IF-1 can be used for HALF-PEL motion vector values only. Then if IFindex is not equal to zero and the MV horizontal (or vertical) component is not HALF-PEL, then IF-0 is used as illustrated in FIG 5, which illustrates that the value of “IFindex” and “MV” allow deriving the motion compensation filter.
- N 2 IF filters (IF-0 and IF-1) for simplification.
- the present principles can be applied to the case N > 2 (IF-0, ... IF-(N-1)).
- IFindex 0 and IFindex 1 0 that correspond to IF-0 and IF-1 in the following.
- filter IF-0 IF-default
- filter IF-0 IF-default
- the present principles can also be applied when the interpolation filter is applied to motion vectors that are not HALF- PEL.
- the weights (wo, wi) are not necessarily equal and are signaled in the bitstream (or inherited in merge mode) as an index in a lookup table (GBildx).
- GBI generalized bi-prediction
- the weights (wo, wi) are not necessarily equal and are signaled in the bitstream (or inherited in merge mode) as an index in a lookup table (GBildx).
- merge modes such as regular merge, MMVD, triangle, CUP, IBC
- some pruning is performed to limit the redundancy in the constructed list. This pruning is performed by comparing sets of motion information to differentiate sets that have different motions.
- VVC draft 6 a set of motion information, stored spatially at a 4x4 level for inheritance purpose, is composed of:
- Table 1 motion information with associated size.
- the GBi index is only stored at the CU level and not in the motion information at the 4x4 level.
- the GBildx stored in this motion information is, in VTM-6.0 (VVC Test Model 6.0), only used by the HMVP list (updates and loads), the other modes use the GBildx stored at the CU level.
- HMVP uses a FIFO list of previously used predictions, for which it needs all the motion information (as well as the GBildx). Note that GBildx is CU level information as Motion
- MI MI Information
- MI is saved on a 4x4 basis (i.e., a 16x16 CU holds one GBildx and 16 MI)
- GBildx in MI is only used by HMVP that saves MI and not CU info.
- a CU is inter coded
- its motion information is added into the HMVP list.
- a merge list is constructed, some candidates are chosen into the HMVP list (from end to beginning, i.e., from older to the most recent one).
- MI is decorrelated from the corresponding CU, so MI needs to contain GBildx.
- MI are always linked to the corresponding CU that hold the GBildx (so no need in MI).
- motion information comparison is performed in two different ways, one when the motion information is fully available and a second one when only partial motion information is accessible.
- Extract of VVC draft 6 text 8.5.2.3 Derivation process for spatial merging candidates.
- availableFlagBi is set equal to 0
- both components of mvLXBi are set equal to 0
- refldxLXBi is set equal to -1
- predFlagLXBi is set equal to 0
- bcwIdxBi is set equal to 0:
- - availableBi is equal to FALSE.
- - availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi and
- availableFlagBi is set equal to 1 and the following ...
- the present embodiments propose to extend the comparisons of motion information, for example, to check if the same prediction will be generated (instead of just motion vectors and reference frames). For that purpose, some parameters may be added to motion information comparison. It may make it more robust and potentially simpler for implementations especially hardware implementation.
- IFindex and “GBildx” can modify the resulting prediction of a motion information even if the motion vectors and references frames are identical. Therefore, such parameters can be added into the comparisons.
- Table 2 and Table 3 become Table 4 and Table 5, respectively.
- Table 4 all parameters compared during comparison of full motion information.
- Extract of VVC draft text 8.5.2.3 Derivation process for spatial merging candidates.
- availableFlagBi is set equal to 0
- both components of mvLXBi are set equal to 0
- refldxLXBi is set equal to -1
- predFlagLXBi is set equal to 0
- bcwIdxBi is set equal to 0:
- - availableBi is equal to FALSE.
- - availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi ) and
- availableFlagBi is set equal to 1 and the following ...
- the GBildx in the motion information at the 4x4 level, instead of at the CU level, for all inter coding modes (not only for HMVP list) in order to improve the performance of such a comparison.
- the GBildx is stored at the CU level in VVC draft 6, and it is not stored at the MI (4x4) level. But by storing it at the MI level, it becomes part of the information that can be retrieved by the spatial prediction in merge mode (as it retrieves MI).
- this embodiment can be extended to any new parameter that has to be added into the motion information because it modifies the resulting prediction coming from this motion information and it has to be inherited by following CUs.
- Table 2 and Table 3 then become Table 6 and Table 7, respectively.
- Table 6 parameters compared using full motion information with added IFindex.
- Table 7 parameters compared using partial motion information with added IFindex.
- availableFlagBi is set equal to 0
- both components of mvLXBi are set equal to 0
- refldxLXBi is set equal to -1
- predFlagLXBi is set equal to 0
- bcwIdxBi is set equal to 0:
- - availableBi is equal to FALSE.
- - availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi ) and
- availableFlagBi is set equal to 1 and the following
- the IFindex is also compared. MI from top candidate B1 is compared to the left one Al. If MI of A1 is the same as MI of Bl, then B1 is set unavailable for merge list construction.
- a single full comparison can be used to compare full motion information even if the HMVP list update is slightly impacted.
- the merge list (a list of motion candidates) is constructed by including the following types of predictors (also referred to as candidates): 1) Spatial MVPs (Motion Vector Predictors) from spatial neighbour CUs;
- step 725 motion information for B 1 (MIBI) is compared with motion information for A1 (MIAI), and candidate at position Bi is added to the merge list only if different from candidate at position Ai.
- Position B2 is considered (755, 760, 765) when there are less than four spatial candidates in the list (750).
- Temporal candidate derivation (“TMVP C0/C1”)
- temporal candidate Only one temporal candidate is added (770) to the merge list. Particularly, in the derivation of this temporal merge candidate, a scaled motion vector is derived based on co-located CU belonging to the collocated reference picture. The position for the temporal candidate is selected between candidates Co and Ci, as depicted in FIG. 6. If CU at position Co is not available, is intra coded, or is outside of the current row of CTUs, position Ci is used. Otherwise, position Co is used in the derivation of the temporal merge candidate.
- HMVP history-based MVP
- TMVP TMVP
- the history-based MVP (HMVP) merge candidates are added (780) to the merge list after the spatial MVP and TMVP.
- HMVP the motion information of a previously coded block stored in a table is used as MVP for the current CU.
- the table with multiple HMVP candidates is maintained during the encoding/decoding process.
- the table is reset (emptied) when a new CTU row is encountered.
- the associated motion information is added to the last entry of the table as a new HMVP candidate and if redundant motion information is present, it is removed, otherwise the first entry of the table is removed (the oldest one).
- HMVP candidates could be used in the merge candidate list construction process.
- the latest several HMVP candidates in the table are checked in order and inserted to the candidate list after the TMVP candidate. Redundancy check is applied on the HMVP candidates to some spatial merge candidate.
- Each of the two last HMVP candidates in the FIFO (the more recent ones) is compared to spatial candidates Ai and Bi and added to the merge list only if it has not the same motion information. Once the total number of available merge candidates reaches the maximally allowed merge candidates minus 1, the merge candidate list construction process from HMVP is terminated.
- Pairwise average candidate is generated by averaging the first pair of candidates in the existing merge candidate list.
- the merge list is not full after pair-wise average merge candidate is added (790)
- the zero MVPs are inserted (795) in the end until the maximum merge candidate number is reached.
- Different motion comparison methods as described above can be used during the redundancy check (e.g., 725, 735, 745, 760).
- the motion comparison methods can also be applied when different types of motion candidates are used to construct the merge list, or when the motion candidates are added to the merge list in another order.
- each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and/or use of specific steps and/or actions may be modified or combined. Additionally, terms such as “first”, “second”, etc. may be used in various embodiments to modify an element, component, step, operation, etc., for example, a “first decoding” and a “second decoding”. Use of such terms does not imply an ordering to the modified operations unless specifically required. So, in this example, the first decoding need not be performed before the second decoding, and may occur, for example, before, during, or in an overlapping time period with the second decoding.
- modules to derive coding parameters for example, the modules to derive coding parameters (203, 325), the motion compensation module (270, 375), of a video encoder 200 and decoder 300 as shown in FIG. 2 and FIG. 3.
- present aspects are not limited to VVC or HEVC, and can be applied, for example, to other standards and recommendations, and extensions of any such standards and recommendations. Unless indicated otherwise, or technically precluded, the aspects described in this application can be used individually or in combination.
- Various numeric values are used in the present application. The specific values are for example purposes and the aspects described are not limited to these specific values.
- An embodiment provides a computer program comprising instructions which when executed by one or more processors cause the one or more processors to perform the encoding method or decoding method according to any of the embodiments described above.
- One or more of the present embodiments also provide a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to the methods described above.
- One or more embodiments also provide a computer readable storage medium having stored thereon a bitstream generated according to the methods described above.
- One or more embodiments also provide a method and apparatus for transmitting or receiving the bitstream generated according to the methods described above.
- Decoding may encompass all or part of the processes performed, for example, on a received encoded sequence in order to produce a final output suitable for display.
- processes include one or more of the processes typically performed by a decoder, for example, entropy decoding, inverse quantization, inverse transformation, and differential decoding.
- a decoder for example, entropy decoding, inverse quantization, inverse transformation, and differential decoding.
- encoding may encompass all or part of the processes performed, for example, on an input video sequence in order to produce an encoded bitstream.
- the implementations and aspects described herein may be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed may also be implemented in other forms (for example, an apparatus or program).
- An apparatus may be implemented in, for example, appropriate hardware, software, and firmware.
- the methods may be implemented in, for example, an apparatus, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, for example, computers, cell phones, portable/personal digital assistants (“PDAs”), and other devices that facilitate communication of information between end-users.
- PDAs portable/personal digital assistants
- references to “one embodiment” or “an embodiment” or “one implementation” or “an implementation”, as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment.
- the appearances of the phrase “in one embodiment” or “in an embodiment” or “in one implementation” or “in an implementation”, as well any other variations, appearing in various places throughout this application are not necessarily all referring to the same embodiment.
- this application may refer to “determining” various pieces of information. Determining the information may include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.
- Accessing the information may include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, moving the information, copying the information, calculating the information, determining the information, predicting the information, or estimating the information.
- this application may refer to “receiving” various pieces of information. Receiving is, as with “accessing”, intended to be a broad term. Receiving the information may include one or more of, for example, accessing the information, or retrieving the information (for example, from memory). Further, “receiving” is typically involved, in one way or another, during operations, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.
- such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C).
- This may be extended, as is clear to one of ordinary skill in this and related arts, for as many items as are listed.
- implementations may produce a variety of signals formatted to carry information that may be, for example, stored or transmitted.
- the information may include, for example, instructions for performing a method, or data produced by one of the described implementations.
- a signal may be formatted to carry the bitstream of a described embodiment.
- Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal.
- the formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream.
- the information that the signal carries may be, for example, analog or digital information.
- the signal may be transmitted over a variety of different wired or wireless links, as is known.
- the signal may be stored on a processor-readable medium.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
In some coding modes, such as the merge mode, a list of motion candidates is generated using spatial or temporal neighboring blocks or constructed ones, and one of the motion candidates is inherited by the current block. When constructing the list of motion candidates, motion information of a candidate to be added is checked to limit the redundancy in the constructed list. In one implementation, the switchable interpolation filter, the IFindex becomes part of the motion information to be used in comparison since it can modify the resulting prediction. Furthermore, the GBiIdx indicating the weights used in bi-prediction can also be part of the motion information to be compared and could also be taken into account in the redundancy check. In general, all or part of motion information that causes different prediction can be used in redundancy check.
Description
EXTENDED MOTION INFORMATION COMPARISON
TECHNICAL FIELD
[1] The present embodiments generally relate to motion information comparison in video encoding and decoding.
BACKGROUND
[2] To achieve high compression efficiency, image and video coding schemes usually employ prediction and transform to leverage spatial and temporal redundancy in the video content. Generally, intra or inter prediction is used to exploit the intra or inter picture correlation, then the differences between the original block and the predicted block, often denoted as prediction errors or prediction residuals, are transformed, quantized, and entropy coded. To reconstruct the video, the compressed data are decoded by inverse processes corresponding to the entropy coding, quantization, transform, and prediction.
SUMMARY [3] According to an embodiment, a method of video encoding or decoding is provided, comprising: accessing a list of motion candidates for a block; accessing motion information of a neighboring block of said block; comparing said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block being different from said motion information of said motion candidate in said list of motion candidates, adding said neighboring block as a candidate to said list of motion candidates; and encoding or decoding motion information of said block based on said list of motion candidates.
[4] According to another embodiment, an apparatus for video encoding or decoding is provided, comprising one or more processors, wherein said one or more processors are configured to: access a list of motion candidates for a block; access motion information of a neighboring block of said block; compare said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block
being different from said motion information of said motion candidate in said list of motion candidates, add said neighboring block as a candidate to said list of motion candidates; and encode or decode motion information of said block based on said list of motion candidates.
[5] One or more embodiments also provide a computer program comprising instructions which when executed by one or more processors cause the one or more processors to perform the encoding method or decoding method according to any of the embodiments described above. One or more of the present embodiments also provide a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to the methods described above. One or more embodiments also provide a computer readable storage medium having stored thereon a bitstream generated according to the methods described above. One or more embodiments also provide a method and apparatus for transmitting or receiving the bitstream generated according to the methods described above.
BRIEF DESCRIPTION OF THE DRAWINGS
[6] FIG. 1 illustrates a block diagram of a system within which aspects of the present embodiments may be implemented.
[7] FIG. 2 illustrates a block diagram of an embodiment of a video encoder.
[8] FIG. 3 illustrates a block diagram of an embodiment of a video decoder.
[9] FIG. 4 illustrates interpolation filters with different smoothing characteristics.
[10] FIG. 5 illustrates the derivation of the interpolation filter based on the value of IFindex and
MV.
[11] FIG. 6 illustrates positions for spatial and temporal predictors.
[12] FIG. 7 illustrates the generation process of a merge list.
DETAILED DESCRIPTION
[13] FIG. 1 illustrates a block diagram of an example of a system in which various aspects and embodiments can be implemented. System 100 may be embodied as a device including the various components described below and is configured to perform one or more of the aspects described in this application. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital
multimedia settop boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. Elements of system 100, singly or in combination, may be embodied in a single integrated circuit, multiple ICs, and/or discrete components. For example, in at least one embodiment, the processing and encoder/decoder elements of system 100 are distributed across multiple ICs and/or discrete components. In various embodiments, the system 100 is communicatively coupled to other systems, or to other electronic devices, via, for example, a communications bus or through dedicated input and/or output ports. In various embodiments, the system 100 is configured to implement one or more of the aspects described in this application.
[14] The system 100 includes at least one processor 110 configured to execute instructions loaded therein for implementing, for example, the various aspects described in this application. Processor 110 may include embedded memory, input output interface, and various other circuitries as known in the art. The system 100 includes at least one memory 120 (e.g., a volatile memory device, and/or a non-volatile memory device). System 100 includes a storage device 140, which may include non-volatile memory and/or volatile memory, including, but not limited to, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drive, and/or optical disk drive. The storage device 140 may include an internal storage device, an attached storage device, and/or a network accessible storage device, as non-limiting examples.
[15] System 100 includes an encoder/decoder module 130 configured, for example, to process data to provide an encoded video or decoded video, and the encoder/decoder module 130 may include its own processor and memory. The encoder/decoder module 130 represents module(s) that may be included in a device to perform the encoding and/or decoding functions. As is known, a device may include one or both of the encoding and decoding modules. Additionally, encoder/decoder module 130 may be implemented as a separate element of system 100 or may be incorporated within processor 110 as a combination of hardware and software as known to those skilled in the art.
[16] Program code to be loaded onto processor 110 or encoder/decoder 130 to perform the various aspects described in this application may be stored in storage device 140 and subsequently loaded onto memory 120 for execution by processor 110. In accordance with various embodiments, one or more of processor 110, memory 120, storage device 140, and encoder/decoder module 130 may store one or more of various items during the performance of the processes described in this
application. Such stored items may include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.
[17] In several embodiments, memory inside of the processor 110 and/or the encoder/decoder module 130 is used to store instructions and to provide working memory for processing that is needed during encoding or decoding. In other embodiments, however, a memory external to the processing device (for example, the processing device may be either the processor 110 or the encoder/decoder module 130) is used for one or more of these functions. The external memory may be the memory 120 and/or the storage device 140, for example, a dynamic volatile memory and/or a non-volatile flash memory. In several embodiments, an external non-volatile flash memory is used to store the operating system of a television. In at least one embodiment, a fast external dynamic volatile memory such as a RAM is used as working memory for video coding and decoding operations, such as for MPEG-2, HEVC, or VVC.
[18] The input to the elements of system 100 may be provided through various input devices as indicated in block 105. Such input devices include, but are not limited to, (i) an RF portion that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a Composite input terminal, (iii) a USB input terminal, and/or (iv) an HDMI input terminal.
[19] In various embodiments, the input devices of block 105 have associated respective input processing elements as known in the art. For example, the RF portion may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a band of frequencies), (ii) down converting the selected signal, (iii) band- limiting again to a narrower band of frequencies to select (for example) a signal frequency band which may be referred to as a channel in certain embodiments, (iv) demodulating the down converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select the desired stream of data packets. The RF portion of various embodiments includes one or more elements to perform these functions, for example, frequency selectors, signal selectors, band- limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF portion may include a tuner that performs various of these functions, including, for example, down converting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to baseband. In one set-top box
embodiment, the RF portion and its associated input processing element receives an RF signal transmitted over a wired (for example, cable) medium, and performs frequency selection by filtering, down converting, and filtering again to a desired frequency band. Various embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and/or add other elements performing similar or different functions. Adding elements may include inserting elements in between existing elements, for example, inserting amplifiers and an analog- to-digital converter. In various embodiments, the RF portion includes an antenna.
[20] Additionally, the USB and/or HDMI terminals may include respective interface processors for connecting system 100 to other electronic devices across USB and/or HDMI connections. It is to be understood that various aspects of input processing, for example, Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or within processor 110 as necessary. Similarly, aspects of USB or HDMI interface processing may be implemented within separate interface ICs or within processor 110 as necessary. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 110, and encoder/decoder 130 operating in combination with the memory and storage elements to process the datastream as necessary for presentation on an output device.
[21] Various elements of system 100 may be provided within an integrated housing, Within the integrated housing, the various elements may be interconnected and transmit data therebetween using suitable connection arrangement 115, for example, an internal bus as known in the art, including the I2C bus, wiring, and printed circuit boards.
[22] The system 100 includes communication interface 150 that enables communication with other devices via communication channel 190. The communication interface 150 may include, but is not limited to, a transceiver configured to transmit and to receive data over communication channel 190. The communication interface 150 may include, but is not limited to, a modem or network card and the communication channel 190 may be implemented, for example, within a wired and/or a wireless medium.
[23] Data is streamed to the system 100, in various embodiments, using a Wi-Fi network such as IEEE 802.11. The Wi-Fi signal of these embodiments is received over the communications channel 190 and the communications interface 150 which are adapted for Wi-Fi communications. The communications channel 190 of these embodiments is typically connected to an access point
or router that provides access to outside networks including the Internet for allowing streaming applications and other over-the-top communications. Other embodiments provide streamed data to the system 100 using a set-top box that delivers the data over the HDMI connection of the input block 105. Still other embodiments provide streamed data to the system 100 using the RF connection of the input block 105.
[24] The system 100 may provide an output signal to various output devices, including a display 165, speakers 175, and other peripheral devices 185. The other peripheral devices 185 include, in various examples of embodiments, one or more of a stand-alone DVR, a disk player, a stereo system, a lighting system, and other devices that provide a function based on the output of the system 100. In various embodiments, control signals are communicated between the system 100 and the display 165, speakers 175, or other peripheral devices 185 using signaling such as AV.Link, CEC, or other communications protocols that enable device-to-device control with or without user intervention. The output devices may be communicatively coupled to system 100 via dedicated connections through respective interfaces 160, 170, and 180. Alternatively, the output devices may be connected to system 100 using the communications channel 190 via the communications interface 150. The display 165 and speakers 175 may be integrated in a single unit with the other components of system 100 in an electronic device, for example, a television. In various embodiments, the display interface 160 includes a display driver, for example, a timing controller (T Con) chip.
[25] The display 165 and speaker 175 may alternatively be separate from one or more of the other components, for example, if the RF portion of input 105 is part of a separate set-top box. In various embodiments in which the display 165 and speakers 175 are external components, the output signal may be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.
[26] FIG. 2 illustrates an example video encoder 200, such as a High Efficiency Video Coding (HEVC) encoder. FIG. 2 may also illustrate an encoder in which improvements are made to the HEVC standard or an encoder employing technologies similar to HEVC, such as a VVC (Versatile Video Coding) encoder under development by JVET (Joint Video Exploration Team).
[27] In the present application, the terms “reconstructed” and “decoded” may be used interchangeably, the terms “encoded” or “coded” may be used interchangeably, and the terms
“image,” “picture” and “frame” may be used interchangeably. Usually, but not necessarily, the term “reconstructed” is used at the encoder side while “decoded” is used at the decoder side.
[28] Before being encoded, the video sequence may go through pre-encoding processing (201), for example, applying a color transform to the input color picture (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of the input picture components in order to get a signal distribution more resilient to compression (for instance using a histogram equalization of one of the color components). Metadata can be associated with the pre-processing, and attached to the bitstream.
[29] To encode a video sequence with one or more pictures, a picture is partitioned (202), for example, into one or more slices where each slice can include one or more slice segments. In HEVC, a slice segment is organized into coding units, prediction units, and transform units. The HEVC specification distinguishes between “blocks” and “units,” where a “block” addresses a specific area in a sample array (e.g., luma, Y), and the “unit” includes the collocated blocks of all encoded color components (Y, Cb, Cr, or monochrome), syntax elements, and prediction data that are associated with the blocks (e.g., motion vectors).
[30] For coding according to HEVC, a picture is partitioned into coding tree blocks (CTB) of square shape with a configurable size (typically at 64x64, 128x128, or 256x256 pixels), and a consecutive set of coding tree blocks is grouped into a slice. A Coding Tree Unit (CTU) contains the CTBs of the encoded color components. A CTB is the root of a quadtree partitioning into Coding Blocks (CB), and a Coding Block may be partitioned into one or more Prediction Blocks (PB) and forms the root of a quadtree partitioning into Transform Blocks (TBs). A Transform Block (TB) larger than 4x4 is divided into 4x4 sub-blocks of quantized coefficients called Coefficient Groups (CG). Corresponding to the Coding Block, Prediction Block, and Transform Block, a Coding Unit (CU) includes the Prediction Units (PUs) and the tree-structured set of Transform Units (TUs), a PU includes the prediction information for all color components, and a TU includes residual coding syntax structure for each color component. The size of a CB, PB, and TB of the luma component applies to the corresponding CU, PU, and TU. In the present application, the term “block” can be used to refer, for example, to any of CTU, CU, PU, TU, CG, CB, PB, and TB. In addition, the term “block” can also be used to refer to a macroblock and a partition as specified in H.264/AVC or other video coding standards, and more generally to refer
to an array of data of various sizes.
[31] In the encoder 200, a picture is encoded by the encoder elements as described below. The picture to be encoded is processed in units of, for example, CUs. Each coding unit is encoded using either an intra or inter mode. When a coding unit is encoded in an intra mode, it performs intra prediction (260). In an inter mode, motion estimation (275) and compensation (270) are performed. The construction of the merge lists (regular merge, MMVD (Merge with MVD), triangle, CUP (Combined Intra/Inter Prediction), IBC (Intra Block Copy)) is performed (203) by inheritance from neighboring CUs (spatial), collocated CUs (temporal), from HMVP (History- based Motion Vector Prediction) list, or constructed (pairwise and zeros). The encoder decides (205) which one of the intra mode or inter mode to use for encoding the coding unit, and indicates the intra/inter decision by a prediction mode flag. Prediction residuals are calculated by subtracting (210) the predicted block from the original image block.
[32] The prediction residuals are then transformed (225) and quantized (230). The quantized transform coefficients, as well as motion vectors and other syntax elements, are entropy coded (245) to output a bitstream. As a non-limiting example, context-based adaptive binary arithmetic coding (CAB AC) can be used to encode syntax elements into the bitstream.
[33] The encoder may also skip the transform and apply quantization directly to the non- transformed residual signal, for example, on a 4x4 TU basis. The encoder may also bypass both transform and quantization, i.e., the residual is coded directly without the application of the transform or quantization process. In direct PCM coding, no prediction is applied and the coding unit samples are directly coded into the bitstream.
[34] The encoder decodes an encoded block to provide a reference for further predictions. The quantized transform coefficients are de-quantized (240) and inverse transformed (250) to decode prediction residuals. Combining (255) the decoded prediction residuals and the predicted block, an image block is reconstructed. In-loop filters (265) are applied to the reconstructed picture, for example, to perform deblocking/SAO (Sample Adaptive Offset) filtering to reduce encoding artifacts. The filtered image is stored at a reference picture buffer (280).
[35] FIG. 3 illustrates a block diagram of an example video decoder 300, such as an HEVC decoder. In the decoder 300, a bitstream is decoded by the decoder elements as described below.
Video decoder 300 generally performs a decoding pass reciprocal to the encoding pass as described in FIG. 2, which performs video decoding as part of encoding video data. FIG. 3 may also illustrate a decoder in which improvements are made to the HEVC standard or a decoder employing technologies similar to HEVC, such as a VVC decoder. [36] In particular, the input of the decoder includes a video bitstream, which may be generated by video encoder 200. The bitstream is entropy decoded (330) to obtain transform coefficients, motion vectors, picture partitioning information, and other coded information. If CABAC is used for entropy coding, the context models are initialized in the same manner as the encoder context models, and syntax elements are decoded from the bitstream based on the context models. The construction of the merge lists (regular merge, MMVD, triangle CUP, IBC) is performed (325) by inheritance from neighboring CUs (spatial), collocated CUs (temporal), from HMVP list, or constructed (pairwise and zeros).
[37] The picture partitioning information indicates how the picture is partitioned, for example, the size of the CTUs, and a manner a CTU is split into CUs, and possibly into PUs when applicable. The decoder may therefore divide (335) the picture, for example, into CTUs, and each CTU into CUs, according to the decoded picture partitioning information. The transform coefficients are de-quantized (340) and inverse transformed (350) to decode the prediction residuals.
[38] Combining (355) the decoded prediction residuals and the predicted block, an image block is reconstructed. The predicted block may be obtained (370) from intra prediction (360) or motion- compensated prediction (i.e., inter prediction) (375). In-loop filters (365) are applied to the reconstructed image. The filtered image is stored at a reference picture buffer (380).
[39] The decoded picture can further go through post-decoding processing (385), for example, an inverse color transform (e.g., conversion from YCbCr 4:2:0 to RGB 4:4:4) or an inverse remapping performing the inverse of the remapping process performed in the pre-encoding processing (201). The post-decoding processing may use metadata derived in the pre-encoding processing and signaled in the bitstream.
[40] Switchable interpolation filters (IF)
[41] The principle of switchable interpolation filter (IF) is to improve the motion compensation prediction by selecting the IF to use for each block prediction. The IFs may differ with smoothing
characteristics typically as shown in FIG. 4, which illustrates an example of interpolation filters proposed in JVET-00057 (see A. Henkel et al., “CE4: Switchable interpolation filter,” document JVET-00057, 15th Meeting: Gothenburg, SE, 3-12 July 2019).
[42] For example, in VVC draft 6 (see “Text of Versatile Video Coding (Draft 6),” document JVET-02001, 15th Meeting: Gothenburg, SE, 3-12 July 2019) and JVET-00057, the IF index
(IFindex) can be selected per coding unit (CU) and can be derived from the coded “imv” index indicating the resolution of the coded motion vector difference (MVD). In particular, if the MVD resolution is HALF-PEL, then IFindex = 1 is selected; otherwise IFindex = 0 is selected. In case the coding unit is in Merge mode, the IF index is not coded explicitly but derived from merge candidate(s).
[43] In VVC draft 6 and JVET-00057, IFindex value can be one among two filters (IF-0 or IF- 1), but IF-1 can be used for HALF-PEL motion vector values only. Then if IFindex is not equal to zero and the MV horizontal (or vertical) component is not HALF-PEL, then IF-0 is used as illustrated in FIG 5, which illustrates that the value of “IFindex” and “MV” allow deriving the motion compensation filter.
[44] In the following, we will consider N = 2 IF filters (IF-0 and IF-1) for simplification. But the present principles can be applied to the case N > 2 (IF-0, ... IF-(N-1)). In this case, one distinguishes the case IFindex = 0 and IFindex ¹ 0 that correspond to IF-0 and IF-1 in the following. Also, filter IF-0 (IF-default) is considered as the “default filter”. Note that the present principles can also be applied when the interpolation filter is applied to motion vectors that are not HALF- PEL.
[45] Bi-prediction with CU-level weighting (a.k.a. GBI or BPWA or BCWI
[46] In traditional bi-prediction, the prediction sample (biPred[x]) is built by averaging two motion compensated uni-directional prediction samples (refi[ x + mvi ], i = 0, 1) with equal weights (wo = 1, wi = 1): biPred[x] = (wo.refo[ x + mvo ] + wi.refi[ x + mvi] + 1) / 2
[47] In case of generalized bi-prediction (a.k.a. GBI, BPWA or BCW), the weights (wo, wi) are not necessarily equal and are signaled in the bitstream (or inherited in merge mode) as an index in a lookup table (GBildx).
[48] In several coding modes (for example, merge modes such as regular merge, MMVD, triangle, CUP, IBC) that inherit candidates from neighboring ones (spatial, temporal or constructed), some pruning is performed to limit the redundancy in the constructed list. This pruning is performed by comparing sets of motion information to differentiate sets that have different motions.
[49] However, with the newly adopted switchable interpolation filter, the “IFindex” becomes part of the motion information (since it can modify the resulting prediction), but it is not considered by the current pruning. Furthermore, the GBildx can also be part of the motion information and could also be taken into account in the pruning. [50] Motion information
[51] In VVC draft 6, a set of motion information, stored spatially at a 4x4 level for inheritance purpose, is composed of:
Table 1: motion information with associated size.
[52] In all coding modes except HMVP update and load, the GBi index is only stored at the CU level and not in the motion information at the 4x4 level. The GBildx stored in this motion information is, in VTM-6.0 (VVC Test Model 6.0), only used by the HMVP list (updates and loads), the other modes use the GBildx stored at the CU level.
[53] HMVP uses a FIFO list of previously used predictions, for which it needs all the motion information (as well as the GBildx). Note that GBildx is CU level information as Motion
Information (MI) but MI is saved on a 4x4 basis (i.e., a 16x16 CU holds one GBildx and 16 MI), and GBildx in MI is only used by HMVP that saves MI and not CU info. Each time a CU is inter coded, its motion information is added into the HMVP list. Each time a merge list is constructed, some candidates are chosen into the HMVP list (from end to beginning, i.e., from older to the most
recent one). In the HMVP list, MI is decorrelated from the corresponding CU, so MI needs to contain GBildx. In all other inter coding modes, MI are always linked to the corresponding CU that hold the GBildx (so no need in MI).
[54] Motion information comparison [55] In VVC, motion information comparison is performed in two different ways, one when the motion information is fully available and a second one when only partial motion information is accessible.
[56] The comparison that has access to the full motion information of the spatial neighbors (stored in the memory at the 4x4 level) is currently used in: (i) all the merge modes (regular merge, MMVD, triangle, IBC, CUP), (ii) the HMVP list update and (iii) the motion compensation of sub block CUs.
[57] The goal of this comparison is to check if Mis have the same motion vectors and associated reference frames as described in the VVC draft text, which requires that Mis are inter ones (islnter) from the same slice (sliceldx) in the same mode (isIBC). Below is an extract of this draft where the derivation of the spatial candidates for the regular merge list is described. It focuses on the top neighbor (Bl) after the left one (Al) has been derived:
Extract of VVC draft 6 text: 8.5.2.3 Derivation process for spatial merging candidates.
(the comparison of full motion information is underlined)
- The variables availableFlagBi, refldxLXBi, predFlagLXBi and mvLXBi are derived as follows:
- If one or more of the following conditions are true, availableFlagBi is set equal to 0, both components of mvLXBi are set equal to 0, refldxLXBi is set equal to -1 and predFlagLXBi is set equal to 0, with X being 0 or 1, and bcwIdxBi is set equal to 0:
- availableBi is equal to FALSE. - availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi and
- Otherwise, availableFlagBi is set equal to 1 and the following ...
[58] This comparison of full motion information is illustrated in Table 2. Table 2: parameters compared during comparison of full motion information in VVC draft 6.
[59] The comparison of partial motion information, which is only used when adding a HMVP candidate into a regular merge list, compares only part of the motion information as shown in Table 3. Table 3: parameters compared during comparison of partial motion information in VVC draft 6.
[60] The present embodiments propose to extend the comparisons of motion information, for example, to check if the same prediction will be generated (instead of just motion vectors and reference frames). For that purpose, some parameters may be added to motion information comparison. It may make it more robust and potentially simpler for implementations especially hardware implementation.
[61] First embodiment
[62] In this embodiment, it is proposed to compare all the available parameters such that only a simple memory comparison is required, i.e., a single comparison of the complete structure instead of numerous structure accesses and comparisons.
[63] “IFindex” and “GBildx” can modify the resulting prediction of a motion information even if the motion vectors and references frames are identical. Therefore, such parameters can be added into the comparisons.
[64] In that case, Table 2 and Table 3 become Table 4 and Table 5, respectively.
Table 4: all parameters compared during comparison of full motion information.
Table 5: all parameters compared during comparison of partial motion information.
[65] Accordingly, the draft text becomes:
Extract of VVC draft text: 8.5.2.3 Derivation process for spatial merging candidates.
The variables availableFlagBi, refldxLXBi, predFlagLXBi and mvLXBi are derived as follows:
- If one or more of the following conditions are true, availableFlagBi is set equal to 0, both components of mvLXBi are set equal to 0, refldxLXBi is set equal to -1 and predFlagLXBi is set equal to 0, with X being 0 or 1, and bcwIdxBi is set equal to 0:
- availableBi is equal to FALSE.
- availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi ) and
( xNbBi. vNbBi ) have the same motion vectors.-and- the same reference indices, the same half sample interpolation filter indices and the same bi-prediction weight indices.
- Otherwise, availableFlagBi is set equal to 1 and the following ...
[66] According to the modified VVC draft as described above, all motion information is compared instead of comparing only motion vectors and reference frames, which need to be from Inter MI (islnter) of the same slice (sliceldx) in the same mode (isIBC). MI from top candidate B1 are compared to the left one Al. If MI from A1 is equal to MI from Bl, then B1 is set unavailable for merge list construction, namely, Bl is considered as redundant with respect to Al
and is pruned from the merge list.
[67] In a variant, it is possible to store the GBildx in the motion information at the 4x4 level, instead of at the CU level, for all inter coding modes (not only for HMVP list) in order to improve the performance of such a comparison. As explained above, the GBildx is stored at the CU level in VVC draft 6, and it is not stored at the MI (4x4) level. But by storing it at the MI level, it becomes part of the information that can be retrieved by the spatial prediction in merge mode (as it retrieves MI).
[68] In another variant, this embodiment can be extended to any new parameter that has to be added into the motion information because it modifies the resulting prediction coming from this motion information and it has to be inherited by following CUs.
[69] Second embodiment
[70] In this embodiment, it is proposed to add only IFindex into the comparisons as the GBildx is not used everywhere.
[71] Table 2 and Table 3 then become Table 6 and Table 7, respectively. Table 6: parameters compared using full motion information with added IFindex.
[72] Accordingly, the draft text become:
Extract of VVC draft text: 8.5.2.3 Derivation process for spatial merging candidates.
The variables availableFlagBi, refldxLXBi, predFlagLXBi and mvLXBi are derived as follows:
- If one or more of the following conditions are true, availableFlagBi is set equal to 0, both components of mvLXBi are set equal to 0, refldxLXBi is set equal to -1 and predFlagLXBi is set equal to 0, with X being 0 or 1, and bcwIdxBi is set equal to 0:
- availableBi is equal to FALSE.
- availableAi is equal to TRUE and the luma locations ( xNbAi. vNbAi ) and
( xNbBi. vNbBi ) have the same motion vectors.-and the same reference indices and the same half sample interpolation filter indices.
- Otherwise, availableFlagBi is set equal to 1 and the following
[73] According to the above modified text, instead of comparing only motion vectors and reference frames, which need to be from Inter MI (islnter) of the same slice (sliceldx) in the same mode (isIBC), the IFindex is also compared. MI from top candidate B1 is compared to the left one Al. If MI of A1 is the same as MI of Bl, then B1 is set unavailable for merge list construction.
[74] As GBildx of motion information is only used by the HMVP list (updates and loads), these indices are all set to the default value in all other cases (inter coding modes) which do not influence the result of full comparisons. A full comparison will only affect the HMVP list but with a very limited impact.
[75] In a variant, a single full comparison can be used to compare full motion information even if the HMVP list update is slightly impacted.
[76] In another variant, it possible to store and load GBildx from the HMVP list in another way than through motion information so that GBildx can be completely removed from motion information and therefore full comparisons can be used.
[77] Third embodiment
[78] In this embodiment, it is proposed to consider all the combinations of parameter comparisons in each process, as illustrated in Table 8. It is possible that only full motion information comparison method is used when motion information comparison is used, such as when the HMVP list is generated.
Table 8: added parameter comparisons in each comparison.
[79] In VTM-6.0, the merge list (a list of motion candidates) is constructed by including the following types of predictors (also referred to as candidates): 1) Spatial MVPs (Motion Vector Predictors) from spatial neighbour CUs;
2) Temporal MVP from collocated CUs;
3) History-based MVPs from a FIFO table;
4) Pairwise average MVP; and
5) Zero MVPs. [80] For each CU coded in the merge mode, the index of the selected predictor is encoded. The generation process of each category of merge candidates is shown in FIG. 7 and described below.
[81] Spatial candidates derivation
[82] The derivation of spatial merge candidates in VVC draft 6 is same as in HEVC. A maximum of four merge candidates are selected among candidates located in the positions depicted in FIG. 6. The order of derivation is Ai, Bi, Bo, Ao and B2. After candidate at position Ai is added (710, 715), the addition of the remaining candidates (720, 727, 730, 737, 740, 747, 755, 765) is subject to a redundancy check (725, 735, 745, 760), which ensures that candidates with same motion information are excluded from the list so that coding efficiency is improved. To reduce computational complexity, not all possible candidate pairs are considered in the mentioned
redundancy check. Instead only some pairs are considered (725, 735, 745, 760), and a candidate is only added to the list if the corresponding candidate used for redundancy check has not the same motion information. For example, in step 725, motion information for B 1 (MIBI) is compared with motion information for A1 (MIAI), and candidate at position Bi is added to the merge list only if different from candidate at position Ai. Position B2 is considered (755, 760, 765) when there are less than four spatial candidates in the list (750).
[83] Temporal candidate derivation (“TMVP C0/C1”)
[84] Only one temporal candidate is added (770) to the merge list. Particularly, in the derivation of this temporal merge candidate, a scaled motion vector is derived based on co-located CU belonging to the collocated reference picture. The position for the temporal candidate is selected between candidates Co and Ci, as depicted in FIG. 6. If CU at position Co is not available, is intra coded, or is outside of the current row of CTUs, position Ci is used. Otherwise, position Co is used in the derivation of the temporal merge candidate.
[85] History-based merge candidates derivation [86] The history-based MVP (HMVP) merge candidates are added (780) to the merge list after the spatial MVP and TMVP. To use HMVP, the motion information of a previously coded block stored in a table is used as MVP for the current CU. The table with multiple HMVP candidates is maintained during the encoding/decoding process. The table is reset (emptied) when a new CTU row is encountered. Whenever there is a non-subblock inter-coded CU, the associated motion information is added to the last entry of the table as a new HMVP candidate and if redundant motion information is present, it is removed, otherwise the first entry of the table is removed (the oldest one).
[87] HMVP candidates could be used in the merge candidate list construction process. The latest several HMVP candidates in the table are checked in order and inserted to the candidate list after the TMVP candidate. Redundancy check is applied on the HMVP candidates to some spatial merge candidate. Each of the two last HMVP candidates in the FIFO (the more recent ones) is compared to spatial candidates Ai and Bi and added to the merge list only if it has not the same motion information. Once the total number of available merge candidates reaches the maximally allowed merge candidates minus 1, the merge candidate list construction process from HMVP is
terminated.
[88] Pair-wise average merge candidate derivation
[89] Pairwise average candidate is generated by averaging the first pair of candidates in the existing merge candidate list. When the merge list is not full after pair-wise average merge candidate is added (790), the zero MVPs are inserted (795) in the end until the maximum merge candidate number is reached.
[90] Different motion comparison methods as described above can be used during the redundancy check (e.g., 725, 735, 745, 760). The motion comparison methods can also be applied when different types of motion candidates are used to construct the merge list, or when the motion candidates are added to the merge list in another order.
[91] At the decoder side, the same process for constructing the merge list is used. Depending on the index of the selected predictor decoded from the bitstream, a motion vector predictor from the merge list is selected as the motion vector predictor for the current CU.
[92] Various methods are described herein, and each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and/or use of specific steps and/or actions may be modified or combined. Additionally, terms such as “first”, “second”, etc. may be used in various embodiments to modify an element, component, step, operation, etc., for example, a “first decoding” and a “second decoding”. Use of such terms does not imply an ordering to the modified operations unless specifically required. So, in this example, the first decoding need not be performed before the second decoding, and may occur, for example, before, during, or in an overlapping time period with the second decoding.
[93] Various methods and other aspects described in this application can be used to modify modules, for example, the modules to derive coding parameters (203, 325), the motion compensation module (270, 375), of a video encoder 200 and decoder 300 as shown in FIG. 2 and FIG. 3. Moreover, the present aspects are not limited to VVC or HEVC, and can be applied, for example, to other standards and recommendations, and extensions of any such standards and recommendations. Unless indicated otherwise, or technically precluded, the aspects described in this application can be used individually or in combination.
[94] Various numeric values are used in the present application. The specific values are for example purposes and the aspects described are not limited to these specific values.
[95] An embodiment provides a computer program comprising instructions which when executed by one or more processors cause the one or more processors to perform the encoding method or decoding method according to any of the embodiments described above. One or more of the present embodiments also provide a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to the methods described above. One or more embodiments also provide a computer readable storage medium having stored thereon a bitstream generated according to the methods described above. One or more embodiments also provide a method and apparatus for transmitting or receiving the bitstream generated according to the methods described above.
[96] Various implementations involve decoding. “Decoding,” as used in this application, may encompass all or part of the processes performed, for example, on a received encoded sequence in order to produce a final output suitable for display. In various embodiments, such processes include one or more of the processes typically performed by a decoder, for example, entropy decoding, inverse quantization, inverse transformation, and differential decoding. Whether the phrase “decoding process” is intended to refer specifically to a subset of operations or generally to the broader decoding process will be clear based on the context of the specific descriptions and is believed to be well understood by those skilled in the art.
[97] Various implementations involve encoding. In an analogous way to the above discussion about “decoding”, “encoding” as used in this application may encompass all or part of the processes performed, for example, on an input video sequence in order to produce an encoded bitstream.
[98] Note that the syntax elements as used herein are descriptive terms. As such, they do not preclude the use of other syntax element names.
[99] The implementations and aspects described herein may be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed may also be implemented in other forms (for
example, an apparatus or program). An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The methods may be implemented in, for example, an apparatus, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, for example, computers, cell phones, portable/personal digital assistants (“PDAs”), and other devices that facilitate communication of information between end-users.
[100] Reference to “one embodiment” or “an embodiment” or “one implementation” or “an implementation”, as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” or “in an embodiment” or “in one implementation” or “in an implementation”, as well any other variations, appearing in various places throughout this application are not necessarily all referring to the same embodiment.
[101] Additionally, this application may refer to “determining” various pieces of information. Determining the information may include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.
[102] Further, this application may refer to “accessing” various pieces of information. Accessing the information may include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, moving the information, copying the information, calculating the information, determining the information, predicting the information, or estimating the information.
[103] Additionally, this application may refer to “receiving” various pieces of information. Receiving is, as with “accessing”, intended to be a broad term. Receiving the information may include one or more of, for example, accessing the information, or retrieving the information (for example, from memory). Further, “receiving” is typically involved, in one way or another, during operations, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.
[104] It is to be appreciated that the use of any of the following “and/or”, and “at least one of’, for example, in the cases of “A/B”, “A and/or B” and “at least one of A and B”, is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of “A, B, and/or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C). This may be extended, as is clear to one of ordinary skill in this and related arts, for as many items as are listed.
[105] As will be evident to one of ordinary skill in the art, implementations may produce a variety of signals formatted to carry information that may be, for example, stored or transmitted. The information may include, for example, instructions for performing a method, or data produced by one of the described implementations. For example, a signal may be formatted to carry the bitstream of a described embodiment. Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal. The formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information that the signal carries may be, for example, analog or digital information. The signal may be transmitted over a variety of different wired or wireless links, as is known. The signal may be stored on a processor-readable medium.
Claims
1. A method of video encoding or decoding, comprising: accessing a list of motion candidates for a block; accessing motion information of a neighboring block of said block; comparing said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block being different from said motion information of said motion candidate in said list of motion candidates, adding said neighboring block as a candidate to said list of motion candidates; and encoding or decoding motion information of said block based on said list of motion candidates.
2. The method of claim 1, wherein a signal indicating weights used in bi-prediction is considered in said comparison.
3. The method of claim 1 or 2, wherein all available motion information for said neighboring block is considered during said comparison.
4. The method of any one of claims 1-3, wherein a single comparison of a complete structure is used when comparing motion information.
5. The method of any one of claims 1-4, wherein said neighboring block is considered redundant with said motion candidate when predictions corresponding to said motion information of said neighboring block and said motion information of said motion candidate are identical.
6. The method of any one of claims 1-5, wherein said list of motion candidates is used in a merge mode for signaling the motion information for said block.
7. The method of any one of claim 6, wherein said motion information for said block is signaled through an index into said list of motion candidates.
8. The method of any one of claims 1-7, wherein said list of motion candidates is used by all merge modes.
9. An apparatus for video encoding or decoding, comprising one or more processors, wherein said one or more processors are configured to: access a list of motion candidates for a block; access motion information of a neighboring block of said block; compare said motion information of said neighboring block with motion information of a motion candidate in said list of motion candidates, wherein said comparison considers interpolation filter information; responsive to said motion information of said neighboring block being different from said motion information of said motion candidate in said list of motion candidates, add said neighboring block as a candidate to said list of motion candidates; and encode or decode motion information of said block based on said list of motion candidates.
10. The apparatus of claim 9, wherein a signal indicating weights used in bi-prediction is considered in said comparison.
11. The apparatus of claim 9 or 10, wherein all available motion information for said neighboring block is considered during said comparison.
12. The apparatus of any one of claims 9-11, wherein a single comparison of a complete structure is used when comparing motion information.
13. The apparatus of any one of claims 9-12, wherein said neighboring block is considered redundant with said motion candidate when predictions corresponding to said motion information of said neighboring block and said motion information of said motion candidate are identical.
14. The apparatus of any one of claims 9-13, wherein said list of motion candidates is used in a merge mode for signaling the motion information for said block.
15. The apparatus of any one of claim 14, wherein said motion information for said block is signaled through an index into said list of motion candidates.
16. The apparatus of any one of claims 9-15, wherein said list of motion candidates is used by all merge modes.
17. A signal comprising a bitstream, formed by performing the method of any one of claims
1 8
18. A computer readable storage medium having stored thereon instructions for encoding or decoding a video according to the method of any one of claims 1-8.
19. A computer program comprising instructions which when executed by one or more processors cause the one or more processors to perform the encoding method or decoding method according to any one of claims 1-8.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020227004575A KR20220065756A (en) | 2019-09-26 | 2020-09-23 | Comparison of extended motion information |
EP20780141.6A EP4035381A1 (en) | 2019-09-26 | 2020-09-23 | Extended motion information comparison |
CN202080053001.6A CN114503562A (en) | 2019-09-26 | 2020-09-23 | Extended motion information comparison |
US17/619,445 US20220103811A1 (en) | 2019-09-26 | 2020-09-23 | Extended motion information comparison |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP19306201.5 | 2019-09-26 | ||
EP19306201 | 2019-09-26 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021058498A1 true WO2021058498A1 (en) | 2021-04-01 |
Family
ID=72644218
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2020/076460 WO2021058498A1 (en) | 2019-09-26 | 2020-09-23 | Extended motion information comparison |
Country Status (5)
Country | Link |
---|---|
US (1) | US20220103811A1 (en) |
EP (1) | EP4035381A1 (en) |
KR (1) | KR20220065756A (en) |
CN (1) | CN114503562A (en) |
WO (1) | WO2021058498A1 (en) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3456049B1 (en) * | 2016-05-13 | 2022-05-04 | VID SCALE, Inc. | Systems and methods for generalized multi-hypothesis prediction for video coding |
WO2020130617A1 (en) * | 2018-12-18 | 2020-06-25 | 엘지전자 주식회사 | Method and apparatus for processing video data |
WO2020200235A1 (en) * | 2019-04-01 | 2020-10-08 | Beijing Bytedance Network Technology Co., Ltd. | Half-pel interpolation filter in intra block copy coding mode |
-
2020
- 2020-09-23 WO PCT/EP2020/076460 patent/WO2021058498A1/en unknown
- 2020-09-23 KR KR1020227004575A patent/KR20220065756A/en unknown
- 2020-09-23 CN CN202080053001.6A patent/CN114503562A/en active Pending
- 2020-09-23 US US17/619,445 patent/US20220103811A1/en active Pending
- 2020-09-23 EP EP20780141.6A patent/EP4035381A1/en active Pending
Non-Patent Citations (9)
Title |
---|
"Text of Versatile Video Coding (Draft 6", JVET-02001, 15TH MEETING: GOTHENBURG, SE, 3 July 2019 (2019-07-03) |
A. HENKEL ET AL.: "CE4: Switchable interpolation filter", JVET-00057, 15TH MEETING: GOTHENBURG, SE, 3 July 2019 (2019-07-03) |
BROSS B ET AL: "Versatile Video Coding (Draft 6)", no. m49908, 15 July 2019 (2019-07-15), XP030208561, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/127_Gothenburg/wg11/m49908-JVET-O2001-v7-JVET-O2001-v7.zip JVET-O2001-v7.docx> [retrieved on 20190715] * |
CHEN J ET AL: "Algorithm description for Versatile Video Coding and Test Model 6 (VTM 6)", no. m49914, 15 August 2019 (2019-08-15), XP030208572, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/127_Gothenburg/wg11/m49914-JVET-O2002-v1-JVET-O2002-v1.zip JVET-O2002-v1.docx> [retrieved on 20190815] * |
MCCANN K ET AL: "HEVC Test Model 3 (HM 3) Encoder Description", 5. JCT-VC MEETING; 96. MPEG MEETING; 16-3-2011 - 23-3-2011; GENEVA; (JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JCTVC-SITE/,, no. JCTVC-E602, 29 March 2011 (2011-03-29), XP030009013 * |
ROBERT (INTERDIGITAL) A ET AL: "Non-CE4: On motion information comparison", no. JVET-P0621, 26 September 2019 (2019-09-26), XP030217880, Retrieved from the Internet <URL:http://phenix.int-evry.fr/jvet/doc_end_user/documents/16_Geneva/wg11/JVET-P0621-v1.zip JVET-P0621-nonCE4-MotionInformationComparison-v1.docx> [retrieved on 20190926] * |
SOLOVYEV (HUAWEI) T ET AL: "Non-CE4: On switchable interpolation filter and bi-prediction weight indices cleanup", no. JVET-P0856, 4 October 2019 (2019-10-04), XP030218213, Retrieved from the Internet <URL:http://phenix.int-evry.fr/jvet/doc_end_user/documents/16_Geneva/wg11/JVET-P0856-v1.zip JVET-P0856.docx> [retrieved on 20191004] * |
WANG (PKU) S H ET AL: "CE4-related: On inheritance of half-pel interpolation filter in merge mode", no. m50224, 24 September 2019 (2019-09-24), XP030206216, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/128_Geneva/wg11/m50224-JVET-P0260-v1-JVET-P0260.zip JVET-P0260.docx> [retrieved on 20190924] * |
ZHANG L ET AL: "3D-CE5.h related: Improved merge mode for inter-view predicted motion", 101. MPEG MEETING; 16-7-2012 - 20-7-2012; STOCKHOLM; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. m26051, 10 July 2012 (2012-07-10), XP030054386 * |
Also Published As
Publication number | Publication date |
---|---|
US20220103811A1 (en) | 2022-03-31 |
CN114503562A (en) | 2022-05-13 |
KR20220065756A (en) | 2022-05-20 |
EP4035381A1 (en) | 2022-08-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11729417B2 (en) | Generalized bi-prediction and weighted prediction | |
US20220345744A1 (en) | Secondary transform for video encoding and decoding | |
WO2020185496A1 (en) | Method and apparatus for video encoding and decoding with subblock based local illumination compensation | |
WO2020060843A1 (en) | Generalized bi-prediction index coding | |
WO2020112620A2 (en) | Motion vector predictor candidates ordering in merge list | |
US20210400276A1 (en) | Quantization for video encoding and decoding | |
WO2019236335A1 (en) | Syntax elements for video encoding or decoding | |
WO2020254459A1 (en) | Motion vector processing for video encoding and decoding | |
EP3687172A1 (en) | Multiple transforms selection signalling | |
US20220377318A1 (en) | Spatial predictor scan order | |
JP7506063B2 (en) | Parameter grouping among multiple coding units for video encoding and decoding | |
US20220103811A1 (en) | Extended motion information comparison | |
WO2021122416A1 (en) | Subblock merge candidates in triangle merge mode | |
WO2020193736A1 (en) | Inter-prediction parameter derivation for video encoding and decoding | |
KR20210062070A (en) | Method and apparatus for determining chroma quantization parameters when using separate coding trees for luma and chroma | |
US20220345693A1 (en) | Coding mode information propagation for video coding | |
EP3691271A1 (en) | Generalized bi-prediction and weighted prediction | |
EP3591969A1 (en) | Syntax elements for video encoding or decoding | |
WO2024002846A1 (en) | Methods and apparatuses for encoding and decoding an image or a video using combined intra modes | |
EP3994893A1 (en) | Signaling of merge indices for triangle partitions | |
WO2020060864A1 (en) | Multiple transforms selection signalling | |
WO2020072397A1 (en) | Block size based motion vector coding in affine mode |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20780141 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2020780141 Country of ref document: EP Effective date: 20220426 |