EP3984227A1 - Restrictions d'utilisation d'outils en fonction de types d'images de référence - Google Patents

Restrictions d'utilisation d'outils en fonction de types d'images de référence

Info

Publication number
EP3984227A1
EP3984227A1 EP20848261.2A EP20848261A EP3984227A1 EP 3984227 A1 EP3984227 A1 EP 3984227A1 EP 20848261 A EP20848261 A EP 20848261A EP 3984227 A1 EP3984227 A1 EP 3984227A1
Authority
EP
European Patent Office
Prior art keywords
reference pictures
picture
current
mvd
coding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20848261.2A
Other languages
German (de)
English (en)
Other versions
EP3984227A4 (fr
Inventor
Na Zhang
Hongbin Liu
Li Zhang
Kai Zhang
Yue Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing ByteDance Network Technology Co Ltd
ByteDance Inc
Original Assignee
Beijing ByteDance Network Technology Co Ltd
ByteDance Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing ByteDance Network Technology Co Ltd, ByteDance Inc filed Critical Beijing ByteDance Network Technology Co Ltd
Publication of EP3984227A1 publication Critical patent/EP3984227A1/fr
Publication of EP3984227A4 publication Critical patent/EP3984227A4/fr
Pending legal-status Critical Current

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/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/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/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • 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/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • 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
    • 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/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • 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/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/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/537—Motion estimation other than block-based
    • H04N19/54—Motion estimation other than block-based using feature points or meshes
    • 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/557—Motion estimation characterised by stopping computation or iteration based on certain criteria, e.g. error magnitude being too large or early exit
    • 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/56—Motion estimation with initialisation of the vector search, e.g. estimating a good candidate to initiate a search
    • 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/563—Motion estimation with padding, i.e. with filling of non-object values in an arbitrarily shaped picture block or region for estimation purposes
    • 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/577—Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • 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/58—Motion compensation with long-term prediction, i.e. the reference frame for a current frame not being the temporally closest one
    • 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/583—Motion compensation with overlapping blocks
    • 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

Definitions

  • This document is related to video and image coding and decoding technologies.
  • Digital video accounts for the largest bandwidth use on the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, it is expected that the bandwidth demand for digital video usage will continue to grow.
  • the disclosed techniques may be used by video or image decoder or encoder embodiments for in which reference pictures are used in video coding or decoding.
  • a method of video processing includes determining, for a conversion between a current video block of a current picture of a video and a coded representation of the video, an applicability of a coding tool to the current video block based on types of reference pictures used for the conversion; and performing the conversion based on the determining, wherein the types of the reference pictures are at least based on 1) whether the reference pictures are short term reference pictures or long term reference pictures, 2) resolutions of the reference pictures or the current picture, or 3) picture order count (POC) distances of the reference pictures relative to the current picture.
  • POC picture order count
  • another method of video processing includes determining, for a conversion between a current video block of a video and a coded representation of the video, an applicability of a bi-directional optical flow (BDOF) coding tool or a decoder side motion vector refinement (DMVR) coding tool to the current video block based on types of reference pictures used for the conversion; and performing the conversion based on the determining, wherein, using the BDOF coding tool, one or more initial predictions are refined based on an optical flow calculation, and wherein, using the DMVR coding tool, motion information of the current video block is refined using prediction blocks of the current video block, and wherein the types of reference pictures are at least based on 1) whether the reference pictures are short term reference pictures or long term reference pictures, 2) resolutions of the reference pictures or the current picture, or 3) picture order count (POC) distances of the reference pictures relative to the current picture.
  • BDOF bi-directional optical flow
  • DMVR decoder side motion vector refinement
  • another method of video processing includes performing a conversion between a current video block of a current picture of a video and a coded representation of the current video block using a merge mode motion vector difference (MMVD) coding in which a merge candidate is selected to be used as a base merge candidate and refined with motion vector difference (MVD) information, without scaling the MVD information; and wherein the base merge candidate is a bi-directional motion vector, and wherein a MVD of one prediction direction is set as equal to a MVD included in the coded representation and another MVD of the other prediction direction is set as equal or opposite to the MVD included in the coded representation based on a coding condition of the video.
  • MMVD merge mode motion vector difference
  • another method of video processing includes performing a conversion between a current video block of a current picture of a video and a coded representation of the current video block using a merge mode motion vector difference (MMVD) coding in which a merge candidate is selected to be used as a base merge candidate and refined with motion vector difference (MVD) information, wherein the coded representation conforms to a rule that specifies that at most a first MVD value for a first prediction direction is included in the coded representation.
  • MMVD merge mode motion vector difference
  • the above-described method may be implemented by a video encoder apparatus that comprises a processor.
  • the above-described method may be implemented by a video decoder apparatus that comprises a processor.
  • these methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.
  • FIG. 1 shows an example of bilateral matching.
  • FIG. 2 shows an example of template matching.
  • FIG. 3 shows an example of unilateral motion estimation (ME) in frame rate upconversion (FRUC) .
  • FIG. 4 shows an example of optical flow trajectory.
  • FIG. 5A-5B show examples of bidirectional optical flow without block extension.
  • FIG. 6 shows an example of bilateral matching with 6-point search.
  • FIG. 7 shows examples of an adaptive integer search pattern (left) , and a half sample search pattern (right) .
  • FIG. 8 shows examples of integer positions where parametric error surface fit will be performed.
  • FIG. 9 shows an example of a merge with motion vector difference (MMVD) search point.
  • FIG. 10 shows an example of sub-block MV V SB and pixel ⁇ v (i, j) (red arrow)
  • FIG. 11 is an example illustration of symmetrical MVD mode.
  • FIG. 12 shows examples on usage of the mixed STRP and LTRP.
  • FIGS. 13A and 13B are block diagrams of examples of a hardware platform used for implementing techniques described in the present document.
  • FIG. 14 is a flowchart for an example method of video processing based on some implementations of the disclosed technology.
  • FIGS. 15A to 15C show flowcharts for example methods of video processing based on some implementations of the disclosed technology.
  • the present document provides various techniques that can be used by a decoder of image or video bitstreams to improve the quality of decompressed or decoded digital video or images.
  • video is used herein to include both a sequence of pictures (traditionally called video) and individual images.
  • a video encoder may also implement these techniques during the process of encoding in order to reconstruct decoded frames used for further encoding.
  • Section headings are used in the present document for ease of understanding and do not limit the embodiments and techniques to the corresponding sections. As such, embodiments from one section can be combined with embodiments from other sections.
  • This document is related to video coding technologies. Specifically, it is related to palette coding with employing base colors based representation in video coding. It may be applied to the existing video coding standard like HEVC, or the standard (Versatile Video Coding) to be finalized. It may be also applicable to future video coding standards or video codec.
  • Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO/IEC standards.
  • the ITU-T produced H. 261 and H. 263, ISO/IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced the H. 262/MPEG-2 Video and H. 264/MPEG-4 Advanced Video Coding (AVC) and H. 265/HEVC standards.
  • AVC H. 264/MPEG-4 Advanced Video Coding
  • H. 265/HEVC High Efficiency Video Coding
  • the video coding standards are based on the hybrid video coding structure wherein temporal prediction plus transform coding are utilized.
  • Joint Video Exploration Team JVET was founded by VCEG and MPEG jointly in 2015.
  • JVET Joint Exploration Model
  • VVC draft i.e., Versatile Video Coding (Draft 4)
  • Draft 4 Versatile Video Coding
  • VTM The latest reference software of VVC, named VTM, could be found at:
  • Pattern matched motion vector derivation (PMMVD) mode is a special merge mode based on Frame-Rate Up Conversion (FRUC) techniques. With this mode, motion information of a block is not signalled but derived at decoder side.
  • PMMVD Pattern matched motion vector derivation
  • FRUC Frame-Rate Up Conversion
  • a FRUC flag is signalled for a CU when its merge flag is true.
  • FRUC flag is false, a merge index is signalled and the regular merge mode is used.
  • FRUC flag is true, an additional FRUC mode flag is signalled to indicate which method (bilateral matching or template matching) is to be used to derive motion information for the block.
  • the decision on whether using FRUC merge mode for a CU is based on RD cost selection as done for normal merge candidate. That is the two matching modes (bilateral matching and template matching) are both checked for a CU by using RD cost selection. The one leading to the minimal cost is further compared to other CU modes. If a FRUC matching mode is the most efficient one, FRUC flag is set to true for the CU and the related matching mode is used.
  • Motion derivation process in FRUC merge mode has two steps.
  • a CU-level motion search is first performed, then followed by a Sub-CU level motion refinement.
  • an initial motion vector is derived for the whole CU based on bilateral matching or template matching.
  • a list of MV candidates is generated and the candidate which leads to the minimum matching cost is selected as the starting point for further CU level refinement.
  • a local search based on bilateral matching or template matching around the starting point is performed and the MV results in the minimum matching cost is taken as the MV for the whole CU.
  • the motion information is further refined at sub-CU level with the derived CU motion vectors as the starting points.
  • the following derivation process is performed for a W ⁇ H CU motion information derivation.
  • MV for the whole W ⁇ H CU is derived.
  • the CU is further split into M ⁇ M sub-CUs.
  • the value of M is calculated as in (16)
  • D is a predefined splitting depth which is set to 3 by default in the JEM. Then the MV for each sub-CU is derived.
  • the bilateral matching is used to derive motion information of the current CU by finding the closest match between two blocks along the motion trajectory of the current CU in two different reference pictures.
  • the motion vectors MV0 and MV1 pointing to the two reference blocks shall be proportional to the temporal distances, i.e., TD0 and TD1, between the current picture and the two reference pictures.
  • the bilateral matching becomes mirror based bi-directional MV.
  • template matching is used to derive motion information of the current CU by finding the closest match between a template (top and/or left neighbouring blocks of the current CU) in the current picture and a block (same size to the template) in a reference picture. Except the aforementioned FRUC merge mode, the template matching is also applied to AMVP mode.
  • AMVP has two candidates.
  • template matching method a new candidate is derived. If the newly derived candidate by template matching is different to the first existing AMVP candidate, it is inserted at the very beginning of the AMVP candidate list and then the list size is set to two (meaning remove the second existing AMVP candidate) .
  • AMVP mode only CU level search is applied.
  • the MV candidate set at CU level consists of:
  • each valid MV of a merge candidate is used as an input to generate a MV pair with the assumption of bilateral matching.
  • one valid MV of a merge candidate is (MVa, refa) at reference list A.
  • the reference picture refb of its paired bilateral MV is found in the other reference list B so that refa and refb are temporally at different sides of the current picture. If such a refb is not available in reference list B, refb is determined as a reference which is different from refa and its temporal distance to the current picture is the minimal one in list B.
  • MVb is derived by scaling MVa based on the temporal distance between the current picture and refa, refb.
  • MVs from the interpolated MV field are also added to the CU level candidate list. More specifically, the interpolated MVs at the position (0, 0) , (W/2, 0) , (0, H/2) and (W/2, H/2) of the current CU are added.
  • the original AMVP candidates are also added to CU level MV candidate set.
  • the MV candidate set at sub-CU level consists of:
  • the scaled MVs from reference pictures are derived as follows. All the reference pictures in both lists are traversed. The MVs at a collocated position of the sub-CU in a reference picture are scaled to the reference of the starting CU-level MV.
  • ATMVP and STMVP candidates are limited to the four first ones.
  • interpolated motion field is generated for the whole picture based on unilateral ME. Then the motion field may be used later as CU level or sub-CU level MV candidates.
  • the motion field of each reference pictures in both reference lists is traversed at 4 ⁇ 4 block level.
  • the motion of the reference block is scaled to the current picture according to the temporal distance TD0 and TD1 (the same way as that of MV scaling of TMVP in HEVC) and the scaled motion is assigned to the block in the current frame. If no scaled MV is assigned to a 4 ⁇ 4 block, the block’s motion is marked as unavailable in the interpolated motion field.
  • FIG. 3 shows an example of unilateral ME in FRUC
  • the matching cost is a bit different at different steps.
  • the matching cost is the absolute sum difference (SAD) of bilateral matching or template matching.
  • SAD absolute sum difference
  • the matching cost C of bilateral matching at sub-CU level search is calculated as follows:
  • MV and MV s indicate the current MV and the starting MV, respectively.
  • SAD is still used as the matching cost of template matching at sub-CU level search.
  • MV is derived by using luma samples only. The derived motion will be used for both luma and chroma for MC inter prediction. After MV is decided, final MC is performed using 8-taps interpolation filter for luma and 4-taps interpolation filter for chroma.
  • MV refinement is a pattern based MV search with the criterion of bilateral matching cost or template matching cost.
  • two search patterns are supported –an unrestricted center-biased diamond search (UCBDS) and an adaptive cross search for MV refinement at the CU level and sub-CU level, respectively.
  • UMBDS center-biased diamond search
  • the MV is directly searched at quarter luma sample MV accuracy, and this is followed by one-eighth luma sample MV refinement.
  • the search range of MV refinement for the CU and sub-CU step are set equal to 8 luma samples.
  • the encoder can choose among uni-prediction from list0, uni-prediction from list1 or bi-prediction for a CU. The selection is based on a template matching cost as follows:
  • cost0 is the SAD of list0 template matching
  • cost1 is the SAD of list1 template matching
  • costBi is the SAD of bi-prediction template matching.
  • the value of factor is equal to 1.25, which means that the selection process is biased toward bi-prediction.
  • the inter prediction direction selection is only applied to the CU-level template matching process.
  • JVET-L0100 multi-hypothesis prediction is proposed, wherein hybrid intra and inter prediction is one way to generate multiple hypotheses.
  • multi-hypothesis prediction When the multi-hypothesis prediction is applied to improve intra mode, multi-hypothesis prediction combines one intra prediction and one merge indexed prediction.
  • a merge CU In a merge CU, one flag is signaled for merge mode to select an intra mode from an intra candidate list when the flag is true.
  • the intra candidate list is derived from 4 intra prediction modes including DC, planar, horizontal, and vertical modes, and the size of the intra candidate list can be 3 or 4 depending on the block shape.
  • horizontal mode is exclusive of the intra mode list and when the CU height is larger than the double of CU width, vertical mode is removed from the intra mode list.
  • One intra prediction mode selected by the intra mode index and one merge indexed prediction selected by the merge index are combined using weighted average.
  • DM is always applied without extra signaling.
  • the weights for combining predictions are described as follow. When DC or planar mode is selected, or the CB width or height is smaller than 4, equal weights are applied. For those CBs with CB width and height larger than or equal to 4, when horizontal/vertical mode is selected, one CB is first vertically/horizontally split into four equal-area regions.
  • (w_intra 1 , w_inter 1 ) is for the region closest to the reference samples and (w_intra 4 , w_inter 4 ) is for the region farthest away from the reference samples.
  • the combined prediction can be calculated by summing up the two weighted predictions and right-shifting 3 bits.
  • the intra prediction mode for the intra hypothesis of predictors can be saved for reference of the following neighboring CUs.
  • Motion compensation is first performed to generate the first predictions (in each prediction direction) of the current block.
  • the first predictions are used to derive the spatial gradient, the temporal gradient and the optical flow of each subblock/pixel within the block, which are then used to generate the second prediction, i.e., the final prediction of the subblock/pixel.
  • the details are described as follows.
  • Bi-directional Optical flow (BIO, also known as BDOF) is sample-wise motion refinement which is performed on top of block-wise motion compensation for bi-prediction.
  • the sample-level motion refinement doesn’t use signalling.
  • FIG. 4 shows an example of optical flow trajectory.
  • the motion vector field (v x , v y ) is given by an equation
  • ⁇ 0 and ⁇ 1 denote the distances to the reference frames as shown on a FIG. 4.
  • the motion vector field (v x , v y ) is determined by minimizing the difference ⁇ between values in points A and B (intersection of motion trajectory and reference frame planes on FIG. 4) .
  • Model uses only first linear term of a local Taylor expansion for ⁇ :
  • Equation 5 All values in Equation 5 depend on the sample location (i′, j′) , which was omitted from the notation so far. Assuming the motion is consistent in the local surrounding area, we minimize ⁇ inside the (2M+1) ⁇ (2M+1) square window ⁇ centered on the currently predicted point (i, j) , where M is equal to 2:
  • the JEM uses a simplified approach making first a minimization in the vertical direction and then in the horizontal direction. This results in
  • d bit depth of the video samples.
  • I (k) In order to keep the memory access for BIO the same as for regular bi-predictive motion compensation, all prediction and gradients values, I (k) , are calculated only for positions inside the current block.
  • (2M+1) ⁇ (2M+1) square window ⁇ centered in currently predicted point on a boundary of predicted block needs to accesses positions outside of the block (as shown in FIG. 5A) .
  • values of I (k) , outside of the block are set to be equal to the nearest available value inside the block. For example, this can be implemented as padding, as shown in FIG. 5B.
  • FIGS. 5A, 5B show examples of BIO w/o block extension.
  • FIG. 5A shows access positions outside of the block;
  • FIG. 5B shows padding isused in order to avoid extra memory access and calculation.
  • BIO it’s possible that the motion field can be refined for each sample.
  • a block-based design of BIO is used in the JEM.
  • the motion refinement is calculated based on 4 ⁇ 4 block.
  • the values of s n in Equation 9 of all samples in a 4 ⁇ 4 block are aggregated, and then the aggregated values of s n in are used to derived BIO motion vectors offset for the 4 ⁇ 4 block. More specifically, the following formula is used for block-based BIO derivation:
  • Equations 7 and 8 are replaced by ( (s n, bk ) >>4) to derive the associated motion vector offsets.
  • MV regiment of BIO might be unreliable due to noise or irregular motion. Therefore, in BIO, the magnitude of MV regiment is clipped to a threshold value thBIO.
  • the threshold value is determined based on whether the reference pictures of the current picture are all from one direction. If all the reference pictures of the current picture are from one direction, the value of the threshold is set to 12 ⁇ 2 14-d ; otherwise, it is set to 12 ⁇ 2 13-d .
  • Gradients for BIO are calculated at the same time with motion compensation interpolation using operations consistent with HEVC motion compensation process (2D separable FIR) .
  • the input for this 2D separable FIR is the same reference frame sample as for motion compensation process and fractional position (fracX, fracY) according to the fractional part of block motion vector.
  • gradient filter BIOfilterG is applied in horizontal direction corresponding to the fractional position fracX with de-scaling shift by 18-d.
  • BIOfilterG corresponding to the fractional position fracY with de-scaling shift d-8
  • signal displacement is performed using BIOfilterS in horizontal direction corresponding to the fractional position fracX with de-scaling shift by 18-d.
  • the length of interpolation filter for gradients calculation BIOfilterG and signal displacement BIOfilterF is shorter (6-tap) in order to maintain reasonable complexity.
  • Table 1 shows the filters used for gradients calculation for different fractional positions of block motion vector in BIO.
  • Table 2 shows the interpolation filters used for prediction signal generation in BIO.
  • Fractional pel position Interpolation filter for gradient (BIOfilterG) 0 ⁇ 8, -39, -3, 46, -17, 5 ⁇ 1/16 ⁇ 8, -32, -13, 50, -18, 5 ⁇ 1/8 ⁇ 7, -27, -20, 54, -19, 5 ⁇ 3/16 ⁇ 6, -21, -29, 57, -18, 5 ⁇ 1/4 ⁇ 4, -17, -36, 60, -15, 4 ⁇ 5/16 ⁇ 3, -9, -44, 61, -15, 4 ⁇ 3/8 ⁇ 1, -4, -48, 61, -13, 3 ⁇ 7/16 ⁇ 0, 1, -54, 60, -9, 2 ⁇ 1/2 ⁇ -1, 4, -57, 57, -4, 1 ⁇
  • Fractional pel position Interpolation filter for prediction signal (BIOfilterS) 0 ⁇ 0, 0, 64, 0, 0, 0 ⁇ 1/16 ⁇ 1, -3, 64, 4, -2, 0 ⁇ 1/8 ⁇ 1, -6, 62, 9, -3, 1 ⁇ 3/16 ⁇ 2, -8, 60, 14, -5, 1 ⁇ 1/4 ⁇ 2, -9, 57, 19, -7, 2 ⁇ 5/16 ⁇ 3, -10, 53, 24, -8, 2 ⁇ 3/8 ⁇ 3, -11, 50, 29, -9, 2 ⁇ 7/16 ⁇ 3, -11, 44, 35, -10, 3 ⁇ 1/2 ⁇ 3, -10, 35, 44, -11, 3 ⁇
  • BIO is applied to all bi-predicted blocks when the two predictions are from different reference pictures.
  • BIO is disabled.
  • BIO is not applied during the OBMC process. This means that BIO is only applied in the MC process for a block when using its own MV and is not applied in the MC process when the MV of a neighboring block is used during the OBMC process.
  • a two-stage early termination method is used to conditionally disable the BIO operations depending on the similarity between the two prediction signals.
  • the early termination is first applied at the CU-level and then at the sub-CU-level.
  • the proposed method first calculates the SAD between the L0 and L1 prediction signals at the CU level. Given that the BIO is only applied to luma, only the luma samples need to be considered for the SAD calculation. If the CU-level SAD is no larger than a predefined threshold, the BIO process is completely disabled for the whole CU.
  • the CU-level threshold is set to 2 (BDepth-9) per sample.
  • the BIO process is not disabled at the CU level, and if the current CU contains multiple sub-CUs, the SAD of each sub-CU inside the CU will be calculated. Then, the decision on whether to enable or disable the BIO process is made at the sub-CU-level based on a predefined sub-CU-level SAD threshold, which is set to 3*2 (BDepth-10) per sample.
  • a predefined sub-CU-level SAD threshold which is set to 3*2 (BDepth-10) per sample.
  • BIO is also known as BDOF.
  • the BDOF can be applied for the CUs which are coded with following modes and features:
  • ⁇ sps_bdof_enabled_flag is equal to 1.
  • predFlagL0 [0] [0] and predFlagL1 [0] [0] are both equal to 1.
  • ⁇ luma_weight_l0_flag [refIdxL0] and luma_weight_l1_flag [refIdxL1] are both equal to 0.
  • ⁇ cbHeight is greater than or equal to 8
  • ⁇ colour component index of the current block is equal to 0.
  • the width and/or height of a CU When the width and/or height of a CU are larger than 16 luma samples, it will be split into sub-blocks with width and/or height equal to 16 luma samples, and the sub-block boundaries are treated as the CU boundaries in the BDOF process.
  • the maximum unit size for BDOF process is limit to 16x16.
  • bi-prediction operation for the prediction of one block region, two prediction blocks, formed using a motion vector (MV) of list0 and a MV of list1, respectively, are combined to form a single prediction signal.
  • MV motion vector
  • DMVR decoder-side motion vector refinement
  • POC–picture order count of current to be encoded picture POC0 and POC1 –picture order counts of the references for the current picture.
  • the signaled merge candidate pair is used as input to DMVR process and are denoted initial motion vectors (MV0, MV1) .
  • the search points that are searched by DMVR obey the motion vector difference mirroring condition. In other words any point that is checked by DMVR, denoted by candidate motion vector pair (MV0’, MV1’) obey the following two equations:
  • MV0′ MV0+MV diff
  • MV1′ MV1-MV diff
  • MV diff represents the points in the search space in one of the reference pictures.
  • the uni-lateral predictions are constructed using regular 8-tap DCTIF interpolation filter.
  • Bilateral matching cost function is calculated by using MRSAD (mean removed sum of absolute differences) between the two predictions (FIG. 6) and the search point resulting in the minimum cost is selected as the refined MV pair.
  • MRSAD mean removed sum of absolute differences
  • FIG. 6 shows an example of bilateral matching with 6 points search
  • the integer precision search points are chosen by the Adaptive pattern method.
  • the cost, corresponding to the central points (pointed by the initial motion vectors) is calculated firstly.
  • the other 4 costs (in sign shape) is calculated by the two predictions, located at the opposite sides of each other by the central point.
  • Last 6th point at the angle is chosen by the gradient of the previous calculated costs (FIG. 7, showing adaptive integer search pattern (left) , half sample search pattern (right) ) .
  • the output of the DMVR process is the refined motion vector pair corresponding to the minimal cost.
  • the minimum cost is achieved at the central point of the search space, i.e. the motion vectors are not changed, and the refinement process is terminated. Otherwise, the best cost further is regarded as center, and the process continues, while the minimal cost does not correspond to the central point and the search range is not exceeded.
  • Half sample precision search is applied only if application of half-pel search does not exceed the search range. In this case only 4 MRSAD calculations are performed, corresponding to plus shape points around the central one, which is chosen as the best during the integer precision search. At the end the refined motion vector pair is output that correspond to the minimal cost point.
  • Reference sample padding is applied in order to extend the reference sample block that is pointed by the initial motion vector. If the size of the coding block are given by “w” and “h” , then it is assumed that a block of size w+7 and h+7 is retrieved from the reference picture buffer. The retrieved buffer is then extended by 2 samples in each direction by repetitive sample padding using the nearest sample. Afterwards the extended reference sample block is used to generate the final prediction once the refined motion vector is obtained (which can deviate from the initial motion vector 2 samples in each direction) .
  • bilinear interpolation is applied during the DMVR search process, which means that the predictions used in MRSAD computation are generated using bilinear interpolation.
  • the final refined motion vectors are obtained regular 8-tap DCTIF interpolation filter is applied to generate final predictions.
  • DMVR is conditionally disabled when the below condition is satisfied.
  • the MV difference between the selected merge candidate and any of the previous ones in the same merge list is less than a pre-defined threshold (that is, 1/4-, 1/4-and 1-pixel-wide intervals for CUs with less than 64 pixels, less than 256 pixels and at least 256 pixels, respectively) .
  • a pre-defined threshold that is, 1/4-, 1/4-and 1-pixel-wide intervals for CUs with less than 64 pixels, less than 256 pixels and at least 256 pixels, respectively.
  • the sum of absolute difference (SAD) between the two prediction signals (L0 and L1 prediction) using the initial motion vectors of the current CU is calculated. If the SAD is no larger than a predefined threshold, i.e., 2 (BDepth-9) per sample, the DMVR is skipped; otherwise, the DMVR is still applied to refine the two motion vectors of the current block.
  • a predefined threshold i.e. 2 (BDepth-9) per sample
  • the MRSAD cost is computed only for odd numbered rows of a block, the even numbered samples rows are not considered. Accordingly the number of operations for the MRSAD calculation is halved.
  • JVET-K0041 a parametric error surface fitted using integer distance position evaluated costs to determine 1/16 th -pel accurate sub-pixel offsets with very minimal computational complexity was proposed.
  • the parametric error surface fit is computed only if the minimum matching cost of integer MVD is not equal to 0, and the matching cost of zero MVD is larger than a threshold.
  • the best integer position is taken as the center position, cost of the center position and cost of positions (-1, 0) , (0, -1) , (1, 0) and (0, 1) (in unit of integer pixel) relative to the center position are used to fit a 2-D parabolic error surface equation of the form:
  • the DMVR can be applied for the CUs which are coded with following modes and features:
  • ⁇ CU has more than 64 luma samples
  • width and/or height of a CU When the width and/or height of a CU are larger than 16 luma samples, it will be further split into sub-blocks with width and/or height equal to 16 luma samples.
  • the maximum unit size for DMVR searching process is limit to 16x16.
  • MMVD 2.5 Merge mode with MVD
  • merge mode with motion vector differences is introduced in VVC.
  • a MMVD flag is singnaled right after sending a skip flag and merge flag to specify whehther MMVD mode is used for a CU.
  • MMVD after a merge candidate is selected, it is further refined by the signalled MVDs information.
  • the further information includes a merge candidate flag, an index to specify motion magnitude, and an index for indication of motion direction.
  • MMVD mode one for the first two candidates in the merge list is selected to be used as MV basis (or base merge candidate) .
  • the merge candidate flag is signalled to specify which one is used.
  • Distance index specifies motion magnitude information and indicate the pre-defined offset from the starting point. As shown in FIG. 9, an offset is added to either horizontal component or vertical component of starting MV. The relation of distance index and pre-defined offset is specified in Table 3.
  • Direction index represents the direction of the MVD relative to the starting point.
  • the direction index can represent of the four directions as shown in Table 4. It’s noted that the meaning of MVD sign could be variant according to the information of starting MVs.
  • the starting MVs is an un-prediction MV or bi-prediction MVs with both lists point to the same side of the current picture (i.e. POCs of two references are both larger than the POC of the current picture, or are both smaller than the POC of the current picture)
  • the sign in Table 4 specifies the sign of MV offset added to the starting MV.
  • the starting MVs is bi-prediction MVs with the two MVs point to the different sides of the current picture (i.e.
  • the sign in Table 4 specifies the sign of MV offset added to the list0 MV component of starting MV and the sign for the list1 MV has opposite value.
  • Outputs of this process are the luma merge motion vector differences in 1/16 fractional-sample accuracy mMvdL0 and mMvdL1.
  • variable currPic specifies the current picture.
  • the luma merge motion vector differences mMvdL0 and mMvdL1 are derived as follows:
  • currPocDiffL0 DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) (8-349)
  • currPocDiffL1 DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) (8-350)
  • currPocDiffL0 is equal to currPocDiffL1
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-352)
  • mMvdL1 [0] MmvdOffset [xCb] [yCb] [0] (8-353)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-354)
  • mMvdL0 [0] MmvdOffset [xCb] [yCb] [0] (8-355)
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-356)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL1) (8-358)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-366)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL0) (8-368)
  • predFlagL0 or predFlagL1 are equal to 1) , the following applies for X being 0 and 1:
  • this contribution proposes a method to refine the sub-block based affine motion compensated prediction with optical flow. After the sub-block based affine motion compensation is performed, luma prediction sample is refined by adding a difference derived by the optical flow equation.
  • the proposed PROF is described as following four steps.
  • Step 1) The sub-block-based affine motion compensation is performed to generate sub-block prediction I (i, j) .
  • Step2 The spatial gradients g x (i, j) and g y (i, j) of the sub-block prediction are calculated at each sample location using a 3-tap filter [-1, 0, 1].
  • the sub-block prediction is extended by one pixel on each side for the gradient calculation. To reduce the memory bandwidth and complexity, the pixels on the extended borders are copied from the nearest integer pixel position in the reference picture. Therefore, additional interpolation for padding region is avoided.
  • Step 3 The luma prediction refinement is calculated by the optical flow equation.
  • ⁇ I (i, j) g x (i, j) * ⁇ v x (i, j) +g y (i, j) * ⁇ v y (i, j)
  • ⁇ v (i, j) is the difference between pixel MV computed for sample location (i, j) , denoted by v (i, j) , and the sub-block MV of the sub-block to which pixel (i, j) belongs, as shown in FIG. 10.
  • FIG. 10 shows an example of a sub-block MV V SB and pixel ⁇ v (i, j) (red arrow)
  • ⁇ v (i, j) can be calculated for the first sub-block, and reused for other sub-blocks in the same CU.
  • x and y be the horizontal and vertical offset from the pixel location to the center of the sub-block, ⁇ v (x, y) can be derived by the following equation,
  • Step 4) Finally, the luma prediction refinement is added to the sub-block prediction I (i, j) .
  • the final prediction I’ is generated as the following equation.
  • I′ (i, j) I (i, j) + ⁇ I (i, j)
  • log2CbW and log2CbH are derived as follows:
  • variable fallbackModeTriggered is set equal to 1 and modified as follows:
  • MinW 4 Min (0, Min (4* (2048+dHorX) , Min (4*dHorY, 4* (2048+dHorX) +4*dHorY) ) ) ) (8-680)
  • fallbackModeTriggered is set equal to 0.
  • fallbackModeTriggered is equal to 1, the following applies:
  • mvLX [xSbIdx] [ySbIdx] [1] Clip3 (-2 17 , 2 17 -1, mvLX [xSbIdx] [ySbIdx] [1] ) (8-696)
  • the average luma motion vector mvAvgLX is derived as follows:
  • variable cbProfFlagLX is derived as follows:
  • cbProfFlagLX is set equal to FALSE.
  • affine_prof_enabled_flag is equal to 0.
  • fallbackModeTriggered is equal to 1.
  • numCpMv is equal to 2 and cpMvLX [1] [0] is equal to cpMvLX [0] [0] and cpMvLX [1] [1] is equal to cpMvLX [0] [1] .
  • numCpMv is equal to 3 and cpMvLX [1] [0] is equal to cpMvLX [0] [0] and cpMvLX [1] [1] is equal to cpMvLX [0] [1] and cpMvLX [2] [0] is equal to cpMvLX [0] [0] and cpMvLX [2] [1] is equal to cpMvLX [0] [1] .
  • cbProfFlagLX set equal to TRUE.
  • variable shift1 is set to equal to Max (6, bitDepth -6) .
  • variable dmvLimit is set to equal to 1 ⁇ shift1.
  • diffMv [x] [y] [i] Clip3 (-dmvLimit, dmvLimit -1, diffMv [x] [y] [i] )
  • VTM5 besides the normal unidirectional prediction and bi-directional prediction mode MVD signalling, symmetric MVD mode for bi-predictional MVD signalling is applied.
  • the symmetric MVD mode motion information including reference picture indices of both list-0 and list-1 and MVD of list-1 are not signaled but derived.
  • the decoding process of the symmetric MVD mode is as follows:
  • variables BiDirPredFlag, RefIdxSymL0 and RefIdxSymL1 are derived as follows:
  • BiDirPredFlag is set equal to 0.
  • BiDirPredFlag is set to 1. Otherwise BiDirPredFlag is set to 0.
  • a symmetrical mode flag indicating whether symmetrical mode is used or not is explicitly signaled if the CU is bi-prediction coded and BiDirPredFlag is equal to 1.
  • FIG. 11 is an illustration for symmetrical MVD mode
  • symmetric MVD motion estimation starts with initial MV evaluation.
  • a set of initial MV candidates comprising of the MV obtained from uni-prediction search, the MV obtained from bi-prediction search and the MVs from the AMVP list.
  • the one with the lowest rate-distortion cost is chosen to be the initial MV for the symmetric MVD motion search.
  • the reference picture type is determined as “short-term reference picture (STRP) ” or “long-term reference picture (LTRP) ” . Both STRP and LTRP can be used as a reference picture for current block.
  • FIG. 12 depicts examples on usage of the mixed STRP and LTRP in SMVD scheme. Using the mirrored L0_MVD as L1_MVD can be inaccurate when reference picture type of the L0 and L1 are different, because the distance difference (distance between reference picture 0 and current picture and distance between reference picture 1 and current picture) is larger, correlation of the motion vector in each direction can be lower.
  • FIG. 12 shows examples on usage of the mixed STRP and LTRP.
  • sym_mvd_flag parsing process is as follows, i.e., availability of the reference pictures are checked and if the conditions are satisfied, sym_mvd_flag is parsed. If sym_mvd_flag is true, MVD of the L1 (MvdL1) is derived as mirrored MvdL0.
  • RefIdxSymL0 is the closest reference picture with POC smaller than POC of the current picture and RefIdxSymL1 is the closest reference picture with POC larger than the POC of the current picture.
  • MVD means the MVD of the List 0.
  • DMVD is used to represent the decoder-side motion vector derivation method, such as BDOF, DMVR, template-based motion estimation, FRUC etc.
  • Whether to enable or disable a coding tool or how to apply a coding tool for a block may depend on the reference picture types (e.g., long-term or short term) of the block and/or resolutions of reference pictures and/or resolution of current picture.
  • reference picture types e.g., long-term or short term
  • the coding tool is disabled for the block.
  • the checking of POC distances of each of the reference picture relative to the current picture is omitted. That is, in one example, the coding tool may be enabled regardless of the POC distances.
  • the coding tool may be enabled for the block.
  • the same reference picture type is long-term or short-term reference picture type or same absolute POC distances of each of the reference picture relative to the current picture.
  • the coding tool may be enabled for the block.
  • type X is the short-term reference picture type.
  • the coding tools may be disabled.
  • the coding tools may be disabled.
  • type X may not be Adaptive Resolution Picture (ARP) .
  • ARP Adaptive Resolution Picture
  • the resolution of the reference picture with type X is same with the resolution of the current picture.
  • type X may be same absolute POC distances of each of the reference picture relative to the current picture.
  • the coding tool is disabled for the block.
  • type X is the long-term reference picture type.
  • type X may be Adaptive Resolution Picture (ARP) .
  • ARP Adaptive Resolution Picture
  • the resolution of the reference picture with type X is different from the resolution of the current picture.
  • the coding tool may be only applied to the reference pictures of a typical reference picture type X.
  • type X is the short-term reference picture type.
  • type X may not be Adaptive Resolution Picture (ARP) .
  • ARP Adaptive Resolution Picture
  • the resolution of the reference picture with type X is same with the resolution of the current picture.
  • type X may be same absolute POC distances of each of the reference picture relative to the current picture.
  • the coding tool is the BDOF coding tool.
  • the coding tool is the DMVR coding tool.
  • the coding tool is the MMVD coding tool.
  • the coding tool is the PROF coding tool.
  • the coding tool is the Affine coding tool.
  • the coding tool is the Combined Inter-Intra Prediction (CIIP) coding tool.
  • CIIP Combined Inter-Intra Prediction
  • the coding tool is the Adaptive Motion Vector Resolution (AMVR) coding tool.
  • AMVR Adaptive Motion Vector Resolution
  • the coding tool is the Triangle Partition Mode (TPM) coding tool.
  • TPM Triangle Partition Mode
  • the coding tool is the SMVD coding tool.
  • the coding tool is the switchable interpolation filtering coding tool.
  • the coding tool is the BCW (i.e., Bi-prediction with CU-level Weights) coding tool.
  • the coding tool is a coding tool which refines the motion information of a block based on coded information, such as DMVD (e.g., including template matching based methods) .
  • coded information such as DMVD (e.g., including template matching based methods)
  • the coding tool is a coding tool which refines the prediction signals of a block based on coded information (e.g., coding methods with optical flow) .
  • Enabling/disabling BDOF may be dependent on the reference picture types.
  • BDOF when all reference pictures are with the same reference picture type, BDOF may be enabled. That is, if two of them are with different types, BDOF may be disabled.
  • BDOF may be enabled when both the reference picture in the past (e.g., with smaller POC value compared to current picture) and the reference picture in the future (e.g., with greater POC value compared to current picture) are long-term or short-term reference pictures or same absolute POC distances of each of the reference picture relative to the current picture.
  • BDOF may be enabled.
  • BDOF may be enabled when both the reference picture in the past and the reference picture in the future are short-term reference pictures.
  • type X is the short-term reference picture type.
  • type X may not be Adaptive Resolution Picture (ARP) .
  • ARP Adaptive Resolution Picture
  • the resolution of the reference picture with type X is same from the resolution of the current picture.
  • At least one of the reference pictures is not with type X, BDOF may be disabled.
  • type X may be same absolute POC distances of each of the reference picture relative to the current picture.
  • Enabling/disabling DMVR may be dependent on the reference picture types.
  • DMVR when all reference pictures are with the same reference picture type, DMVR may be enabled. That is, if two of them are with different types, DMVR may be disabled.
  • DMVR may be enabled when both the reference picture in the past (e.g., with smaller POC value compared to current picture) and the reference picture in the future (e.g., with greater POC value compared to current picture) are long-term or short-term reference pictures or same absolute POC distances of each of the reference picture relative to the current picture.
  • DMVR may be enabled when all reference pictures are with the same reference picture type X.
  • DMVR may be enabled when both the reference picture in the past and the reference picture in the future are short-term reference pictures.
  • type X is the short-term reference picture type.
  • type X may not be Adaptive Resolution Picture (ARP) .
  • ARP Adaptive Resolution Picture
  • the resolution of the reference picture with type X is same from the resolution of the current picture.
  • DMVR may be disabled.
  • type X may be same absolute POC distances of each of the reference picture relative to the current picture.
  • DMVR may be enabled regardless of the POC distances.
  • type Y is the long-term reference picture type.
  • MMVD/BCW/PROF/TPM/SMVD/Affine is enabled or not or how to apply MMVD/BCW/PROF/TPM/SMVD/Affine may be dependent on the reference picture types.
  • MMVD/BCW/PROF/TPM/SMVD/Affine may be enabled; otherwise, MMVD/BCW/PROF/TPM/SMVD/Affine may be disabled.
  • MMVD/BCW/PROF/TPM/SMVD/Affine may be enabled.
  • type X is the short-term reference picture type.
  • type X may be same absolute POC distances of each of the reference picture relative to the current picture.
  • such restriction may be applied to bi-directional predicted blocks.
  • such restriction may be applied to uni-directional predicted blocks.
  • such restriction may be applied to both bi-directional predicted blocks and uni-directional predicted blocks.
  • indication of whether MMVD/BCW/TPM/SMVD/Affine is applied or not may not be signaled.
  • the indication shall always be false, i.e., MMVD/BCW/TPM/SMVD/Affine shall be disabled.
  • the “reference type” of a reference picture disclosed in the document may be determined by judging:
  • a reference picture is long term or short term.
  • the original resolution of a reference picture is identical to the current picture or not.
  • the POC distance between a reference picture and the current picture is in a certain range.
  • the temporal layer of a reference picture is in a certain range.
  • MVD of prediction direction Y may be set equal to the signaled MVD.
  • MVD of prediction direction Y may be set equal to the opposite value of the signaled MVD.
  • X may be set equal to the prediction direction of the MV basis.
  • X may be set equal to 0 or 1.
  • MVD of reference picture list Y may be derived dependent on the reference picture type (e.g., long-term reference picture or short-term reference picture) of the two reference pictures identified by the MV basis.
  • reference picture type e.g., long-term reference picture or short-term reference picture
  • MVD of prediction direction Y may be derived by scaling the signaled MVD according to the POC distance between the two reference pictures and the current picture.
  • MVD of prediction direction Y may be set equal to the signaled MVD.
  • such derivation method may be applied only when at least one of the reference pictures are not a short-term reference picture.
  • MVD of prediction direction Y may be set equal to the opposite value of the signaled MVD.
  • such derivation method may be applied only when at least one of the reference pictures are not a short-term reference picture.
  • Deleted parts are marked with double brackets (e.g., [ [a] ] denotes the deletion of the character “a” ) , and newly added parts are highlighted in Italic and bold.
  • BDOF may be enabled only when both the reference picture in the past and the reference picture in the future are long-term or short-term reference pictures.
  • This process is invoked when decoding a coding unit coded in inter prediction mode.
  • a luma location (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture
  • variable cbWidth specifying the width of the current coding block in luma samples
  • variable cbHeight specifying the height of the current coding block in luma samples
  • variables numSbX and numSbY specifying the number of luma coding subblocks in horizontal and vertical direction
  • variable cIdx specifying the colour component index of the current block.
  • predSamplesL0 L , predSamplesL1 L and predSamplesIntra L be (cbWidth) x (cbHeight) arrays of predicted luma sample values and, predSamplesL0 Cb , predSamplesL1 Cb , predSamplesL0 Cr and predSamplesL1 Cr , predSamplesIntra Cb , and predSamplesIntra Cr be (cbWidth/SubWidthC) x (cbHeight/SubHeightC) arrays of predicted chroma sample values.
  • variable currPic specifies the current picture and the variable bdofFlag is derived as follows:
  • bdofFlag is set equal to TRUE.
  • predFlagL0 [xSbIdx] [ySbIdx] and predFlagL1 [xSbIdx] [ySbIdx] are both equal to 1.
  • DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) * DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) is less than 0.
  • RefPicList [0] [refIdxL0] and RefPicList [1] [refIdxL1] are both long-term or short-term reference pictures
  • luma_weight_l0_flag [refIdxL0] and luma_weight_l1_flag [refIdxL1] are both equal to 0.
  • bdofFlag is set equal to FALSE.
  • BDOF may be enabled only when both the reference picture in the past and the reference picture in the future are short-term reference pictures.
  • This process is invoked when decoding a coding unit coded in inter prediction mode.
  • a luma location (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture
  • variable cbWidth specifying the width of the current coding block in luma samples
  • variable cbHeight specifying the height of the current coding block in luma samples
  • variables numSbX and numSbY specifying the number of luma coding subblocks in horizontal and vertical direction
  • variable cIdx specifying the colour component index of the current block.
  • predSamplesL0 L , predSamplesL1 L and predSamplesIntra L be (cbWidth) x (cbHeight) arrays of predicted luma sample values and, predSamplesL0 Cb , predSamplesL1 Cb , predSamplesL0 Cr and predSamplesL1 Cr , predSamplesIntra Cb , and predSamplesIntra Cr be (cbWidth/SubWidthC) x (cbHeight/SubHeightC) arrays of predicted chroma sample values.
  • variable currPic specifies the current picture and the variable bdofFlag is derived as follows:
  • bdofFlag is set equal to TRUE.
  • predFlagL0 [xSbIdx] [ySbIdx] and predFlagL1 [xSbIdx] [ySbIdx] are both equal to 1.
  • DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) * DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) is less than 0.
  • RefPicList [0] [refIdxL0] and RefPicList [1] [refIdxL1] are both short-term reference pictures
  • luma_weight_l0_flag [refIdxL0] and luma_weight_l1_flag [refIdxL1] are both equal to 0.
  • bdofFlag is set equal to FALSE.
  • DMVR may be enabled only when both the reference picture in the past and the reference picture in the future are long-term or short-term reference pictures.
  • a luma location (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture
  • variable cbWidth specifying the width of the current coding block in luma samples
  • variable cbHeight specifying the height of the current coding block in luma samples
  • variable treeType specifying whether a single or a dual tree is used and if a dual tree is used, it specifies whether the current tree corresponds to the luma or chroma components.
  • Output of this process is a modified reconstructed picture before in-loop filtering.
  • the derivation process for quantization parameters as specified in clause 8.7.1 is invoked with the luma location (xCb, yCb) , the width of the current coding block in luma samples cbWidth and the height of the current coding block in luma samples cbHeight, and the variable treeType as inputs.
  • the decoding process for coding units coded in inter prediction mode consists of the following ordered steps:
  • variable dmvrFlag is set equal to 0.
  • the motion vector components and reference indices of the current coding unit are derived as follows:
  • dmvrFlag is set equal to 1:
  • DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) is equal to DiffPicOrderCnt (RefPicList [1] [refIdxL1] , currPic)
  • RefPicList [0] [refIdxL0] and RefPicList [1] [refIdxL1] are both long-term or short-term reference pictures
  • DMVR may be enabled only when both the reference picture in the past and the reference picture in the future are short-term reference pictures.
  • a luma location (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture
  • variable cbWidth specifying the width of the current coding block in luma samples
  • variable cbHeight specifying the height of the current coding block in luma samples
  • variable treeType specifying whether a single or a dual tree is used and if a dual tree is used, it specifies whether the current tree corresponds to the luma or chroma components.
  • Output of this process is a modified reconstructed picture before in-loop filtering.
  • the derivation process for quantization parameters as specified in clause 8.7.1 is invoked with the luma location (xCb, yCb) , the width of the current coding block in luma samples cbWidth and the height of the current coding block in luma samples cbHeight, and the variable treeType as inputs.
  • the decoding process for coding units coded in inter prediction mode consists of the following ordered steps:
  • variable dmvrFlag is set equal to 0.
  • the motion vector components and reference indices of the current coding unit are derived as follows:
  • dmvrFlag is set equal to 1:
  • DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) is equal to DiffPicOrderCnt (RefPicList [1] [refIdxL1] , currPic)
  • RefPicList [0] [refIdxL0] and RefPicList [1] [refIdxL1] are both short-term reference pictures
  • a luma location (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture
  • variable cbWidth specifying the width of the current coding block in luma samples
  • variable cbHeight specifying the height of the current coding block in luma samples
  • variable treeType specifying whether a single or a dual tree is used and if a dual tree is used, it specifies whether the current tree corresponds to the luma or chroma components.
  • Output of this process is a modified reconstructed picture before in-loop filtering.
  • the derivation process for quantization parameters as specified in clause 8.7.1 is invoked with the luma location (xCb, yCb) , the width of the current coding block in luma samples cbWidth and the height of the current coding block in luma samples cbHeight, and the variable treeType as inputs.
  • the decoding process for coding units coded in inter prediction mode consists of the following ordered steps:
  • variable dmvrFlag is set equal to 0.
  • the motion vector components and reference indices of the current coding unit are derived as follows:
  • dmvrFlag is set equal to 1:
  • DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) is equal to DiffPicOrderCnt (RefPicList [1] [refIdxL1] , currPic) or (RefPicList [0] [refIdxL0] and RefPicList [1] [refIdxL1] are both long-term reference pictures)
  • MMVD may be enabled only when reference pictures of the block are both long-term or short-term reference pictures.
  • mmvd_merge_flag [x0] [y0] 1 specifies that merge mode with motion vector difference is used to generate the inter prediction parameters of the current coding unit.
  • the array indices x0, y0 specify the location (x0, y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture.
  • the current coding block is a bi-predicted block, and one reference picture of the coding block is a short-term reference picture and the other reference picture of the coding block is a long-term reference picture, it is a requirement of bitstream conformance that the value of mmvd_merge_flag [x0] [y0] be equal to 0.
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 1:
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 0.
  • MMVD may be enabled only when reference pictures of the block are both short-term reference pictures.
  • mmvd_merge_flag [x0] [y0] 1 specifies that merge mode with motion vector difference is used to generate the inter prediction parameters of the current coding unit.
  • the array indices x0, y0 specify the location (x0, y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture.
  • the current coding block is a bi-predicted block, and at least one of the two reference pictures of the coding block is the long-term reference picture, it is a requirement of bitstream conformance that the value of mmvd_merge_flag [x0] [y0] be equal to 0.
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 1:
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 0.
  • MMVD may be enabled only when all of the reference pictures of the block are short-term reference pictures.
  • mmvd_merge_flag [x0] [y0] 1 specifies that merge mode with motion vector difference is used to generate the inter prediction parameters of the current coding unit.
  • the array indices x0, y0 specify the location (x0, y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture.
  • At least one reference picture of the current coding block is the long-term reference picture, it is a requirement of bitstream conformance that the value of mmvd_merge_flag [x0] [y0] be equal to 0.
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 1:
  • mmvd_merge_flag [x0] [y0] is inferred to be equal to 0.
  • log2CbW and log2CbH are derived as follows:
  • variable fallbackModeTriggered is set equal to 1 and modified as follows:
  • MinW 4 Min (0, Min (4* (2048+dHorX) , Min (4*dHorY, 4* (2048+dHorX) +4*dHorY) ) ) ) (8-680)
  • fallbackModeTriggered is set equal to 0.
  • fallbackModeTriggered is equal to 1, the following applies:
  • mvLX [xSbIdx] [ySbIdx] [1] Clip3 (-2 17 , 2 17 -1, mvLX [xSbIdx] [ySbIdx] [1] ) (8-696)
  • the average luma motion vector mvAvgLX is derived as follows:
  • variable cbProfFlagLX is derived as follows:
  • cbProfFlagLX is set equal to FALSE.
  • affine_prof_enabled_flag is equal to 0.
  • fallbackModeTriggered is equal to 1.
  • numCpMv is equal to 2 and cpMvLX [1] [0] is equal to cpMvLX [0] [0] and cpMvLX [1] [1] is equal to cpMvLX [0] [1] .
  • numCpMv is equal to 3 and cpMvLX [1] [0] is equal to cpMvLX [0] [0] and cpMvLX [1] [1] is equal to cpMvLX [0] [1] and cpMvLX [2] [0] is equal to cpMvLX [0] [0] and cpMvLX [2] [1] is equal to cpMvLX [0] [1] .
  • RefPicList [X] [refIdxLX] is a long-term reference picture
  • cbProfFlagLX set equal to TRUE.
  • MVD of prediction direction 0 is set equal to the signaled MVD directly and MVD of prediction direction 1 may be set equal to the signaled MVD or the opposite value of the signaled MVD.
  • MVD of prediction direction 1 may be set equal to the signaled MVD.
  • MVD of prediction direction 1 may be set equal to the opposite value of the signaled MVD.
  • Outputs of this process are the luma merge motion vector differences in 1/16 fractional-sample accuracy mMvdL0 and mMvdL1.
  • variable currPic specifies the current picture.
  • the luma merge motion vector differences mMvdL0 and mMvdL1 are derived as follows:
  • currPocDiffL0 DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) (8-349)
  • currPocDiffL1 DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) (8-350)
  • currPocDiffL0 is equal to currPocDiffL1
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-352)
  • mMvdL1 [0] MmvdOffset [xCb] [yCb] [0] (8-353)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-354)
  • mMvdL0 [0] MmvdOffset [xCb] [yCb] [0] (8-355)
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-356)
  • tb Clip3 (-128, 127, currPocDiffL1) (8-358)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-366)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL0) (8-368)
  • predFlagL0 or predFlagL1 are equal to 1) , the following applies for X being 0 and 1:
  • MVD of prediction direction 1 is set equal to the signaled MVD directly and MVD of prediction direction 0 may be set equal to the signaled MVD or the opposite value of the signaled MVD.
  • MVD of prediction direction 0 may be set equal to the signaled MVD.
  • MVD of prediction direction 0 may be set equal to the opposite value of the signaled MVD.
  • Outputs of this process are the luma merge motion vector differences in 1/16 fractional-sample accuracy mMvdL0 and mMvdL1.
  • variable currPic specifies the current picture.
  • the luma merge motion vector differences mMvdL0 and mMvdL1 are derived as follows:
  • currPocDiffL0 DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) (8-349)
  • currPocDiffL1 DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) (8-350)
  • currPocDiffL0 is equal to currPocDiffL1
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-352)
  • mMvdL1 [0] MmvdOffset [xCb] [yCb] [0] (8-353)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-354)
  • mMvdL0 [0] MmvdOffset [xCb] [yCb] [0] (8-355)
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-356)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL1) (8-358)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-366)
  • tb Clip3 (-128, 127, currPocDiffL0) (8-368)
  • predFlagL0 or predFlagL1 are equal to 1) , the following applies for X being 0 and 1:
  • MVD of prediction direction 0 is set equal to the signaled MVD directly and MVD of prediction direction 1 may be set equal to the signaled MVD or the opposite value of the signaled MVD.
  • MVD of prediction direction 1 may be derived by scaling the signaled MVD according to the POC distance between the two reference pictures and the current picture.
  • MVD of prediction direction 1 may be set equal to the signaled MVD.
  • MVD of prediction direction 1 may be set equal to the opposite value of the signaled MVD.
  • Outputs of this process are the luma merge motion vector differences in 1/16 fractional-sample accuracy mMvdL0 and mMvdL1.
  • variable currPic specifies the current picture.
  • the luma merge motion vector differences mMvdL0 and mMvdL1 are derived as follows:
  • currPocDiffL0 DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) (8-349)
  • currPocDiffL1 DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) (8-350)
  • currPocDiffL0 is equal to currPocDiffL1
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-352)
  • mMvdL1 [0] MmvdOffset [xCb] [yCb] [0] (8-353)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-354)
  • mMvdL0 [0] MmvdOffset [xCb] [yCb] [0] (8-355)
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-356)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL1) (8-358)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-366)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL0) (8-368)
  • predFlagL0 or predFlagL1 are equal to 1) , the following applies for X being 0 and 1:
  • MVD of prediction direction 1 is set equal to the signaled MVD directly and MVD of prediction direction 0 may be set equal to the signaled MVD or the opposite value of the signaled MVD.
  • MVD of prediction direction 0 may be derived by scaling the signaled MVD according to the POC distance between the two reference pictures and the current picture.
  • MVD of prediction direction 0 may be set equal to the signaled MVD.
  • MVD of prediction direction 0 may be set equal to the opposite value of the signaled MVD.
  • Outputs of this process are the luma merge motion vector differences in 1/16 fractional-sample accuracy mMvdL0 and mMvdL1.
  • variable currPic specifies the current picture.
  • the luma merge motion vector differences mMvdL0 and mMvdL1 are derived as follows:
  • currPocDiffL0 DiffPicOrderCnt (currPic, RefPicList [0] [refIdxL0] ) (8-349)
  • currPocDiffL1 DiffPicOrderCnt (currPic, RefPicList [1] [refIdxL1] ) (8-350)
  • currPocDiffL0 is equal to currPocDiffL1
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-352)
  • mMvdL1 [0] MmvdOffset [xCb] [yCb] [0] (8-353)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-354)
  • mMvdL0 [0] MmvdOffset [xCb] [yCb] [0] (8-355)
  • mMvdL0 [1] MmvdOffset [xCb] [yCb] [1] (8-356)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL1) (8-358)
  • mMvdL1 [1] MmvdOffset [xCb] [yCb] [1] (8-366)
  • RefPicList [0] [refIdxL0] is not a long-term reference picture and RefPicList [1] [refIdxL1] is not a long-term reference picture, the following applies:
  • tb Clip3 (-128, 127, currPocDiffL0) (8-368)
  • predFlagL0 or predFlagL1 are equal to 1) , the following applies for X being 0 and 1:
  • FIG. 13A is a block diagram of a video processing apparatus 1300.
  • the apparatus 1300 may be used to implement one or more of the methods described herein.
  • the apparatus 1300 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and so on.
  • the apparatus 1300 may include one or more processors 1302, one or more memories 1304 and video processing hardware 1306.
  • the processor (s) 1302 may be configured to implement one or more methods described in the present document.
  • the memory (memories) 1304 may be used for storing data and code used for implementing the methods and techniques described herein.
  • the video processing hardware 1306 may be used to implement, in hardware circuitry, some techniques described in the present document. In some embodiments, the video processing hardware 1306 may be at least partly internal to the processor (s) 1302 (e.g., a graphics co-processor) .
  • FIG. 13B is another example of a block diagram of a video processing system in which disclosed techniques may be implemented.
  • FIG. 13B is a block diagram showing an example video processing system 1310 in which various techniques disclosed herein may be implemented.
  • Various implementations may include some or all of the components of the system 1310.
  • the system 1310 may include input 1312 for receiving video content.
  • the video content may be received in a raw or uncompressed format, e.g., 8 or 10 bit multi-component pixel values, or may be in a compressed or encoded format.
  • the input 1312 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interface include wired interfaces such as Ethernet, passive optical network (PON) , etc. and wireless interfaces such as Wi-Fi or cellular interfaces.
  • PON passive optical network
  • the system 1310 may include a coding component 1314 that may implement the various coding or encoding methods described in the present document.
  • the coding component 1314 may reduce the average bitrate of video from the input 1312 to the output of the coding component 1314 to produce a coded representation of the video.
  • the coding techniques are therefore sometimes called video compression or video transcoding techniques.
  • the output of the coding component 1314 may be either stored, or transmitted via a communication connected, as represented by the component 1316.
  • the stored or communicated bitstream (or coded) representation of the video received at the input 1312 may be used by the component 1318 for generating pixel values or displayable video that is sent to a display interface 1320.
  • the process of generating user-viewable video from the bitstream representation is sometimes called video decompression.
  • certain video processing operations are referred to as “coding” operations or tools, it will be appreciated that the coding tools or operations are used at an encoder and corresponding decoding tools or operations that reverse the results of the coding will be
  • peripheral bus interface or a display interface may include universal serial bus (USB) or high definition multimedia interface (HDMI) or Displayport, and so on.
  • storage interfaces include SATA (serial advanced technology attachment) , PCI, IDE interface, and the like.
  • the video coding methods may be implemented using an apparatus that is implemented on a hardware platform as described with respect to FIG. 13A or 13B.
  • FIG. 14 is a flowchart for a method 1400 of processing a video.
  • the method 1400 includes determining (1402) , for a conversion between a current video block of a video comprising multiple video blocks and a coded representation of the video, and from types of reference pictures used for the conversion, applicability of a coding tool to the current video block and performing (1404) the conversion based on the determining.
  • FIG. 15A is a flowchart for a method 1510 of processing a video.
  • the method 1510 includes, at step 1512, determining, for a conversion between a current video block of a current picture of a video and a coded representation of the video, an applicability of a coding tool to the current video block based on types of reference pictures used for the conversion.
  • the method 1510 includes, at step 1514, performing the conversion based on the determining.
  • the types of the reference pictures are at least based on 1) whether the reference pictures are short term reference pictures or long term reference pictures, 2) resolutions of the reference pictures or the current picture, or 3) picture order count (POC) distances of the reference pictures relative to the current picture.
  • POC picture order count
  • FIG. 15B is a flowchart for a method 1520 of processing a video.
  • the method 1520 includes, at step 1522, determining, for a conversion between a current video block of a video and a coded representation of the video, an applicability of a bi-directional optical flow (BDOF) coding tool or a decoder side motion vector refinement (DMVR) coding tool to the current video block based on types of reference pictures used for the conversion.
  • BDOF bi-directional optical flow
  • DMVR decoder side motion vector refinement
  • the method 1520 includes, at step 1524, performing the conversion based on the determining.
  • using the BDOF coding tool one or more initial predictions are refined based on an optical flow calculation.
  • motion information of the current video block is refined using prediction blocks of the current video block.
  • the types of reference pictures are at least based on 1) whether the reference pictures are short term reference pictures or long term reference pictures, 2) resolutions of the reference pictures or the current picture, or 3) picture order count (POC) distances of the reference pictures relative to the current picture.
  • FIG. 15C is a flowchart for a method 1530 of processing a video.
  • the method 1530 includes, at step 1532, performing a conversion between a current video block of a current picture of a video and a coded representation of the current video block using a merge mode motion vector difference (MMVD) coding in which a merge candidate is selected to be used as a base merge candidate and refined with motion vector difference (MVD) information.
  • MMVD merge mode motion vector difference
  • the merge candidate is selected to be used as the base merge candidate and refined with motion vector difference (MVD) information without scaling the MVD information.
  • the base merge candidate is a bi-directional motion vector, and wherein a MVD of one prediction direction is set as equal to a MVD included in the coded representation and another MVD of the other prediction direction is set as equal or opposite to the MVD included in the coded representation based on a coding condition of the video
  • the coded representation conforms to a rule that specifies that at most a first MVD value for a first prediction direction is included in the coded representation.
  • Some embodiments of the disclosed technology include making a decision or determination to enable a video processing tool or mode.
  • the encoder when the video processing tool or mode is enabled, the encoder will use or implement the tool or mode in the processing of a block of video, but may not necessarily modify the resulting bitstream based on the usage of the tool or mode. That is, a conversion from the block of video to the bitstream representation of the video will use the video processing tool or mode when it is enabled based on the decision or determination.
  • the decoder when the video processing tool or mode is enabled, the decoder will process the bitstream with the knowledge that the bitstream has been modified based on the video processing tool or mode. That is, a conversion from the bitstream representation of the video to the block of video will be performed using the video processing tool or mode that was enabled based on the decision or determination.
  • Some embodiments of the disclosed technology include making a decision or determination to disable a video processing tool or mode.
  • the encoder will not use the tool or mode in the conversion of the block of video to the bitstream representation of the video.
  • the decoder will process the bitstream with the knowledge that the bitstream has not been modified using the video processing tool or mode that was disabled based on the decision or determination.
  • video processing may refer to video encoding, video decoding, video compression or video decompression.
  • video compression algorithms may be applied during conversion from pixel representation of a video to a corresponding bitstream representation or vice versa.
  • the bitstream representation of a current video block may, for example, correspond to bits that are either co-located or spread in different places within the bitstream, as is defined by the syntax.
  • a macroblock may be encoded in terms of transformed and coded error residual values and also using bits in headers and other fields in the bitstream.
  • a method for processing video comprising: determining, for a conversion between a current video block of a video comprising multiple video blocks and a coded representation of the video, and from types of reference pictures used for the conversion, applicability of a coding tool to the current video block; and performing the conversion based on the determining.
  • the coding tool corresponds to one or merge mode with motion vector difference (MMVD) tool or bi-predictive with coding unit weights (BCW) or prediction refinement with optical flow (PROF) or triangular partition mode (TPM) or spatial motion vector difference (SMVD) or Affine coding tool.
  • MMVD motion vector difference
  • BCW bi-predictive with coding unit weights
  • PROF prediction refinement with optical flow
  • TPM triangular partition mode
  • SMVD spatial motion vector difference
  • a method for processing video comprising: determining, for a conversion between a current video block of a video comprising multiple video blocks and a coded representation of the video, and from types of reference pictures used for the conversion, applicability of bi-directional optical flow (BDOF) coding tool to the current video block; and performing the conversion based on the determining.
  • BDOF bi-directional optical flow
  • a method for processing video comprising: determining, for a conversion between a current video block of a video comprising multiple video blocks and a coded representation of the video, and from types of reference pictures used for the conversion, applicability of a coding tool to the current video block, wherein the coding tool corresponds to a decoder side motion vector refinement (DMVR) tool; and performing the conversion based on the determining.
  • DMVR decoder side motion vector refinement
  • a method of video processing comprising: performing a conversion between a current video block of a video and a coded representation of the current video block using a merge mode motion vector difference (MMVD) coding in which the conversion uses a combination of motion vector differencing and merge mode candidates; wherein at least one of a scaling or a prediction direction of a component of MVD is determined from a coding condition of the video.
  • MMVD merge mode motion vector difference
  • a method of video processing comprising: performing a conversion between a current video block of a video and a coded representation of the current video block using a merge mode motion vector difference (MMVD) coding in which a single MVD value of a single direction is signaled.
  • MMVD merge mode motion vector difference
  • a video decoding apparatus comprising a processor configured to implement a method recited in one or more of clauses 1 to 37.
  • a video encoding apparatus comprising a processor configured to implement a method recited in one or more of clauses 1 to 37.
  • a computer program product having computer code stored thereon, the code, when executed by a processor, causes the processor to implement a method recited in any of clauses 1 to 37.
  • a method for processing video comprising: determining, for a conversion between a current video block of a current picture of a video and a coded representation of the video, an applicability of a coding tool to the current video block based on types of reference pictures used for the conversion; and performing the conversion based on the determining, wherein the types of the reference pictures are at least based on 1) whether the reference pictures are short term reference pictures or long term reference pictures, 2) resolutions of the reference pictures or the current picture, or 3) picture order count (POC) distances of the reference pictures relative to the current picture.
  • POC picture order count
  • the determining includes determining that the coding tool is disabled for use with the current video block due to at least two of the reference pictures being of different types.
  • the determining includes determining that the coding tool is disabled for use with the current video block due to one or all of the reference pictures being of a given type.
  • each of the one or all of the reference pictures being of the given type corresponds to an adaptive resolution picture (ARP) such that each of the one or all of the reference pictures has a resolution different from a resolution of the current picture.
  • ARP adaptive resolution picture
  • the one or more reference pictures with the given type does not correspond to an adaptive resolution picture (ARP) and wherein the one or more reference pictures with the given type have a resolution same as a resolution of the current picture.
  • ARP adaptive resolution picture
  • the determining includes omitting checking of picture order count (POC) distances of each of the reference pictures relative to the current picture due to all of the reference pictures being long term reference pictures.
  • POC picture order count
  • the determining includes making a determination regarding an enablement of the coding tool for use with the current video block due to at least two of the reference pictures being of a same type.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Procédé de traitement vidéo comprenant la détermination, pour une conversion entre un bloc vidéo actuel d'une vidéo comprenant de multiples blocs vidéo et une représentation codée de la vidéo, et à partir de types d'images de référence utilisées pour la conversion, de l'applicabilité d'un outil de codage au bloc vidéo actuel et la réalisation de la conversion sur la base de la détermination. Le procédé peut être mis en œuvre par un décodeur vidéo ou un codeur vidéo ou un transcodeur vidéo.
