WO2020008328A1 - Codage de mode amvp et mode de fusion dépendant de la forme - Google Patents

Codage de mode amvp et mode de fusion dépendant de la forme Download PDF

Info

Publication number
WO2020008328A1
WO2020008328A1 PCT/IB2019/055569 IB2019055569W WO2020008328A1 WO 2020008328 A1 WO2020008328 A1 WO 2020008328A1 IB 2019055569 W IB2019055569 W IB 2019055569W WO 2020008328 A1 WO2020008328 A1 WO 2020008328A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
video block
candidates
list
video
Prior art date
Application number
PCT/IB2019/055569
Other languages
English (en)
Inventor
Hongbin Liu
Li Zhang
Kai Zhang
Yue Wang
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 WO2020008328A1 publication Critical patent/WO2020008328A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/119Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/105Selection 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/109Selection of coding mode or of prediction mode among a plurality of temporal predictive coding modes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/11Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/176Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/184Methods 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 bits, e.g. of the compressed video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/186Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • H04N19/517Processing of motion vectors by encoding
    • H04N19/52Processing of motion vectors by encoding by predictive encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96Tree coding, e.g. quad-tree coding

Definitions

  • This document is related to video coding 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 decoder or encoder embodiments for in which performance of coding of intra-coding of video blocks is improved using a block-shape dependent coding technique.
  • a method of video bitstream processing includes generating, for a video block that is inter-coded, a list of merge candidates according to a first shape dependency rule that depends on a shape of the video block, and using the list of merge candidates to reconstruct a coded representation of the video block.
  • a method of reconstructing a video block includes generating, for a video block that is inter-coded, a list of advanced motion vector prediction (AMVP) candidates according to a first shape dependency rule that depends on a shape of the video block, and using the list of AMVP candidates to reconstruct a coded representation of the video block.
  • AMVP advanced motion vector prediction
  • the above-described method may be implemented by a video decoder apparatus that comprises a processor.
  • the above-described method may be implemented by a video encoder apparatus comprising a processor for decoding encoded video during video encoding process.
  • these methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.
  • FIG. 1 is an illustration of a QUAD TREE BINARY TREE (QTBT) structure
  • FIG. 2 shows an example derivation process for merge candidates list construction.
  • FIG. 3 shows example positions of spatial merge candidates.
  • FIG. 4 shows an example of candidate pairs considered for redundancy check of spatial merge candidates.
  • FIG. 5 shows examples of positions for the second prediction unit (PU) of Nx2N and 2NxN partitions.
  • FIG. 6 is an illustration of motion vector scaling for temporal merge candidate.
  • FIG. 7 shows example candidate positions for temporal merge candidate, CO and Cl.
  • FIG. 8 shows an example of combined bi-predictive merge candidate.
  • FIG. 9 shows an example of a derivation process for motion vector prediction candidates.
  • FIG. 10 is an illustration of motion vector scaling for spatial motion vector candidate.
  • FIG. 11 shows an example of advanced temporal motion vector prediction (ATMVP) motion prediction for a coding unit (CU).
  • ATMVP advanced temporal motion vector prediction
  • FIG. 12 shows an example of one CU with four sub-blocks (A-D) and its neighbouring blocks (a-d).
  • FIG. 13 illustrates proposed non-adjacent merge candidates in J0021.
  • FIG. 14 illustrates proposed non-adjacent merge candidates in J0058.
  • FIG. 15 illustrates proposed non-adjacent merge candidates in J0059.
  • FIG. 16 illustrates proposed 67 intra prediction modes.
  • FIG. 17 shows examples of neighbouring blocks for most probable mode (MPM) derivation.
  • FIG. 18 shows examples of corresponding sub-blocks for a chroma CB in I slice.
  • FIG. 19A and FIG. 19B show examples of additional blocks used for MPM list.
  • FIG. 20 is a block diagram of an example of a video processing apparatus.
  • FIG. 21 shows a block diagram of an example implementation of a video encoder.
  • FIG. 22 is a flowchart for an example of a video bitstream processing method.
  • FIG. 23 is a flowchart for an example of a video bitstream processing method.
  • the present document provides various techniques that can be used by a decoder of video bitstreams to improve the quality of decompressed or decoded digital video. Furthermore, a video encoder may also implement these techniques during the process of encoding in order to reconstruct coded or decoded frames used for further encoding.
  • the term video block is used to represent a logical grouping of pixels and different embodiments may work with video blocks of different sizes. Furthermore, a video block may correspond to one chroma or luma component or may include another component representation such as RGB representation.
  • 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.
  • the techniques described in this patent document relate to video coding technologies. Specifically, it is related to intra/inter mode coding in video coding. It may be applied to the existing video coding standard like High Efficiency Video Coding (HEVC), or the standard (Versatile Video Coding) to be finalized. It may be also applicable to future video coding standards or video codec.
  • HEVC High Efficiency Video Coding
  • Versatile Video Coding Very Video Coding
  • 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-l and MPEG-4 Visual, and the two organizations jointly produced the
  • AVC H.264/MPEG-4 Advanced Video Coding
  • H.265/HEVC [1] standards. Since H.262, 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. Since then, many new methods have been adopted by JVET and put into the reference software named Joint Exploration Model (JEM).
  • JEM Joint Exploration Model
  • the Joint Video Expert Team (JVET) between VCEG (Q6/16) and ISO/IEC JTC1 SC29/WG11 (MPEG) was created to work on the VVC standard targeting at 50% bitrate reduction compared to HEVC.
  • FIG. 21 is a block diagram of an example implementation of a video encoder.
  • a CTU is split into coding units (CUs) by using a quadtree structure denoted as coding tree to adapt to various local characteristics.
  • the decision whether to code a picture area using inter-picture (temporal) or intra-picture (spatial) prediction is made at the CU level.
  • Each CU can be further split into one, two or four prediction units (PUs) according to the PU splitting type. Inside one PU, the same prediction process is applied and the relevant information is transmitted to the decoder on a PU basis.
  • a CU can be partitioned into transform units (TUs) according to another quadtree structure similar to the coding tree for the CU.
  • TUs transform units
  • the QTBT structure removes the concepts of multiple partition types, i.e. it removes the separation of the CU, PU and TU concepts, and supports more flexibility for CU partition shapes.
  • a CU can have either a square or rectangular shape.
  • a CTU is first partitioned by a quadtree structure.
  • the quadtree leaf nodes are further partitioned by a binary tree structure.
  • the binary tree leaf nodes are called coding units (CUs), and that segmentation is used for prediction and transform processing without any further partitioning.
  • a CU sometimes consists of coding blocks (CBs) of different colour components, e.g. one CU contains one luma CB and two chroma CBs in the case of P and B slices of the 4:2:0 chroma format and sometimes consists of a CB of a single component, e.g., one CU contains only one luma CB or just two chroma CBs in the case of I slices.
  • CBs coding blocks
  • - CTU size the root node size of a quadtree, the same concept as in HEVC;
  • MinQTSize the minimum allowed quadtree leaf node size
  • MaxBTSize the maximum allowed binary tree root node size
  • MinBTSize the minimum allowed binary tree leaf node size.
  • the CTU size is set as 128x128 luma samples with two corresponding 64x64 blocks of chroma samples
  • theMinQTSize is set as 16x
  • t e MaxBTSize is set as 64x64
  • the MinBTSize (for both width and height) is set as 4x4
  • the MaxBTDepth is set as 4.
  • the quadtree partitioning is applied to the CTU first to generate quadtree leaf nodes.
  • the quadtree leaf nodes may have a size from 16x 16 (i.e., the MinQTSize) to 128x128 (i.e., the CTU size).
  • the quadtree leaf node is also the root node for the binary tree and it has the binary tree depth as 0.
  • MaxBTDepth i.e., 4
  • no further splitting is considered.
  • MinBTSize i.e. 4
  • no further horizontal splitting is considered.
  • the binary tree node has height equal to MinBTSize
  • no further vertical splitting is considered.
  • the leaf nodes of the binary tree are further processed by prediction and transform processing without any further partitioning. In the JEM, the maximum CTU size is 256x256 luma samples.
  • FIG. 1 illustrates an example of block partitioning by using QTBT
  • FIG. 1 (right) illustrates the corresponding tree representation.
  • the solid lines indicate quadtree splitting and dotted lines indicate binary tree splitting.
  • each splitting (i.e., non-leaf) node of the binary tree one flag is signalled to indicate which splitting type (i.e., horizontal or vertical) is used, where 0 indicates horizontal splitting and 1 indicates vertical splitting.
  • the quadtree splitting there is no need to indicate the splitting type since quadtree splitting always splits a block both horizontally and vertically to produce 4 sub-blocks with an equal size.
  • the QTBT scheme supports the ability for the luma and chroma to have a separate QTBT structure.
  • the luma and chroma CTBs in one CTU share the same QTBT structure.
  • the luma CTB is partitioned into CUs by a QTBT structure
  • the chroma CTBs are partitioned into chroma CUs by another QTBT structure. This means that a CU in an I slice consists of a coding block of the luma component or coding blocks of two chroma components, and a CU in a P or B slice consists of coding blocks of all three colour components.
  • inter prediction for small blocks is restricted to reduce the memory access of motion compensation, such that bi-prediction is not supported for 4x8 and 8x4 blocks, and inter prediction is not supported for 4x4 blocks. In the QTBT of the JEM, these restrictions are removed.
  • Each inter-predicted PU has motion parameters for one or two reference picture lists.
  • Motion parameters include a motion vector and a reference picture index. Usage of one of the two reference picture lists may also be signalled using inter _predjdc. Motion vectors may be explicitly coded as deltas relative to predictors.
  • a merge mode is specified whereby the motion parameters for the current PU are obtained from neighbouring PUs, including spatial and temporal candidates.
  • the merge mode can be applied to any inter-predicted PU, not only for skip mode.
  • the alternative to merge mode is the explicit transmission of motion parameters, where motion vector (to be more precise, motion vector difference compared to a motion vector predictor), corresponding reference picture index for each reference picture list and reference picture list usage are signalled explicitly per each PU.
  • Such mode is named Advanced motion vector prediction (AMVP) in this disclosure.
  • the PU When signalling indicates that one of the two reference picture lists is to be used, the PU is produced from one block of samples. This is referred to as‘uni-prediction’. Uni-prediction is available both for P-slices and B-slices. [0053] When signalling indicates that both of the reference picture lists are to be used, the PU is produced from two blocks of samples. This is referred to as‘bi-prediction’. Bi-prediction is available for B-slices only.
  • Step 1.2 Redundancy check for spatial candidates
  • FIG. 5 depicts the second PU for the case of Nx2N and 2N/N, respectively.
  • candidate at position Ai is not considered for list construction.
  • position Bi is not considered when the current PU is partitioned as 2NxN.
  • a scaled motion vector is derived based on co-located PU belonging to the picture which has the smallest POC difference with current picture within the given reference picture list.
  • the reference picture list to be used for derivation of the co-located PU is explicitly signalled in the slice header.
  • the scaled motion vector for temporal merge candidate is obtained as illustrated by the dashed line in FIG.
  • tb is defined to be the POC difference between the reference picture of the current picture and the current picture
  • td is defined to be the POC difference between the reference picture of the co-located picture and the co-located picture.
  • the reference picture index of temporal merge candidate is set equal to zero.
  • FIG. 6 is an illustration of motion vector scaling for temporal merge candidate.
  • the position for the temporal candidate is selected between candidates Co and Ci, as depicted in FIG. 7. If PU at position Co is not available, is intra coded, or is outside of the current CTU row, position Ci is used. Otherwise, position Co is used in the derivation of the temporal merge candidate.
  • merge candidates Besides spatial and temporal merge candidates, there are two additional types of merge candidates: combined bi-predictive merge candidate and zero merge candidate.
  • Combined bi- predictive merge candidates are generated by utilizing spatial and temporal merge candidates.
  • Combined bi-predictive merge candidate is used for B-Slice only.
  • the combined bi-predictive candidates are generated by combining the first reference picture list motion parameters of an initial candidate with the second reference picture list motion parameters of another. If these two tuples provide different motion hypotheses, they will form a new bi-predictive candidate. As an example, FIG.
  • motion estimation can be performed in parallel whereby the motion vectors for all prediction units inside a given region are derived
  • HEVC defines the motion estimation region (MER) whose size is signalled in the picture parameter set using the
  • AMVP exploits spatio-temporal correlation of motion vector with neighbouring PUs, which is used for explicit transmission of motion parameters.
  • a motion vector candidate list is constructed by firstly checking availability of left, above temporally neighbouring PU positions, removing redundant candidates and adding zero vector to make the candidate list to be constant length. Then, the encoder can select the best predictor from the candidate list and transmit the corresponding index indicating the chosen candidate. Similarly with merge index signalling, the index of the best motion vector candidate is encoded using truncated unary. The maximum value to be encoded in this case is 2 (see FIG. 9).
  • the maximum value to be encoded is 2 (see FIG. 9).
  • FIG. 9 summarizes derivation process for motion vector prediction candidate.
  • motion vector candidate two types are considered: spatial motion vector candidate and temporal motion vector candidate.
  • spatial motion vector candidate derivation two motion vector candidates are eventually derived based on motion vectors of each PU located in five different positions as depicted in FIG. 3.
  • one motion vector candidate is selected from two candidates, which are derived based on two different co-located positions. After the first list of spatio-temporal candidates is made, duplicated motion vector candidates in the list are removed. If the number of potential candidates is larger than two, motion vector candidates whose reference picture index within the associated reference picture list is larger than 1 are removed from the list. If the number of spatio-temporal motion vector candidates is smaller than two, additional zero motion vector candidates is added to the list.
  • FIG. 10 is an illustration of motion vector scaling for spatial motion vector candidate.
  • the motion vector of the neighbouring PU is scaled in a similar manner as for temporal scaling, as depicted as FIG. 10.
  • the main difference is that the reference picture list and index of current PU is given as input; the actual scaling process is the same as that of temporal scaling.
  • each CU can have at most one set of motion parameters for each prediction direction.
  • Two sub-CU level motion vector prediction methods are considered in the encoder by splitting a large CU into sub-CUs and deriving motion information for all the sub- CUs of the large CU.
  • Alternative temporal motion vector prediction (ATMVP) method allows each CU to fetch multiple sets of motion information from multiple blocks smaller than the current CU in the collocated reference picture.
  • STMVP spatial-temporal motion vector prediction
  • the motion vectors temporal motion vector prediction (TMVP) is modified by fetching multiple sets of motion information (including motion vectors and reference indices) from blocks smaller than the current CU.
  • the sub-CUs are square NxN blocks (N is set to 4 by default).
  • ATMVP predicts the motion vectors of the sub-CUs within a CU in two steps.
  • the first step is to identify the corresponding block in a reference picture with a so-called temporal vector.
  • the reference picture is called the motion source picture.
  • the second step is to split the current CU into sub-CUs and obtain the motion vectors as well as the reference indices of each sub-CU from the block corresponding to each sub-CU, as shown in FIG. 11.
  • a reference picture and the corresponding block is determined by the motion information of the spatial neighbouring blocks of the current CU.
  • the first merge candidate in the merge candidate list of the current CU is used.
  • the first available motion vector as well as its associated reference index are set to be the temporal vector and the index to the motion source picture. This way, in
  • the corresponding block may be more accurately identified, compared with TMVP, wherein the corresponding block (sometimes called collocated block) is always in a bottom-right or center position relative to the current CU.
  • a corresponding block of the sub-CU is identified by the temporal vector in the motion source picture, by adding to the coordinate of the current CU the temporal vector.
  • the motion information of its corresponding block (the smallest motion grid that covers the center sample) is used to derive the motion information for the sub-CU.
  • the motion information of a corresponding NxN block is identified, it is converted to the motion vectors and reference indices of the current sub-CU, in the same way as TMVP of HEVC, wherein motion scaling and other procedures apply.
  • the decoder checks whether the low-delay condition (i.e.
  • motion vector MV X the motion vector corresponding to reference picture list X
  • motion vector MV y the motion vector MV y (with X being equal to 0 or 1 and Y being equal to l-X) for each sub-CU.
  • FIG. 12 illustrates this concept. Let us consider an 8x8 CU which contains four 4x4 sub-CUs A, B, C, and D. The neighbouring 4x4 blocks in the current frame are labelled as a, b, c, and d.
  • the motion derivation for sub-CU A starts by identifying its two spatial neighbours.
  • the first neighbour is the NxN block above sub-CU A (block c). If this block c is not available or is intra coded the other NxN blocks above sub-CU A are checked (from left to right, starting at block c).
  • the second neighbour is a block to the left of the sub-CU A (block b). If block b is not available or is intra coded other blocks to the left of sub-CU A are checked (from top to bottom, staring at block b).
  • the motion information obtained from the neighbouring blocks for each list is scaled to the first reference frame for a given list.
  • temporal motion vector predictor (TMVP) of sub-block A is derived by following the same procedure of TMVP derivation as specified in HEVC.
  • the motion information of the collocated block at location D is fetched and scaled accordingly. Finally, after retrieving and scaling the motion information, all available motion vectors (up to 3) are averaged separately for each reference list. The averaged motion vector is assigned as the motion vector of the current sub-CU.
  • the sub-CU modes are enabled as additional merge candidates and there is no additional syntax element required to signal the modes.
  • Two additional merge candidates are added to merge candidates list of each CU to represent the ATMVP mode and STMVP mode.
  • Tencent proposes to derive additional spatial merge candidates from positions in an outer reference area which has an offset of (-96, -96) to the current block.
  • each candidate B (i, j) or C (i, j) has an offset of 16 in the vertical direction compared to its previous B or C candidates.
  • Each candidate A (i, j) or D (i, j) has an offset of 16 in the horizontal direction compared to its previous A or D candidates.
  • Each E (i, j) has an offset of 16 in both horizontal direction and vertical direction compared to its previous E candidates. The candidates are checked from inside to the outside.
  • the order of the candidates is A (i, j), B (i, j), C (i, j), D (i, j), and E (i, j).
  • the candidates are added after TMVP candidates in the merge candidate list.
  • J0059 the extended spatial positions from 6 to 27 as in FIG. 15 are checked according to their numerical order after the temporal candidate. To save the MV line buffer, all the spatial candidates are restricted within two CTU lines.
  • the number of directional intra modes is extended from 33, as used in HEVC, to 65.
  • the additional directional modes are depicted as red dotted arrows in FIG. 16, and the planar and DC modes remain the same.
  • These denser directional intra prediction modes apply for all block sizes and for both luma and chroma intra predictions.
  • MPMs Most Probable Modes
  • Two major technical aspects are involved: 1) the derivation of 6 MPMs, and 2) entropy coding of 6 MPMs and non-MPM modes.
  • JEM the modes included into the MPM lists are classified into three groups:
  • the MPM list Five neighbouring intra prediction modes are used to form the MPM list. Those locations of the 5 neighbouring blocks are the same as those used in the merge mode, i.e., left (L), above (A), below-left (BL), above-right (AR), and above-left (AL) as shown in FIG. 17.
  • An initial MPM list is formed by inserting 5 neighbour intra modes and the planar and DC modes into the MPM list. A pruning process is used to remove duplicated modes so that only unique modes can be included into the MPM list. The order in which the initial modes are included is: left, above, planar, DC, below-left, above-right, and then above-left.
  • FIG. 17 shows examples of neighbouring blocks for MPM derivation
  • derived modes are added; these intra modes are obtained by adding -1 or +1 to the angular modes that are already included in the MPM list. Such additional derived modes are not generated from the non-angular modes (DC or planar).
  • a truncated unary binarization is used for entropy coding of the selected mode using the 6 MPMs.
  • the first three bins are coded with contexts that depend on the MPM mode related to the bin currently being signalled.
  • the MPM mode is classified into one of three categories: (a) modes that are predominantly horizontal (i.e., the MPM mode number is less than or equal to the mode number for the diagonal direction), (b) modes that are predominantly vertical (i.e., the MPM mode is greater than the mode number for the diagonal direction), and (c) the non-angular (DC and planar) class. Accordingly, three contexts are used to signal the MPM index based on this classification.
  • the coding for selection of the remaining 61 non-MPMs is done as follows.
  • the 61 non-MPMs are first divided into two sets: a selected mode set and a non-selected mode set.
  • the selected modes set contains 16 modes and the rest (45 modes) are assigned to the non-selected modes set.
  • the mode set that the current mode belongs to is indicated in the bitstream with a flag. If the mode to be indicated is within the selected modes set, the selected mode is signalled with a 4-bit fixed-length code, and if the mode to be indicated is from the non-selected set, the selected mode is signalled with a truncated binary code.
  • the selected modes set is generated by sub-sampling the 61 non-MPM modes as follows:
  • Non-selected modes set ⁇ 1, 2, 3, 5, 6, 7, 9, 10 ... 59 ⁇
  • the similar two-stage intra mode decision process of HM is used.
  • the intra mode pre-selection stage a lower complexity Sum of Absolute Transform Difference (SATD) cost is used to pre-select N intra prediction modes from all the available intra modes.
  • SATD Absolute Transform Difference
  • R-D cost selection is further applied to select one intra prediction mode from the N candidates.
  • 67 intra prediction modes since the total number of available modes is roughly doubled, the complexity of the intra mode pre-selection stage will also be increased if the same encoder mode decision process of HM is directly used.
  • a two-step intra mode pre-selection process is performed.
  • N N depends on intra prediction block size
  • STD Sum of Absolute Transform Difference
  • the direct neighbours (additional intra prediction directions as indicated by dashed arrows in FIG. 16) of the selected N modes are further examined by SATD, and the list of selected N modes are updated.
  • the first MMPMs are added to the N modes if not already included, and the final list of candidate intra prediction modes is generated for the second stage R-D cost examination, which is done in the same way as HM.
  • the value of M is increased by one based on the original setting in the HM, and N is decreased somewhat as shown below in Table 1.
  • Table 1 Number of mode candidates at the intra mode pre-selection step
  • the five positions to be checked in order are: center (CR), top-left (TL), top-right (TR), bottom-left (BL) and bottom-right (BR) 4x4 block within the corresponding luma block of current chroma block for I slices.
  • center (CR) top-left
  • TR top-right
  • BL bottom-left
  • BR bottom-right
  • An example of five collocated luma positions is shown in FIG. 18.
  • o 5 chroma prediction modes from left, above, below-left, above-right, and above- left spatially neighbouring blocks
  • o Derived modes are added, these intra modes are obtained by adding -1 or +1 to the angular modes which are already included into the list
  • a pruning process is applied whenever a new chroma intra mode is added to the candidate list.
  • the non-CCLM chroma intra mode candidates list size is then trimmed to 5.
  • a flag is first signalled to indicate whether one of the CCLM modes or one of the traditional chroma intra prediction mode is used. Then a few more flags may follow to specify the exact chroma prediction mode used for the current chroma CBs.
  • the default intra modes used for MPM list construction are always vertical (VER), horizontal (HOR), mode 2, and diagonal mode (DIG), which is not reasonable.
  • the insertion order of merge candidates depends on the current CU shape. a. In one example, for CU shape with width > M * height, a merge candidate fetched from the above neighbouring block is inserted before that fetched from the left neighbouring block, wherein M is equal to 1, 2, 3 or other values.
  • a merge candidate fetched from the above-right neighbouring block is inserted before that fetched from the below-left block.
  • a merge candidate fetched from the above-left neighbouring block is inserted before that fetched from the below-left block.
  • merge candidates fetched from neighbouring blocks above the current block are all inserted before those fetched from neighbouring blocks left to the current block.
  • the insertion order may further depends on the prediction direction. For example, bi-prediction merge candidates are always inserted before uni-prediction merge candidates.
  • a In one example, for CU shape with width > M * height, the above right, above and above left are first checked, and then the below left and left blocks are checked. b. In one example, for CU shape with width > M * height, it is proposed to check more MVPs from above neighbouring blocks, like the above-middle block shown in FIG. 19 A).
  • c. Is defined by width and height of the block.
  • the proposed methods may be applied to certain modes, block sizes/shapes, and/or certain sub-block sizes.
  • the proposed methods may be applied to certain modes, such as conventional translational motion (i.e., affine mode is disabled).
  • affine mode is disabled.
  • the proposed methods may be applied to certain block sizes.
  • the proposed methods may be applied on all colour components. Alternatively, they may be applied only to some colour components. For example, they may be only applied on the luma component.
  • FIG. 20 is a block diagram of a video processing apparatus 2000.
  • the apparatus 2000 may be used to implement one or more of the methods described herein.
  • the apparatus 2000 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and so on.
  • the apparatus 2000 may include one or more processors 2002, one or more memories 2004 and video processing hardware 2006.
  • the processor(s) 2002 may be configured to implement one or more methods described in the present document, such as the methods described with reference to methods 2200 and 2300.
  • the memory (memories) 2004 may be used for storing data and code used for implementing the methods and techniques described herein, such as the methods described with reference to methods 2200 and 2300.
  • the video processing hardware 2006 may be used to implement, in hardware circuitry, some techniques described in the present document.
  • FIG. 22 is a flowchart for a method 2200 of video bitstream processing.
  • the method 2200 includes generating (2202), for a video block that is inter-coded, a list of merge candidates according to a first shape dependency rule that depends on a shape of the video block, and reconstructing (2204) a coded representation of the video block using the list of merge candidates.
  • first shape dependency rule specifies an order in which neighboring blocks are checked for insertion into the list of merge candidates.
  • the first shape dependency rule specifies that in case that the video block has a width that is greater than N multiples of a height of the video block, where N is an integer greater than or equal to 1, then the list of merge candidates is generated by first using candidates from above neighboring blocks relative to the video block before candidates from left neighboring blocks relative to the video block.
  • a candidate from an above-right neighboring block relative to the video block is checked before a candidate from a below-left neighboring block relative to the video block, or a candidate from an above-left neighboring block relative to the video block is checked before a candidate from a below-left neighboring block relative to the video block.
  • the first shape dependency rule specifies that in case that the video block has a width that is greater than M multiples of a height of the video block, where M is an integer greater than or equal to 1 , then the list of merge candidates includes merge candidates from an above neighboring block relative to the video block. With reference to method 2200, one of the above neighboring blocks is a middle block.
  • the first shape dependency rule specifies that in case that the video block has a height that is greater than M multiples of a width of the video block, where M is an integer, then the list of merge candidates includes merge candidates from a left neighboring block relative to the video block.
  • the left neighboring block is a middle block.
  • the list of merge candidates is ordered according to prediction direction.
  • the list of merge candidate includes bi prediction merge candidates before uni-prediction merge candidates.
  • FIG. 23 is a flowchart for a method 2300 of reconstructing a video block.
  • the method 2300 includes generating (2302), for a video block that is inter-coded, a list of merge candidates according to a first shape dependency rule that depends on a shape of the video block, and reconstructing (2304) a coded representation of the video block using the list of merge candidates.
  • the first shape dependency rule specifies an order in which neighboring blocks are checked for insertion into the list of AMVP candidates.
  • the first shape dependency rule specifies that in case that the video block has a width that is greater than M multiples of a height of the video block, where M is an integer greater than or equal to 1, then the list of AMVP candidates includes AMVP candidates from an above neighboring block relative to the video block, an above-right neighboring block relative to the video block, and an above-left neighboring block relative to the video block that are checked before a below-left neighboring block relative to the video block and a left neighboring block relative to the video block.
  • the first shape dependency rule specifies that in case that the video block has a width that is greater than M multiples of a height of the video block, where M is an integer greater than or equal to 1 , then the list of AMVP candidates includes AMVP candidates from an above neighboring block relative to the video block, where the AMVP candidates from an above neighboring block are checked.
  • the above neighboring block is a middle block.
  • the first shape dependency rule specifies that in case that the video block has a height that is greater than M multiples of a width of the video block, where M is an integer greater than or equal to 1, then the list of AMVP candidates includes AMVP candidates from a left neighboring block relative to the video block, where the AMVP candidates from a left neighboring block are checked.
  • the left neighboring block is a middle block.
  • the shape of the video block is one of a square or a rectangle.
  • the shape of the video block corresponds to a ratio of the width and the height.
  • the first shape dependency rule selectively applies two different dependency rules based on a coding condition of the video block.
  • the coding condition includes a translational motion coding mode, or an affine motion coding mode.
  • the coding condition includes whether a number of pixels in the video block or a height of the video block or a width of the video block exceed is greater than or equal to a threshold value.
  • the method is applied to one or more of a luma component or a chroma component of the video block.
  • the video block may represent a CU of a compressed video bitstream.
  • the shape of the video block may depend on height to width ratio, or actual values of height and width, or relative values of height and widths.
  • the various lists of candidates may be generated implicitly or explicitly (e.g., by storing a list in memory).
  • neighboring blocks and their use are described in Section 4 of the present document.
  • a preference may be given to either the top neighboring blocks or the left neighboring blocks.
  • the central or middle block (or sub-block) of the top or left side may be the preferred block from which candidates to add to the list are used.
  • the video block may be encoded in the video bitstream using a codeword based technique (e.g., a context adaptive binary arithmetic coding or a variable length coding) technique in which bit efficiency may be achieved by using a bitstream generation rule that also depends on the shape of the video block.
  • a codeword based technique e.g., a context adaptive binary arithmetic coding or a variable length coding
  • the shape of the encoded video block may be used to either decide which blocks to use for candidates, or decide the order in which to place the candidates in the list of candidates, or both.
  • a video decoding apparatus comprising a processor can be configured to implement a method recited with reference to methods 2200 or 2300.
  • a video encoding apparatus comprising a processor can be configured to implement a method recited with reference to methods 2200 or 2300.
  • a computer program product having computer code stored thereon, the code, when executed by a processor, causes the processor to implement a method described with reference to methods 2200 or 2300.
  • the disclosed techniques may be embodied in video encoders or decoders to improve compression efficiency when the coding units being compressed have shaped that are significantly different than the traditional square shaped blocks or rectangular blocks that are half-square shaped.
  • new coding tools that use long or tall coding units such as 4x32 or 32x4 sized units may benefit from the disclosed techniques.
  • the disclosed and other solutions, examples, embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them.
  • the disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus.
  • the computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them.
  • data processing apparatus encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers.
  • the apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
  • a propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
  • a computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program does not necessarily correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • the processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.
  • the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read only memory or a random-access memory or both.
  • the essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

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