EP20848261.2A 2019-07-27 2020-07-24 Restrictions d'utilisation d'outils en fonction de types d'images de référence Pending EP3984227A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2019098068 2019-07-27
PCT/CN2020/104087 WO2021018031A1 (fr) 2019-07-27 2020-07-24 Restrictions d'utilisation d'outils en fonction de types d'images de référence

Publications (2)

Publication Number Publication Date
EP3984227A1 true EP3984227A1 (fr) 2022-04-20
EP3984227A4 EP3984227A4 (fr) 2022-08-17

Family

ID=74229466

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20848261.2A Pending EP3984227A4 (fr) 2019-07-27 2020-07-24 Restrictions d'utilisation d'outils en fonction de types d'images de référence

Country Status (6)

Country Link
US (3) US11323698B2 (fr)
EP (1) EP3984227A4 (fr)
JP (1) JP7322277B2 (fr)
KR (1) KR20220038060A (fr)
CN (2) CN117560490A (fr)
WO (1) WO2021018031A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3984227A4 (fr) 2019-07-27 2022-08-17 Beijing Bytedance Network Technology Co., Ltd. Restrictions d'utilisation d'outils en fonction de types d'images de référence
WO2023191404A1 (fr) * 2022-03-27 2023-10-05 엘지전자 주식회사 Procédé de codage/décodage d'image utilisant une mts adaptative, dispositif, et support d'enregistrement pour stocker d'un flux binaire
JP2024002460A (ja) * 2022-06-24 2024-01-11 シャープ株式会社 動画像復号装置および動画像符号化装置
WO2024086568A1 (fr) * 2022-10-17 2024-04-25 Bytedance Inc. Procédé, appareil et support de traitement vidéo
US20240195978A1 (en) * 2022-12-13 2024-06-13 Apple Inc. Joint motion vector coding