La présente invention concerne un procédé de traitement de flux binaire vidéo qui consiste : à générer, pour un bloc vidéo qui est codé de façon intra, une liste de candidats de mode intra conformément à une première règle de dépendance de forme qui dépend d'une forme du bloc vidéo, et à utiliser la liste de candidats de mode intra pour reconstruire une représentation décodée du bloc vidéo. La règle de dépendance de forme peut également être étendue à des cas de codage inter pour fusionner une liste de candidats ou une liste de candidats de prédiction de vecteur de mouvement avancée.
PCT/IB2019/055569 2018-07-01 2019-07-01 Codage de mode amvp et mode de fusion dépendant de la forme WO2020008328A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862692805P 2018-07-01 2018-07-01
US62/692,805 2018-07-01

Publications (1)

Publication Number Publication Date
WO2020008328A1 true WO2020008328A1 (fr) 2020-01-09

Family

ID=67253941

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/IB2019/055565 WO2020008324A1 (fr) 2018-07-01 2019-07-01 Codage intra dépendant de la forme
PCT/IB2019/055569 WO2020008328A1 (fr) 2018-07-01 2019-07-01 Codage de mode amvp et mode de fusion dépendant de la forme

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/055565 WO2020008324A1 (fr) 2018-07-01 2019-07-01 Codage intra dépendant de la forme

Country Status (3)

Country Link
CN (2) CN110677679B (fr)
TW (2) TW202021344A (fr)
WO (2) WO2020008324A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024022145A1 (fr) * 2022-07-28 2024-02-01 Mediatek Inc. Procédé et appareil d'amvp avec mode de fusion pour codage vidéo

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021027774A1 (fr) 2019-08-10 2021-02-18 Beijing Bytedance Network Technology Co., Ltd. Signalisation dépendante de sous-images dans des flux de données vidéo
WO2021063420A1 (fr) 2019-10-02 2021-04-08 Beijing Bytedance Network Technology Co., Ltd. Signalisation de niveau de tranche dans des trains de bits vidéo qui comprennent des sous-images
CN114631317B (zh) 2019-10-18 2024-03-15 北京字节跳动网络技术有限公司 子图片的参数集信令中的语法约束
WO2021139806A1 (fr) * 2020-01-12 2021-07-15 Beijing Bytedance Network Technology Co., Ltd. Contraintes de codage et de décodage vidéo

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016091162A1 (fr) * 2014-12-09 2016-06-16 Mediatek Inc. Procédé de calcul de prédicteur de vecteur de mouvement ou de candidat à la fusion lors d'un codage vidéo
US20170332084A1 (en) * 2016-05-13 2017-11-16 Qualcomm Incorporated Neighbor based signaling of intra prediction modes
WO2018037896A1 (fr) * 2016-08-26 2018-03-01 シャープ株式会社 Appareil de décodage d'image, appareil de codage d'image, procédé de décodage d'image et procédé de codage d'image
US20180098064A1 (en) * 2016-10-04 2018-04-05 Qualcomm Incorporated Variable number of intra modes for video coding

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101365570B1 (ko) * 2007-01-18 2014-02-21 삼성전자주식회사 인트라 예측 부호화, 복호화 방법 및 장치
CN105120280B (zh) * 2010-07-20 2018-04-20 株式会社Ntt都科摩 图像预测编码装置及方法、图像预测解码装置及方法
US9247266B2 (en) * 2011-04-18 2016-01-26 Texas Instruments Incorporated Temporal motion data candidate derivation in video coding
EP2745519B1 (fr) * 2011-08-17 2017-09-27 MediaTek Singapore Pte Ltd. Procédé et appareil de prédiction intra utilisant des blocs non carrés
US9787982B2 (en) * 2011-09-12 2017-10-10 Qualcomm Incorporated Non-square transform units and prediction units in video coding
AU2013208472B2 (en) * 2012-01-13 2015-10-01 Sharp Kabushiki Kaisha Image decoding device, image encoding device, and data structure of encoded data
EP3334157B1 (fr) * 2015-08-04 2020-09-02 LG Electronics Inc. Procédé d'interprédiction, et dispositif, dans un système de codage vidéo
WO2017043786A1 (fr) * 2015-09-10 2017-03-16 엘지전자 주식회사 Procédé et dispositif de prédiction intra dans un système de codage vidéo

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016091162A1 (fr) * 2014-12-09 2016-06-16 Mediatek Inc. Procédé de calcul de prédicteur de vecteur de mouvement ou de candidat à la fusion lors d'un codage vidéo
US20170332084A1 (en) * 2016-05-13 2017-11-16 Qualcomm Incorporated Neighbor based signaling of intra prediction modes
WO2018037896A1 (fr) * 2016-08-26 2018-03-01 シャープ株式会社 Appareil de décodage d'image, appareil de codage d'image, procédé de décodage d'image et procédé de codage d'image
EP3506638A1 (fr) * 2016-08-26 2019-07-03 Sharp Kabushiki Kaisha Appareil de décodage d'image, appareil de codage d'image, procédé de décodage d'image et procédé de codage d'image
US20180098064A1 (en) * 2016-10-04 2018-04-05 Qualcomm Incorporated Variable number of intra modes for video coding

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"High Efficiency Video Coding (HEVC)", 23 August 2014, SPRINGER INTERNATIONAL PUBLISHING, ISBN: 978-3-319-06894-7, article BENJAMIN BROSS ET AL: "Inter-Picture Prediction in HEVC", pages: 113 - 140, XP055624540, DOI: 10.1007/978-3-319-06895-4__5 *
SEREGIN V ET AL: "Block shape dependent intra mode coding", 7. JVET MEETING; 13-7-2017 - 21-7-2017; TORINO; (THE JOINT VIDEO EXPLORATION TEAM OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://PHENIX.INT-EVRY.FR/JVET/, no. JVET-G0159, 16 July 2017 (2017-07-16), XP030150970 *
TAKEHARA H ET AL: "Non-CE9: Merging candidate reordering", 98. MPEG MEETING; 28-11-2011 - 2-12-2011; GENEVA; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11), no. m21738, 22 November 2011 (2011-11-22), pages 1-16, XP030050301 *
XU (HIKVISION) L ET AL: "CE4 related: Candidate list reordering", no. m42979, 3 July 2018 (2018-07-03), XP030195725, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/123_Ljubljana/wg11/m42979-JVET-K0065-v2-JVET-K0065_v2.zip JVET-K0065_v2.doc> [retrieved on 20180703] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024022145A1 (fr) * 2022-07-28 2024-02-01 Mediatek Inc. Procédé et appareil d'amvp avec mode de fusion pour codage vidéo