Family Cites Families (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9008181B2 (en) * 2011-01-24 2015-04-14 Qualcomm Incorporated Single reference picture list utilization for interprediction video coding
US20130070855A1 (en) 2011-09-17 2013-03-21 Qualcomm Incorporated Hybrid motion vector coding modes for video coding
US9525861B2 (en) 2012-03-14 2016-12-20 Qualcomm Incorporated Disparity vector prediction in video coding
US10200709B2 (en) * 2012-03-16 2019-02-05 Qualcomm Incorporated High-level syntax extensions for high efficiency video coding
US9503720B2 (en) * 2012-03-16 2016-11-22 Qualcomm Incorporated Motion vector coding and bi-prediction in HEVC and its extensions
US9479776B2 (en) * 2012-07-02 2016-10-25 Qualcomm Incorporated Signaling of long-term reference pictures for video coding
US9674542B2 (en) * 2013-01-02 2017-06-06 Qualcomm Incorporated Motion vector prediction for video coding
WO2014166119A1 (fr) 2013-04-12 2014-10-16 Mediatek Inc. Syntaxe de haut niveau de compatibilité stéréo
WO2015006967A1 (fr) 2013-07-19 2015-01-22 Mediatek Singapore Pte. Ltd. Prédiction de synthèse de vue simplifiée pour codage vidéo 3d
WO2015021914A1 (fr) 2013-08-13 2015-02-19 Mediatek Inc. Procédé de dérivation de vecteur de disparité par défaut en 3d et codage vidéo multi-vues
MX352916B (es) * 2013-10-14 2017-12-14 Ericsson Telefon Ab L M Alineación de conteo de orden de imágenes en video escalable.
US20150160390A1 (en) 2013-12-10 2015-06-11 Apple Inc. Display Having Polarizer with Unpolarized Strip
WO2015100710A1 (fr) 2014-01-02 2015-07-09 Mediatek Singapore Pte. Ltd. Existence d'une image de référence inter-vues et disponibilité d'outils de codage 3dvc
US10158884B2 (en) 2014-03-19 2018-12-18 Qualcomm Incorporated Simplified merge list construction process for 3D-HEVC
BR112017004886A2 (pt) 2014-09-12 2017-12-05 Vid Scale Inc dispositivo de codificação de vídeo e método de codificação de vídeo
CN106416254B (zh) 2015-02-06 2019-08-02 微软技术许可有限责任公司 在媒体编码期间跳过评估阶段
US10200711B2 (en) * 2015-03-27 2019-02-05 Qualcomm Incorporated Motion vector derivation in video coding
CN108293131B (zh) 2015-11-20 2021-08-31 联发科技股份有限公司 基于优先级运动矢量预测子推导的方法及装置
US11638027B2 (en) * 2016-08-08 2023-04-25 Hfi Innovation, Inc. Pattern-based motion vector derivation for video coding
US10542280B2 (en) 2017-01-09 2020-01-21 QUALCOMM Incorpated Encoding optimization with illumination compensation and integer motion vector restriction
US10701390B2 (en) * 2017-03-14 2020-06-30 Qualcomm Incorporated Affine motion information derivation
US10491917B2 (en) * 2017-03-22 2019-11-26 Qualcomm Incorporated Decoder-side motion vector derivation
US10595035B2 (en) * 2017-03-22 2020-03-17 Qualcomm Incorporated Constraining motion vector information derived by decoder-side motion vector derivation
US11265551B2 (en) 2018-01-18 2022-03-01 Qualcomm Incorporated Decoder-side motion vector derivation
EP3780608A4 (fr) * 2018-04-02 2021-12-01 SZ DJI Technology Co., Ltd. Procédé de traitement d'image et dispositif de traitement d'image
WO2019234578A1 (fr) 2018-06-05 2019-12-12 Beijing Bytedance Network Technology Co., Ltd. Fusions bi-prédictives pondérées asymétriques
EP3834418A1 (fr) 2018-09-23 2021-06-16 Beijing Bytedance Network Technology Co. Ltd. Modification de vecteur de mouvement avec résolution de vecteur de mouvement adaptative
TW202029755A (zh) 2018-09-26 2020-08-01 美商Ｖｉｄ衡器股份有限公司 視訊編碼雙預測
WO2020084461A1 (fr) 2018-10-22 2020-04-30 Beijing Bytedance Network Technology Co., Ltd. Restrictions sur une dérivation de vecteur de mouvement côté décodeur sur la base d'informations de codage
WO2020084462A1 (fr) 2018-10-22 2020-04-30 Beijing Bytedance Network Technology Co., Ltd. Restrictions de dérivation de vecteur de mouvement côté décodeur basée sur une taille de bloc
WO2020084502A1 (fr) 2018-10-23 2020-04-30 Beijing Bytedance Network Technology Co., Ltd. Traitement vidéo utilisant une compensation d'éclairage local
WO2020093999A1 (fr) 2018-11-05 2020-05-14 Beijing Bytedance Network Technology Co., Ltd. Inter-prédiction à affinement dans un traitement vidéo
JP7354241B2 (ja) 2018-11-07 2023-10-02 華為技術有限公司 ビデオエンコーダ、ビデオデコーダ、及び対応する方法
CN112997487B (zh) 2018-11-15 2024-07-09 北京字节跳动网络技术有限公司 仿射模式与其他帧间编解码工具之间的协调
CN113039780B (zh) 2018-11-17 2023-07-28 北京字节跳动网络技术有限公司 视频处理中用运动矢量差的Merge
CN113170167A (zh) 2018-11-29 2021-07-23 北京字节跳动网络技术有限公司 块内拷贝模式中的标志指示方法
HUE064569T2 (hu) * 2019-02-20 2024-03-28 Beijing Dajia Internet Information Korlátozott mozgásvektor származtatás hosszútávú referenciaképhez videó kódolásnál
CN113615193B (zh) 2019-03-22 2024-06-25 北京字节跳动网络技术有限公司 Merge列表构建和其他工具之间的交互
CN113841409B (zh) 2019-05-10 2023-12-19 北京字节跳动网络技术有限公司 用于视频处理的简化二次变换的有条件使用
US11206404B2 (en) * 2019-07-08 2021-12-21 Fastvdo Llc Adaptive resolution change in video streams
EP3984227A4 (fr) 2019-07-27 2022-08-17 Beijing Bytedance Network Technology Co., Ltd. Restrictions d'utilisation d'outils en fonction de types d'images de référence
US11140402B2 (en) * 2019-09-20 2021-10-05 Tencent America LLC Signaling of reference picture resampling with constant window size indication in video bitstream
US20210092404A1 (en) * 2019-09-20 2021-03-25 Qualcomm Incorporated Reference picture constraint for decoder side motion refinement and bi-directional optical flow

Also Published As

Publication number Publication date
US20230239465A1 (en) 2023-07-27
CN117560490A (zh) 2024-02-13
US11323698B2 (en) 2022-05-03
JP2022540942A (ja) 2022-09-20
WO2021018031A1 (fr) 2021-02-04
US20220109827A1 (en) 2022-04-07
US20220217334A1 (en) 2022-07-07
CN114175655A (zh) 2022-03-11
JP7322277B2 (ja) 2023-08-07
EP3984227A4 (fr) 2022-08-17
KR20220038060A (ko) 2022-03-25
JP2023153885A (ja) 2023-10-18
CN114175655B (zh) 2024-01-02
US11589039B2 (en) 2023-02-21
US12041225B2 (en) 2024-07-16

Similar Documents

Publication Publication Date Title
US11632566B2 (en) Inter prediction with refinement in video processing
US11553201B2 (en) Decoder side motion vector derivation
US11973973B2 (en) Prediction refinement based on optical flow
US11876932B2 (en) Size selective application of decoder side refining tools
US11736698B2 (en) Sub-region based determination of motion information refinement
WO2021018031A1 (fr) Restrictions d'utilisation d'outils en fonction de types d'images de référence
JP7572136B2 (ja) 参照ピクチャタイプに従ったツールの使用制限
WO2020224613A1 (fr) Procédé de calcul unifié pour interprédiction avec affinement

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04N0019500000

Ipc: H04N0019105000

A4 Supplementary search report drawn up and despatched

Effective date: 20220718

RIC1 Information provided on ipc code assigned before grant

Ipc: H04N 19/563 20140101ALI20220712BHEP

Ipc: H04N 19/523 20140101ALI20220712BHEP

Ipc: H04N 19/70 20140101ALI20220712BHEP

Ipc: H04N 19/58 20140101ALI20220712BHEP

Ipc: H04N 19/577 20140101ALI20220712BHEP

Ipc: H04N 19/56 20140101ALI20220712BHEP

Ipc: H04N 19/557 20140101ALI20220712BHEP

Ipc: H04N 19/54 20140101ALI20220712BHEP

Ipc: H04N 19/52 20140101ALI20220712BHEP

Ipc: H04N 19/176 20140101ALI20220712BHEP

Ipc: H04N 19/157 20140101ALI20220712BHEP

Ipc: H04N 19/105 20140101AFI20220712BHEP

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240802