Also Published As

Publication number Publication date
TWI731361B (zh) 2021-06-21
CN110677678A (zh) 2020-01-10
CN110677678B (zh) 2022-09-23
TW202007153A (zh) 2020-02-01
TW202021344A (zh) 2020-06-01
WO2020008324A1 (fr) 2020-01-09
CN110677679A (zh) 2020-01-10
CN110677679B (zh) 2022-07-26

Similar Documents

Publication Publication Date Title
US11146785B2 (en) Selection of coded motion information for LUT updating
KR102147614B1 (ko) 비디오 코딩에서 아핀 모션 모델들을 위한 모션 벡터 예측
US11871023B2 (en) Multi-motion model based video coding and decoding
WO2020114404A1 (fr) Procédé d&#39;élagage dans un mode de prédiction différent
WO2020003279A1 (fr) Concept d&#39;utilisation d&#39;une ou de plusieurs tables de conversion pour mémoriser des informations de mouvement précédemment codées dans l&#39;ordre et les utiliser pour coder des blocs ultérieurs
WO2020003270A1 (fr) Nombre de candidats de mouvement dans une table de consultation à vérifier selon un mode
EP2984838B1 (fr) Prediction de synthese de vue vers l&#39;arriere
EP3791587A1 (fr) Réinitialisation de table de consultation par tranche/tuile/rangée de lcu
WO2020065517A1 (fr) Prédiction de vecteurs de mouvement basée sur l&#39;historique simplifié
WO2018119431A1 (fr) Détermination d&#39;échantillons voisins pour un filtrage bilatéral dans un décodage vidéo
WO2018119429A1 (fr) Dérivation d&#39;informations de filtre bilatéral sur la base d&#39;un mode de prédiction dans un décodage vidéo
CN110677679B (zh) 依赖形状的帧内编码
KR20160041841A (ko) 디스패리티 벡터 유도를 위한 화상들의 선택
WO2020008329A1 (fr) Compression de mouvement spatial
WO2020125628A1 (fr) Filtre d&#39;interpolation dépendant de la forme
WO2020143837A1 (fr) Amélioration du mmvd
WO2020012449A1 (fr) Ordre d&#39;interpolation dépendant de la forme
WO2020008322A1 (fr) Réduction de complexité de conception de fusion non adjacente

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19739399

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 28.04.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19739399

Country of ref document: EP

Kind code of ref document: A1