US20220109852A1 - Interaction between screen content coding tools and motion information - Google Patents

Interaction between screen content coding tools and motion information Download PDF

Info

Publication number
US20220109852A1
US20220109852A1 US17/551,392 US202117551392A US2022109852A1 US 20220109852 A1 US20220109852 A1 US 20220109852A1 US 202117551392 A US202117551392 A US 202117551392A US 2022109852 A1 US2022109852 A1 US 2022109852A1
Authority
US
United States
Prior art keywords
block
modified
motion information
mode
prediction
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
US17/551,392
Other languages
English (en)
Inventor
Jizheng Xu
Li Zhang
Weijia Zhu
Kai Zhang
Hongbin Liu
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
Assigned to BEIJING BYTEDANCE NETWORK TECHNOLOGY CO., LTD. reassignment BEIJING BYTEDANCE NETWORK TECHNOLOGY CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LIU, HONGBIN
Assigned to BYTEDANCE INC. reassignment BYTEDANCE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: XU, JIZHENG, ZHANG, KAI, ZHANG, LI, ZHU, WEIJIA
Publication of US20220109852A1 publication Critical patent/US20220109852A1/en
Pending legal-status Critical Current

Links

Images

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/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
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • H04N19/52—Processing of motion vectors by encoding by predictive encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding

Definitions

  • This patent document is directed generally to video coding and decoding technologies.
  • 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/High Efficiency Video Coding (HEVC) standards.
  • AVC H.264/MPEG-4 Advanced Video Coding
  • 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
  • embodiments of video encoders or decoders can handle virtual boundaries of coding tree blocks to provide better compression efficiency and simpler implementations of coding or decoding tools.
  • a method of video processing includes determining, during a conversion between a current video block of a video picture and a bitstream representation of the current video block, a block vector difference (BVD) representing a difference between a block vector corresponding to the current video block and a predictor thereof and performing the conversion between a current video block and a bitstream representation of the current video block using the block vector.
  • the block vector indicates a motion match for the current video block in the video picture and a modified value of the BVD is coded in the bitstream representation.
  • a method of video processing includes determining, during a conversion between a current video block of a video picture and a bitstream representation of the current video block, to use an intra block copy tool for the conversion and performing the conversion using a modified block vector predictor that corresponds to a modified value of a block vector difference (BVD) for the current video block.
  • VBD block vector difference
  • a method of video processing includes performing a conversion between a current video block of a video picture and a bitstream representation of the current video block using an intra block copy coding tool in which a modified block vector corresponding to a modified value of a block vector that is includes in the bitstream representation is used for the conversion.
  • a method of video processing includes determining, during a conversion between a current video block and a bitstream representation of the current video block, a weighting factor wt based on a condition of the current video block and performing the conversion using a combined intra-inter coding operation in which the weighting factor wt is used for weighting a motion vector of the current video block.
  • a method of video processing includes determining, to use a triangular partitioning mode (TPM) coding tool for a conversion between a current video block and a bitstream representation of the current video block, wherein at least one operational parameter of the TPM coding tool depends on a characteristic of the current video block, wherein the TPM coding tool partitions the current video block into two non-rectangular partitions that are separately coded and performing the conversion by applying the TPM coding tool that uses the one operational parameter.
  • TPM triangular partitioning mode
  • a method of video processing includes modifying, for a conversion between a block of a video and a bitstream representation of the block, at least one of motion information associated with the block which is coded with intra block copy (IBC) mode; and performing the conversion based on the modified motion information.
  • IBC intra block copy
  • a method of video processing includes determining, for a conversion between a block of a video and a bitstream representation of the block, a weighting factor for intra prediction signal in Combined intra-inter prediction (CIIP) mode based on a motion vector (MV) associated with the block; and performing the conversion based on the weighting factor.
  • CIIP Combined intra-inter prediction
  • a method of video processing includes determining, for a conversion between a block of a video and a bitstream representation of the block, weights used in Triangular prediction mode (TPM) mode based on motion information of one or more partitions of the block; and performing the conversion based on the weights.
  • TPM Triangular prediction mode
  • a method of video processing includes determining, for a conversion between a block of a video and a bitstream representation of the block, whether blending process is applied in Triangular prediction mode (TPM) mode based on transform information of the block; and performing the conversion based on the determination.
  • TPM Triangular prediction mode
  • a video encoding apparatus configured to perform an above-described method is disclosed.
  • a video decoder that is configured to perform an above-described method is disclosed.
  • a machine-readable medium stores code which, upon execution, causes a processor to implement one or more of the above-described methods.
  • FIG. 1 shows an example of Multi-type tree splitting modes.
  • FIG. 2 shows an example of Splitting flags signalling in quadtree with nested multi-type tree coding tree structure.
  • FIG. 3 shows an example of quadtree with nested multi-type tree coding block structure.
  • FIG. 4 shows an example of No TT split for 128 ⁇ 128 coding block.
  • FIG. 5 shows 67 intra prediction modes.
  • FIG. 6 shows example Locations of the samples used for the derivation of a and p.
  • FIG. 7 shows an example of example of four reference lines neighboring to a prediction block.
  • FIGS. 8A-8B show examples of sub-partitions for 4 ⁇ 8 and 8 ⁇ 4 CUs and examples of sub-partitions for CUs other than 4 ⁇ 8, 8 ⁇ 4 and 4 ⁇ 4, respectively.
  • FIG. 9 is an illustration of ALWIP for 4 ⁇ 4 blocks.
  • FIG. 10 is an illustration of ALWIP for 8 ⁇ 8 blocks.
  • FIG. 11 is an illustration of ALWIP for 8 ⁇ 4 blocks.
  • FIG. 12 is an illustration of ALWIP for 16 ⁇ 16 blocks.
  • FIG. 13 is an example of derivation process for merge candidates list construction.
  • FIG. 14 shows example positions of spatial merge candidates.
  • FIG. 15 show examples of candidate pairs considered for redundancy check of spatial merge candidates.
  • FIG. 16 shows examples of positions for the second PU of N ⁇ 2N and 2N ⁇ N partitions.
  • FIG. 17 is an illustration of motion vector scaling for temporal merge candidate.
  • FIG. 18 shows examples of candidate positions for temporal merge candidate, C0 and C1.
  • FIG. 19 shows an example of combined bi-predictive merge candidate.
  • FIG. 20 shows an example of derivation process for motion vector prediction candidates.
  • FIG. 21 is an illustration of motion vector scaling for spatial motion vector candidate.
  • FIG. 22A-22B show examples of 4-parameter affine model and 6-parameter affine model, respectively.
  • FIG. 23 shows an example of Affine MVF per sub-block.
  • FIG. 24 shows a coding flow example for history based motion vector prediction.
  • FIG. 25 shows an example of a merge candidate construction process.
  • FIG. 26 shows an example of triangular partition based inter prediction mode.
  • FIG. 27 shows an example of Ultimate Motion Vector Expression (UMVE) search.
  • UMVE Ultimate Motion Vector Expression
  • FIG. 28 shows examples of UMVE search points.
  • FIG. 29 is an illustration of intra block copy coding mode.
  • FIG. 30 shows an example of Top and left neighboring blocks used in CIIP weight derivation.
  • FIG. 31 shows partitioning of a video block.
  • FIG. 32 is a block diagram of an example apparatus for video processing.
  • FIG. 33 is a flowchart for an example method of video processing.
  • FIG. 34 is a flowchart for an example method of video processing.
  • FIG. 35 is a flowchart for an example method of video processing.
  • FIG. 36 is a flowchart for an example method of video processing.
  • FIG. 37 is a flowchart for an example method of video processing.
  • Section headings are used in the present document to facilitate ease of understanding and do not limit the embodiments disclosed in a section to only that section.
  • certain embodiments are described with reference to Versatile Video Coding or other specific video codecs, the disclosed techniques are applicable to other video coding technologies also.
  • video processing encompasses video coding or compression, video decoding or decompression and video transcoding in which video pixels are represented from one compressed format into another compressed format or at a different compressed bitrate.
  • This document is related to video coding technologies. Specifically, it is related to prediction block generation. 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 H.265/HEVC
  • 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
  • a CTU is split into CUs by using a quaternary-tree 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 leaf CU level.
  • Each leaf CU can be further split into one, two or four 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 leaf CU can be partitioned into transform units (TUs) according to another quaternary-tree structure similar to the coding tree for the CU.
  • TUs transform units
  • a quadtree with nested multi-type tree using binary and ternary splits segmentation structure replaces the concepts of multiple partition unit types, i.e. it removes the separation of the CU, PU and TU concepts except as needed for CUs that have a size too large for the maximum transform length, and supports more flexibility for CU partition shapes.
  • a CU can have either a square or rectangular shape.
  • a coding tree unit (CTU) is first partitioned by a quaternary tree (a.k.a. quadtree) structure. Then the quaternary tree leaf nodes can be further partitioned by a multi-type tree structure. As shown in FIG.
  • the multi-type tree leaf nodes are called coding units (CUs), and unless the CU is too large for the maximum transform length, this segmentation is used for prediction and transform processing without any further partitioning. This means that, in most cases, the CU, PU and TU have the same block size in the quadtree with nested multi-type tree coding block structure. The exception occurs when maximum supported transform length is smaller than the width or height of the colour component of the CU.
  • FIG. 2 illustrates the signalling mechanism of the partition splitting information in quadtree with nested multi-type tree coding tree structure.
  • a coding tree unit (CTU) is treated as the root of a quaternary tree and is first partitioned by a quaternary tree structure. Each quaternary tree leaf node (when sufficiently large to allow it) is then further partitioned by a multi-type tree structure.
  • CTU coding tree unit
  • a first flag (mtt_split_cu_flag) is signalled to indicate whether the node is further partitioned; when a node is further partitioned, a second flag (mtt_split_cu_vertical_flag) is signalled to indicate the splitting direction, and then a third flag (mtt_split_cu_binary_flag) is signalled to indicate whether the split is a binary split or a ternary split.
  • the multi-type tree slitting mode (MttSplitMode) of a CU is derived as shown in Table 1.
  • MttSplitMode derviation based on multi-type tree syntax elements MttSplitMode mtt_split_cu_vertical_flag mtt_split_cu_binary_flag SPLIT_TT_HOR 0 0 SPLIT_BT_HOR 0 1 SPLIT_TT_VER 1 0 SPLIT_BT_VER 1 1
  • FIG. 3 shows a CTU divided into multiple CUs with a quadtree and nested multi-type tree coding block structure, where the bold block edges represent quadtree partitioning and the remaining edges represent multi-type tree partitioning.
  • the quadtree with nested multi-type tree partition provides a content-adaptive coding tree structure comprised of CUs.
  • the size of the CU may be as large as the CTU or as small as 4 ⁇ 4 in units of luma samples. For the case of the 4:2:0 chroma format, the maximum chroma CB size is 64 ⁇ 64 and the minimum chroma CB size is 2 ⁇ 2.
  • the maximum supported luma transform size is 64 ⁇ 64 and the maximum supported chroma transform size is 32 ⁇ 32.
  • the width or height of the CB is larger the maximum transform width or height, the CB is automatically split in the horizontal and/or vertical direction to meet the transform size restriction in that direction.
  • CTU size the root node size of a quaternary tree
  • MinQTSize the minimum allowed quaternary tree leaf node size
  • MaxBtSize the maximum allowed binary tree root node size
  • MaxTtSize the maximum allowed ternary tree root node size
  • MaxMttDepth the maximum allowed hierarchy depth of multi-type tree splitting from a quadtree leaf
  • MinBtSize the minimum allowed binary tree leaf node size
  • MinTtSize the minimum allowed ternary tree leaf node size
  • the CTU size is set as 128 ⁇ 128 luma samples with two corresponding 64 ⁇ 64 blocks of 4:2:0 chroma samples
  • the MinQTSize is set as 16 ⁇ 16
  • the MaxBtSize is set as 128 ⁇ 128
  • MaxTtSize is set as 64 ⁇ 64
  • the MinBtSize and MinTtSize (for both width and height) is set as 4 ⁇ 4
  • the MaxMttDepth is set as 4.
  • the quaternary tree partitioning is applied to the CTU first to generate quaternary tree leaf nodes.
  • the quaternary tree leaf nodes may have a size from 16 ⁇ 16 (i.e., the MinQTSize) to 128 ⁇ 128 (i.e., the CTU size). If the leaf QT node is 128 ⁇ 128, it will not be further split by the binary tree since the size exceeds the MaxBtSize and MaxTtSize (i.e., 64 ⁇ 64). Otherwise, the leaf qdtree node could be further partitioned by the multi-type tree. Therefore, the quaternary tree leaf node is also the root node for the multi-type tree and it has multi-type tree depth (mttDepth) as 0. When the multi-type tree depth reaches MaxMttDepth (i.e., 4), no further splitting is considered.
  • TT split is forbidden when either width or height of a luma coding block is larger than 64, as shown in FIG. 4 .
  • TT split is also forbidden when either width or height of a chroma coding block is larger than 32.
  • the coding tree scheme supports the ability for the luma and chroma to have a separate block tree structure.
  • the luma and chroma CTBs in one CTU have to share the same coding tree structure.
  • the luma and chroma can have separate block tree structures.
  • luma CTB is partitioned into CUs by one coding tree structure
  • the chroma CTBs are partitioned into chroma CUs by another coding tree structure.
  • a CU in an I slice may consist of a coding block of the luma component or coding blocks of two chroma components, and a CU in a P or B slice always consists of coding blocks of all three colour components unless the video is monochrome.
  • VTM4 the number of directional intra modes in VTM4 is extended from 33, as used in HEVC, to 65.
  • the new directional modes not in HEVC are depicted as red dotted arrows in FIG. 5 , 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.
  • PDPC position dependent intra prediction combination
  • PDPC is an intra prediction method which invokes a combination of the un-filtered boundary reference samples and HEVC style intra prediction with filtered boundary reference samples.
  • PDPC is applied to the following intra modes without signaling: planar, DC, horizontal, vertical, bottom-left angular mode and its eight adjacent angular modes, and top-right angular mode and its eight adjacent angular modes.
  • the prediction sample pred(x,y) is predicted using an intra prediction mode (DC, planar, angular) and a linear combination of reference samples according to the equation as follows:
  • pred( x,y ) ( wL ⁇ R ⁇ 1,y +wT ⁇ R x, ⁇ 1 ⁇ wTL ⁇ R ⁇ 1, ⁇ 1 +(64 ⁇ wL ⁇ wT+wTL ) ⁇ pred( x,y )+32)>>6
  • R x, ⁇ 1 , R ⁇ 1,y represent the reference samples located at the top and left of current sample (x,y), respectively, and R ⁇ 1, ⁇ 1 represents the reference sample located at the top-left corner of the current block.
  • CCLM cross-component linear model
  • pred C (i,j) represents the predicted chroma samples in a CU and rec L (i,j) represents the downsampled reconstructed luma samples of the same CU.
  • Linear model parameter a and p are derived from the relation between luma values and chroma values from two samples, which are luma sample with minimum sample value and with maximum sample inside the set of downsampled neighboring luma samples, and their corresponding chroma samples.
  • FIG. 6 shows an example of the location of the left and above samples and the sample of the current block involved in the CCLM mode.
  • This parameter computation is performed as part of the decoding process, and is not just as an encoder search operation. As a result, no syntax is used to convey the a and p values to the decoder.
  • Chroma mode coding directly depends on the intra prediction mode of the corresponding luma block. Since separate block partitioning structure for luma and chroma components is enabled in I slices, one chroma block may correspond to multiple luma blocks. Therefore, for Chroma DM mode, the intra prediction mode of the corresponding luma block covering the center position of the current chroma block is directly inherited.
  • Multiple reference line (MRL) intra prediction uses more reference lines for intra prediction.
  • FIG. 7 an example of 4 reference lines is depicted, where the samples of segments A and F are not fetched from reconstructed neighbouring samples but padded with the closest samples from Segment B and E, respectively.
  • HEVC intra-picture prediction uses the nearest reference line (i.e., reference line 0).
  • reference line 0 2 additional lines (reference line 1 and reference line 3) are used.
  • the index of selected reference line (mrl_idx) is signalled and used to generate intra predictor. For reference line idx, which is greater than 0, only include additional reference line modes in MPM list and only signal mpm index without remaining mode.
  • the Intra Sub-Partitions (ISP) tool divides luma intra-predicted blocks vertically or horizontally into 2 or 4 sub-partitions depending on the block size. For example, minimum block size for ISP is 4 ⁇ 8 (or 8 ⁇ 4). If block size is greater than 4 ⁇ 8 (or 8 ⁇ 4) then the corresponding block is divided by 4 sub-partitions. FIG. 8A-8B show examples of the two possibilities. All sub-partitions fulfill the condition of having at least 16 samples.
  • reconstructed samples are obtained by adding the residual signal to the prediction signal.
  • a residual signal is generated by the processes such as entropy decoding, inverse quantization and inverse transform. Therefore, the reconstructed sample values of each sub-partition are available to generate the prediction of the next sub-partition, and each sub-partition is processed repeatedly.
  • the first sub-partition to be processed is the one containing the top-left sample of the CU and then continuing downwards (horizontal split) or rightwards (vertical split).
  • reference samples used to generate the sub-partitions prediction signals are only located at the left and above sides of the lines. All sub-partitions share the same intra mode.
  • Affine Linear Weighted Intra Prediction (ALWIP, a.k.a. Matrix Based Intra Prediction)
  • Affine linear weighted intra prediction (ALWIP, a.k.a. Matrix based intra prediction (MIP)) is proposed.
  • test 1 ALWIP is designed with a memory restriction of 8K bytes and at most 4 multiplications per sample.
  • Test 2 is similar to test 1, but further simplifies the design in terms of memory requirement and model architecture.
  • affine linear weighted intra prediction takes one line of H reconstructed neighbouring boundary samples left of the block and one line of W reconstructed neighbouring boundary samples above the block as input. If the reconstructed samples are unavailable, they are generated as it is done in the conventional intra prediction.
  • the generation of the prediction signal is based on the following three steps:
  • the matrices and offset vectors needed to generate the prediction signal are taken from three sets S 0 , S 1 , S 2 of matrices.
  • the set S 0 consists of 18 matrices A 0 i , i ⁇ 0, . . . , 17 ⁇ each of which has 16 rows and 4 columns and 18 offset vectors b 0 i , i ⁇ 0, . . . , 17 ⁇ each of size 16. Matrices and offset vectors of that set are used for blocks of size 4 ⁇ 4.
  • the set S 1 consists of 10 matrices A 1 i , i ⁇ 0, . . .
  • the set S 2 consists of 6 matrices A 2 i , i ⁇ 0, . . . , 5 ⁇ , each of which has 64 rows and 8 columns and of 6 offset vectors b 2 i , i ⁇ 0, . . . , 5 ⁇ of size 64. Matrices and offset vectors of that set or parts of these matrices and offset vectors are used for all other block-shapes.
  • the total number of multiplications needed in the computation of the matrix vector product is always smaller than or equal to 4 ⁇ W ⁇ H. In other words, at most four multiplications per sample are required for the ALWIP modes.
  • bdry red top and bdry red left both consists of 2 samples in the case of a 4 ⁇ 4-block and both consist of 4 samples in all other cases.
  • W red and H red are defined as:
  • the reduced prediction signal pred red is computed by calculating a matrix vector product and adding an offset:
  • pred red A ⁇ b dry red +b.
  • b is a vector of size W red ⁇ H red .
  • the matrix A and the vector b are taken from one of the sets S 0 , S 1 , S 2 as follows.
  • One defines an index idx idx(W,H) as follows:
  • FIGS. 9, 10, 11 and 12 The entire process of averaging, matrix vector multiplication and linear interpolation is illustrated for different shapes in FIGS. 9, 10, 11 and 12 . Note, that the remaining shapes are treated as in one of the depicted cases.
  • the transposed case is treated accordingly.
  • the procedure is essentially the same and it is easy to check that the number of multiplications per sample is less than four.
  • the output size is 32 and again, only horizontal interpolation remains to be performed.
  • the transposed cases are treated accordingly.
  • boundary samples used to be multiplied with the matrix may be referred as “reduced boundary samples”.
  • boundary samples used to interpolate the final prediction block from the down-sampled block may be referred as “upsampling boundary samples”.
  • the prediction signal arises from the reduced prediction signal pred red on W red ⁇ H red by linear interpolation.
  • linear interpolation is done in vertical, horizontal or both directions. If linear interpolation is to be applied in both directions, it is first applied in horizontal direction if W ⁇ H and it is first applied in vertical direction, else.
  • a flag indicating if an ALWIP mode is to be applied on the corresponding Prediction Unit (PU) or not is sent in the bitstream.
  • the signalization of the latter index is harmonized with MRL. If an ALWIP mode is to be applied, the index predmode of the ALWIP mode is signaled using a MPM-list with 3 MPMS.
  • the derivation of the MPMs is performed using the intra-modes of the above and the left PU as follows.
  • predmode ALWIP map_angular_to_alwip idx [predmode Angular ].
  • idx ( PU ) idx ( W,H ) ⁇ 0,1,2 ⁇
  • the above PU belongs to the same CTU as the current PU and is in intra mode and if a conventional intra prediction mode predmode Angular above is applied on the above PU, one puts
  • three fixed default lists list idx , idx ⁇ 0,1,2 ⁇ are provided, each of which contains three distinct ALWIP modes.
  • the default list list idx(PU) and the modes mode ALWIP above and mode ALWIP left one constructs three distinct MPMs by substituting ⁇ 1 by default values as well as eliminating repetitions.
  • the left neighbouring block and above neighbouring block used in the ALWIP MPM list construction is A1 and B1.
  • the proposed ALWIP-modes are harmonized with the MPM-based coding of the conventional intra-prediction modes as follows.
  • the luma and chroma MPM-list derivation processes for the conventional intra-prediction modes uses fixed tables map_alwip_to_angular idx , idx ⁇ 0,1,2 ⁇ , mapping an ALWIP-mode predmode ALWIP on a given PU to one of the conventional intra-prediction modes
  • predmode Angular map_alwip_to_angular idx(PU) [predmode ALWIP ].
  • CUs For inter-coded coding units (CUs), it may be coded with one prediction unit (PU), 2 PUs according to partition mode.
  • 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_pred_idc.
  • 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 differences (MVD) 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 a 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.
  • Bi-prediction 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.
  • inter prediction is used to denote prediction derived from data elements (e.g., sample values or motion vectors) of reference pictures other than the current decoded picture.
  • data elements e.g., sample values or motion vectors
  • a picture can be predicted from multiple reference pictures.
  • the reference pictures that are used for inter prediction are organized in one or more reference picture lists.
  • the reference index identifies which of the reference pictures in the list should be used for creating the prediction signal.
  • a single reference picture list, List 0 is used for a P slice and two reference picture lists, List 0 and List 1 are used for B slices. It should be noted reference pictures included in List 0/1 could be from past and future pictures in terms of capturing/display order.
  • steps are also schematically depicted in FIG. 13 .
  • For spatial merge candidate derivation a maximum of four merge candidates are selected among candidates that are located in five different positions.
  • temporal merge candidate derivation a maximum of one merge candidate is selected among two candidates. Since constant number of candidates for each PU is assumed at decoder, additional candidates are generated when the number of candidates obtained from step 1 does not reach the maximum number of merge candidate (MaxNumMergeCand) which is signalled in slice header. Since the number of candidates is constant, index of best merge candidate is encoded using truncated unary binarization (TU). If the size of CU is equal to 8, all the PUs of the current CU share a single merge candidate list, which is identical to the merge candidate list of the 2N ⁇ 2N prediction unit.
  • TU truncated unary binarization
  • a maximum of four merge candidates are selected among candidates located in the positions depicted in FIG. 14 .
  • the order of derivation is A 1 , B 1 , B 0 , A 0 and B 2 .
  • Position B 2 is considered only when any PU of position A 1 , B 1 , B 0 , A 0 is not available (e.g. because it belongs to another slice or tile) or is intra coded.
  • candidate at position A 1 is added, the addition of the remaining candidates is subject to a redundancy check which ensures that candidates with same motion information are excluded from the list so that coding efficiency is improved.
  • a redundancy check which ensures that candidates with same motion information are excluded from the list so that coding efficiency is improved.
  • not all possible candidate pairs are considered in the mentioned redundancy check. Instead only the pairs linked with an arrow in FIG.
  • FIG. 16 depicts the second PU for the case of N ⁇ 2N and 2N ⁇ N, respectively.
  • candidate at position A 1 is not considered for list construction. In fact, by adding this candidate will lead to two prediction units having the same motion information, which is redundant to just have one PU in a coding unit.
  • position B 1 is not considered when the current PU is partitioned as 2N ⁇ N.
  • 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 dotted 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.
  • the position for the temporal candidate is selected between candidates C 0 and C 1 , as depicted in FIG. 18 . If PU at position C 0 is not available, is intra coded, or is outside of the current coding tree unit (CTU aka. LCU, largest coding unit) row, position C 1 is used. Otherwise, position C 0 is used in the derivation of the temporal merge candidate.
  • CTU current coding tree unit
  • LCU largest coding unit
  • 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.
  • Zero motion candidates are inserted to fill the remaining entries in the merge candidates list and therefore hit the MaxNumMergeCand capacity. These candidates have zero spatial displacement and a reference picture index which starts from zero and increases every time a new zero motion candidate is added to the list. Finally, no redundancy check is performed on these candidates.
  • 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. 20 ). In the following sections, details about derivation process of motion vector prediction candidate are provided.
  • FIG. 20 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. 20 .
  • 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.
  • a maximum of two candidates are considered among five potential candidates, which are derived from PUs located in positions as depicted in FIG. 16 , those positions being the same as those of motion merge.
  • the order of derivation for the left side of the current PU is defined as A 0 , A 1 , and scaled A 0 , scaled A 1 .
  • the order of derivation for the above side of the current PU is defined as B 0 , B 1 , B 2 , scaled B 0 , scaled B 1 , scaled B 2 .
  • the no-spatial-scaling cases are checked first followed by the spatial scaling. Spatial scaling is considered when the POC is different between the reference picture of the neighbouring PU and that of the current PU regardless of reference picture list. If all PUs of left candidates are not available or are intra coded, scaling for the above motion vector is allowed to help parallel derivation of left and above MV candidates. Otherwise, spatial scaling is not allowed for the above motion vector.
  • the motion vector of the neighbouring PU is scaled in a similar manner as for temporal scaling, as depicted as FIG. 21 .
  • 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.
  • AMVR Adaptive Motion Vector difference Resolution
  • MMVD Merge with Motion Vector Differences
  • TPM Triangular prediction mode
  • CIIP Combined intra-inter prediction
  • GBI Generalized Bi-Prediction
  • DMVR Decoder-side Motion Vector Refinement
  • BIO Bi-directional Optical flow
  • Quad-Tree/Binary Tree/Ternary-Tree (QT/BT/TT) structure is adopted to divide a picture into square or rectangle blocks.
  • separate tree (a.k.a. Dual coding tree) is also adopted in VVC for I-frames.
  • VVC VVC
  • the coding block structure are signaled separately for the luma and chroma components.
  • the CU is set equal to PU and TU, except for blocks coded with a couple of specific coding methods (such as intra sub-partition prediction wherein PU is equal to TU, but smaller than CU, and sub-block transform for inter-coded blocks wherein PU is equal to CU, but TU is smaller than PU).
  • specific coding methods such as intra sub-partition prediction wherein PU is equal to TU, but smaller than CU, and sub-block transform for inter-coded blocks wherein PU is equal to CU, but TU is smaller than PU).
  • HEVC high definition motion model
  • MCP motion compensation prediction
  • a simplified affine transform motion compensation prediction is applied with 4-parameter affine model and 6-parameter affine model.
  • FIG. 22 the affine motion field of the block is described by two control point motion vectors (CPMVs) for the 4-parameter affine model and 3 CPMVs for the 6-parameter affine model.
  • CPMVs control point motion vectors
  • the motion vector field (MVF) of a block is described by the following equations with the 4-parameter affine model (wherein the 4-parameter are defined as the variables a, b, e and f) in equation (1) and 6-parameter affine model (wherein the 4-parameter are defined as the variables a, b, c, d, e and f) in equation (2) respectively:
  • control point motion vectors (CPMV)
  • (x, y) represents the coordinate of a representative point relative to the top-left sample within current block
  • (mv h (x,y), mv v (x,y)) is the motion vector derived for a sample located at (x, y).
  • the CP motion vectors may be signaled (like in the affine AMVP mode) or derived on-the-fly (like in the affine merge mode).
  • w and h are the width and height of the current block.
  • the division is implemented by right-shift with a rounding operation.
  • the representative point is defined to be the center position of a sub-block, e.g., when the coordinate of the left-top corner of a sub-block relative to the top-left sample within current block is (xs, ys), the coordinate of the representative point is defined to be (xs+2, ys+2).
  • the representative point is utilized to derive the motion vector for the whole sub-block.
  • sub-block based affine transform prediction is applied.
  • the motion vector of the center sample of each sub-block is calculated according to Equation (1) and (2), and rounded to 1/16 fraction accuracy.
  • the motion compensation interpolation filters for 1/16-pel are applied to generate the prediction of each sub-block with derived motion vector.
  • the interpolation filters for 1/16-pel are introduced by the affine mode.
  • the high accuracy motion vector of each sub-block is rounded and saved as the same accuracy as the normal motion vector.
  • HMVP history-based motion vector prediction
  • HMVP the previously coded motion information is stored.
  • the motion information of a previously coded block is defined as an HMVP candidate.
  • Multiple HMVP candidates are stored in a table, named as the HMVP table, and this table is maintained during the encoding/decoding process on-the-fly.
  • the HMVP table is emptied when starting coding/decoding a new tile/LCU row/a slice. Whenever there is an inter-coded block and non-sub-block, non-TPM mode, the associated motion information is added to the last entry of the table as a new HMVP candidate.
  • the overall coding flow is depicted in FIG. 24 .
  • Step 1 Derivation of spatial candidates
  • Step 4 default motion candidates
  • HMVP candidates could be used in both AMVP and merge candidate list construction processes.
  • FIG. 25 depicts a modified merge candidate list construction process (highlighted in blue).
  • HMVP candidates stored in the HMVP table could be utilized to fill in the merge candidate list.
  • the HMVP candidates in the table are inserted in a descending order of indices. The last entry in the table is firstly added to the list, while the first entry is added in the end. Similarly, redundancy removal is applied on the HMVP candidates. Once the total number of available merge candidates reaches the maximal number of merge candidates allowed to be signaled, the merge candidate list construction process is terminated.
  • HMVP table contains up to 5 regular motion candidates and each of them is unique.
  • TPM Triangular Prediction Mode
  • VTM4 a triangle partition mode is supported for inter prediction.
  • the triangle partition mode is only applied to CUs that are 8 ⁇ 8 or larger and are coded in merge mode but not in MMVD or CIIP mode.
  • a CU-level flag is signalled to indicate whether the triangle partition mode is applied or not.
  • a CU When this mode is used, a CU is split evenly into two triangle-shaped partitions, using either the diagonal split or the anti-diagonal split, as depicted in FIG. 26 .
  • Each triangle partition in the CU is inter-predicted using its own motion; only uni-prediction is allowed for each partition, that is, each partition has one motion vector and one reference index.
  • the uni-prediction motion constraint is applied to ensure that same as the conventional bi-prediction, only two motion compensated prediction are needed for each CU.
  • the CU-level flag indicates that the current CU is coded using the triangle partition mode
  • a flag indicating the direction of the triangle partition (diagonal or anti-diagonal)
  • two merge indices (one for each partition) are further signalled.
  • the sample values along the diagonal or anti-diagonal edge are adjusted using a blending processing with adaptive weights. This is the prediction signal for the whole CU and transform and quantization process will be applied to the whole CU as in other prediction modes.
  • the motion field of a CU predicted using the triangle partition mode is stored in 4 ⁇ 4 units.
  • the regular merge candidate list is re-used for triangle partition merge prediction with no extra motion vector pruning. For each merge candidate in the regular merge candidate list, one and only one of its L0 or L1 motion vector is used for triangle prediction. In addition, the order of selecting the L0 vs. L1 motion vector is based on its merge index parity. With this scheme, the regular merge list can be directly used.
  • UMVE Ultimate motion vector expression
  • MMVD Motion vector expression
  • UMVE re-uses merge candidate as same as those included in the regular merge candidate list in VVC.
  • a base candidate can be selected, and is further expanded by the proposed motion vector expression method.
  • UMVE provides a new motion vector difference (MVD) representation method, in which a starting point, a motion magnitude and a motion direction are used to represent a MVD.
  • MVD motion vector difference
  • This proposed technique uses a merge candidate list as it is. But only candidates which are default merge type (MRG_TYPE_DEFAULT_N) are considered for UMVE's expansion.
  • Base candidate index defines the starting point.
  • Base candidate index indicates the best candidate among candidates in the list as follows.
  • Base candidate IDX Base candidate IDX 0 1 2 3 N th MVP 1 st MVP 2 nd MVP 3 rd MVP 4 th MVP
  • Base candidate IDX is not signaled.
  • Distance index is motion magnitude information.
  • Distance index indicates the pre-defined distance from the starting point information. Pre-defined distance is as follows:
  • Direction index represents the direction of the MVD relative to the starting point.
  • the direction index can represent of the four directions as shown below.
  • UMVE flag is signaled right after sending a skip flag or merge flag. If skip or merge flag is true, UMVE flag is parsed. If UMVE flag is equal to 1, UMVE syntaxes are parsed. But, if not 1, AFFINE flag is parsed. If AFFINE flag is equal to 1, that is AFFINE mode, But, if not 1, skip/merge index is parsed for VTM's skip/merge mode.
  • either the first or the second merge candidate in the merge candidate list could be selected as the base candidate.
  • UMVE is also known as Merge with MV Differences (MMVD).
  • Multi-hypothesis prediction is proposed, wherein combined 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 For luma component, the intra candidate list is derived from only one intra prediction mode, i.e., planar mode.
  • the weights applied to the prediction block from intra and inter prediction are determined by the coded mode (intra or non-intra) of two neighboring blocks (A1 and B1).
  • sub-block merge candidate list The sub-block related motion candidates are put in a separate merge list is named as ‘sub-block merge candidate list’.
  • the sub-block merge candidate list includes ATMVP candidate and affine merge candidates.
  • the sub-block merge candidate list is filled with candidates in the following order:
  • ATMVP Ka Sub-Block Temporal Motion Vector Predictor
  • ATMVP Basic idea of ATMVP is to derive multiple sets of temporal motion vector predictors for one block. Each sub-block is assigned with one set of motion information. When an ATMVP merge candidate is generated, the motion compensation is done in 8 ⁇ 8 level instead of the whole block level.
  • HMVP candidates Similar to the AMVP design in HEVC, up to 2 AMVP candidates may be derived. However, the HMVP candidates may also be added after the TMVP candidate.
  • the HMVP candidates in the HMVP table are traversed in an ascending order of index (i.e., from index equal to 0, the oldest one). Up to 4 HMVP candidates may be checked to find whether its reference picture is the same as the target reference picture (i.e., same POC value).
  • MVDs motion vector differences
  • AMVR locally adaptive motion vector resolution
  • MVD can be coded in units of quarter luma samples, integer luma samples or four luma samples (i.e., 1 ⁇ 4-pel, 1-pel, 4-pel).
  • the MVD resolution is controlled at the coding unit (CU) level, and MVD resolution flags are conditionally signalled for each CU that has at least one non-zero MVD components.
  • a first flag is signalled to indicate whether quarter luma sample MV precision is used in the CU.
  • the first flag (equal to 1) indicates that quarter luma sample MV precision is not used, another flag is signalled to indicate whether integer luma sample MV precision or four luma sample MV precision is used.
  • the quarter luma sample MV resolution is used for the CU.
  • the MVPs in the AMVP candidate list for the CU are rounded to the corresponding precision.
  • Symmetric motion vector difference (SMVD) is applied for motion information coding in bi-prediction.
  • variables RefIdxSymL0 and RefIdxSymL1 to indicate the reference picture index of list 0/1 used in SMVD mode, respectively, are derived with the following steps as specified in N1001-v2.
  • SMVD mode shall be disabled.
  • a Multiple Transform Selection (MTS) scheme is used for residual coding both inter and intra coded blocks. It uses multiple selected transforms from the DCT8/DST7.
  • the newly introduced transform matrices are DST-VII and DCT-VIII. Table shows the basis functions of the selected DST/DCT.
  • the transform matrices are quantized more accurately than the transform matrices in HEVC.
  • the transform matrices are quantized more accurately than the transform matrices in HEVC.
  • MTS In order to control MTS scheme, separate enabling flags are specified at SPS level for intra and inter, respectively.
  • a CU level flag is signalled to indicate whether MTS is applied or not.
  • MTS is applied only for luma.
  • the MTS CU level flag is signalled when the following conditions are satisfied.
  • MTS CU flag is equal to zero, then DCT2 is applied in both directions. However, if MTS CU flag is equal to one, then two other flags are additionally signalled to indicate the transform type for the horizontal and vertical directions, respectively.
  • Transform and signalling mapping table as shown in Table 6.
  • 8-bit primary transform cores are used. Therefore, all the transform cores used in HEVC are kept as the same, including 4-point DCT-2 and DST-7, 8-point, 16-point and 32-point DCT-2. Also, other transform cores including 64-point DCT-2, 4-point DCT-8, 8-point, 16-point, 32-point DST-7 and DCT-8, use 8-bit primary transform cores.
  • the residual of a block can be coded with transform skip mode.
  • the transform skip flag is not signalled when the CU level MTS_CU_flag is not equal to zero.
  • Transform skip is enabled when both block width and height are equal to or less than 4.
  • Intra block copy (IBC), a.k.a. current picture referencing, has been adopted in HEVC Screen Content Coding extensions (HEVC-SCC) and the current VVC test model (VTM-4.0).
  • IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding.
  • the current block is predicted by a reference block in the same picture when IBC is applied. The samples in the reference block must have been already reconstructed before the current block is coded or decoded.
  • IBC is not so efficient for most camera-captured sequences, it shows significant coding gains for screen content. The reason is that there are lots of repeating patterns, such as icons and text characters in a screen content picture.
  • an inter-coded coding unit can apply IBC if it chooses the current picture as its reference picture.
  • the MV is renamed as block vector (BV) in this case, and a BV always has an integer-pixel precision.
  • BV block vector
  • the current picture is marked as a “long-term” reference picture in the Decoded Picture Buffer (DPB).
  • DPB Decoded Picture Buffer
  • the prediction can be generated by copying the reference block.
  • the residual can be got by subtracting the reference pixels from the original signals.
  • transform and quantization can be applied as in other coding modes.
  • the whole reference block should be with the current coding tree unit (CTU) and does not overlap with the current block. Thus, there is no need to pad the reference or prediction block.
  • the IBC flag is coded as a prediction mode of the current CU. Thus, there are totally three prediction modes, MODE_INTRA, MODE_INTER and MODE_IBC for each CU.
  • IBC merge mode an index pointing to an entry in the IBC merge candidates list is parsed from the bitstream.
  • the construction of the IBC merge list can be summarized according to the following sequence of steps:
  • Step 1 Derivation of spatial candidates
  • a maximum of four merge candidates are selected among candidates located in the positions depicted in A 1 , B 1 , B 0 , A 0 and B 2 as depicted in FIG. 14 in order of derivation is A 1 , B 1 , B 0 , A 0 and B 2 .
  • Position B 2 is considered only when any PU of position A 1 , B 1 , B 0 , A 0 is not available (e.g. because it belongs to another slice or tile) or is not coded with IBC mode.
  • the insertion of the remaining candidates is subject to a redundancy check which ensures that candidates with same motion information are excluded from the list so that coding efficiency is improved.
  • IBC candidates from HMVP table may be inserted. Redundancy check are performed when inserting the HMVP candidates. Finally, pairwise average candidates are inserted into the IBC merge list.
  • the merge candidate When a reference block identified by a merge candidate is outside of the picture, or overlaps with the current block, or outside of the reconstructed area, or outside of the valid area restricted by some constrains, the merge candidate is called invalid merge candidate.
  • invalid merge candidates may be inserted into the IBC merge list.
  • IBC AMVP mode an AMVP index point to an entry in the IBC AMVP list is parsed from the bitstream.
  • the construction of the IBC AMVP list can be summarized according to the following sequence of steps:
  • Step 1 Derivation of spatial candidates
  • IBC candidates from HMVP table may be inserted.
  • the motion compensation in the chroma IBC mode is performed at sub block level.
  • the chroma block will be partitioned into several sub blocks. Each sub block determines whether the corresponding luma block has a block vector and the validity if it is present.
  • There is encoder constrain in the current VTM where the chroma IBC mode will be tested if all sub blocks in the current chroma CU have valid luma block vectors. For example, on a YUV 420 video, the chroma block is N ⁇ M and then the collocated luma region is 2N ⁇ 2M.
  • the sub block size of a chroma block is 2 ⁇ 2. There are several steps to perform the chroma my derivation then the block copy process.
  • the IBC mode is allowed at the encoder when all sub blocks find a valid bv.
  • the decoding process of an IBC block is listed below.
  • the part related to chroma my derivation in a IBC mode is highlighted as grey.
  • 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 ibc prediction mode consists of the following ordered steps:
  • the BV predictors for merge mode and AMVP mode in IBC will share a common predictor list, which consist of the following elements:
  • the number of candidates in the list is controlled by a variable derived from the slice header. For merge mode, up to first 6 entries of this list will be used; for AMVP mode, the first 2 entries of this list will be used. And the list conforms with the shared merge list region requirement (shared the same list within the SMR).
  • the luma motion vector mvL is derived by the following ordered steps:
  • mvIdx general_merge_flag[ xCb ][ yCb ]?merge_ idx [ xCb ][ yCb ]: mvp _10_flag[ xCb ][ yCb ] (8-916)
  • the ancestor node is named merge sharing node.
  • the shared merging candidate list is generated at the merge sharing node pretending the merge sharing node is a leaf CU.
  • VTM5 supports quantized residual differential pulse coded modulation (RDPCM) for screen content coding.
  • RPCM residual differential pulse coded modulation
  • a flag is transmitted at the CU level if the CU size is smaller than or equal to 32 ⁇ 32 luma samples and if the CU is intra coded. This flag indicates whether regular intra coding or RDPCM is used. If RDPCM is used, a RDPCM prediction direction flag is transmitted to indicate whether the prediction is horizontal or vertical. Then, the block is predicted using the regular horizontal or vertical intra prediction process with unfiltered reference samples. The residual is quantized and the difference between each quantized residual and its predictor, i.e. the previously coded residual of the horizontal or vertical (depending on the RDPCM prediction direction) neighbouring position, is coded.
  • r i,j For a block of size M (height) ⁇ N (width), let r i,j , 0 ⁇ i ⁇ M ⁇ 1, 0 ⁇ j ⁇ N ⁇ 1 be the prediction residual.
  • Q(r i,j ), 0 ⁇ i ⁇ M ⁇ 1, 0 ⁇ j ⁇ N ⁇ 1 denote the quantized version of the residual r i,j .
  • RDPCM is applied to the quantized residual values, resulting in a modified M ⁇ N array ⁇ tilde over (R) ⁇ with elements ⁇ tilde over (r) ⁇ i,j , where ⁇ tilde over (r) ⁇ i,j is predicted from its neighboring quantized residual value.
  • vertical RDPCM prediction mode for 0 ⁇ j ⁇ (N ⁇ 1), the following is used to derive ⁇ tilde over (r) ⁇ i,j :
  • the inverse quantized residuals, Q ⁇ 1 (Q(r i,j )), are added to the intra block prediction values to produce the reconstructed sample values.
  • the predicted quantized residual values ⁇ tilde over (r) ⁇ i,j are sent to the decoder using the same residual coding process as that in transform skip mode residual coding.
  • the first MPM intra mode is associated with the current CU and used for intra mode coding of the chroma blocks of the current CU and subsequent CUs. For deblocking, if both blocks on the sides of a block boundary are coded using RDPCM, then that particular block boundary is not deblocked.
  • VTM5 when a CU is coded in merge mode, if the CU contains at least 64 luma samples (that is, CU width times CU height is equal to or larger than 64), and if both CU width and CU height are less than 128 luma samples, an additional flag is signalled to indicate if the combined inter/intra prediction (CIIP) mode is applied to the current CU.
  • the CIIP prediction combines an inter prediction signal with an intra prediction signal.
  • the inter prediction signal in the CIIP mode P inter is derived using the same inter prediction process applied to regular merge mode; and the intra prediction signal P intra is derived following the regular intra prediction process with the planar mode.
  • the intra and inter prediction signals are combined using weighted averaging, where the weight value is calculated depending on the coding modes of the top and left neighbouring blocks (depicted in FIG. 30 ) as follows:
  • the CIIP prediction is formed as follows:
  • the current VVC design may have the following problems:
  • block vector represents the motion vector which points to a reference block within the same picture.
  • IBC represents a coding method which utilize the information of samples (filtered or un-filtered) in the same picture. For example, if one block is coded with two reference pictures, one of them is the current picture and the other not, in such case, it may be also classified to be coded with the IBC mode.
  • MVx and MVy as the horizontal and vertical components of a motion vector (MV); MVDx and MVDy as the horizontal and vertical components of a motion vector difference (MVD); BVx and BVy as the horizontal and vertical components of a block vector (BV); BVPx and BVPy as the horizontal and vertical components of a block vector predictor (BVP); BVDx and BVDy as the horizontal and vertical components of a block vector different (BVD).
  • CBx and CBy stand for the position of a block relative to the upper-left position of a picture; W and H stand for the width and height of the block.
  • (x, y) denotes a sample relative to the upper-left position of a block.
  • Floor(t) is the largest integer no larger than t.
  • FIG. 32 is a block diagram of a video processing apparatus 3200 .
  • the apparatus 3200 may be used to implement one or more of the methods described herein.
  • the apparatus 3200 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and so on.
  • the apparatus 3200 may include one or more processors 3202 , one or more memories 3204 and video processing hardware 3206 .
  • the processor(s) 3202 may be configured to implement one or more methods described in the present document.
  • the memory (memories) 3204 may be used for storing data and code used for implementing the methods and techniques described herein.
  • the video processing hardware 3206 may be used to implement, in hardware circuitry, some techniques described in the present document.
  • the video coding methods may be implemented using an apparatus that is implemented on a hardware platform as described with respect to FIG. 32 .
  • FIG. 33 is a flowchart of an example method 3300 of video processing.
  • the method includes determining ( 3302 ), during a conversion between a current video block of a video picture and a bitstream representation of the current video block, a block vector difference (BVD) representing a difference between a block vector corresponding to the current video block and a predictor thereof, wherein the block vector indicates a motion match for the current video block in the video picture; and wherein a modified value of the BVD is coded in the bitstream representation; and performing ( 3304 ) the conversion between a current video block and a bitstream representation of the current video block using the block vector.
  • the predictor of the BVD may be computed during the conversion based on one or more previous block vectors used for conversion of previous video blocks.
  • a method of video processing comprising: determining, during a conversion between a current video block of a video picture and a bitstream representation of the current video block, a block vector difference (BVD) representing a difference between a block vector corresponding to the current video block and a predictor thereof, wherein the block vector indicates a motion match for the current video block in the video picture; and wherein a modified value of the BVD is coded in the bitstream representation; and performing the conversion between a current video block and a bitstream representation of the current video block using the block vector.
  • a block vector difference representing a difference between a block vector corresponding to the current video block and a predictor thereof, wherein the block vector indicates a motion match for the current video block in the video picture
  • a modified value of the BVD is coded in the bitstream representation
  • a method of video processing comprising: determining, during a conversion between a current video block of a video picture and a bitstream representation of the current video block, to use an intra block copy tool for the conversion; and performing the conversion using a modified block vector predictor that corresponds to a modified value of a block vector difference (BVD) for the current video block.
  • VBD block vector difference
  • a method of video processing comprising: performing a conversion between a current video block of a video picture and a bitstream representation of the current video block using an intra block copy coding tool in which a modified block vector corresponding to a modified value of a block vector that is includes in the bitstream representation is used for the conversion.
  • a method of video processing comprising: determining, during a conversion between a current video block and a bitstream representation of the current video block, a weighting factor wt based on a condition of the current video block; and performing the conversion using a combined intra-inter coding operation in which the weighting factor wt is used for weighting a motion vector of the current video block.
  • a method of video processing comprising: determining, to use a triangular partitioning mode (TPM) coding tool for a conversion between a current video block and a bitstream representation of the current video block, wherein at least one operational parameter of the TPM coding tool depends on a characteristic of the current video block, wherein the TPM coding tool partitions the current video block into two non-rectangular partitions that are separately coded; and performing the conversion by applying the TPM coding tool that uses the one operational parameter.
  • TPM triangular partitioning mode
  • a video encoding apparatus comprising a processor configured to implement a method recited in any one or more of the above solutions.
  • a video decoding apparatus comprising a processor configured to implement a method recited in any one or more of the above solutions.
  • a machine readable medium having stored code for implementing one or more of the above methods by a processor.
  • FIG. 34 is a flowchart of an example method 3400 of video processing.
  • the method includes modifying ( 3402 ), for a conversion between a block of a video and a bitstream representation of the block, at least one of motion information associated with the block which is coded with intra block copy (IBC) mode; and performing ( 3404 ) the conversion based on the modified motion information.
  • IBC intra block copy
  • the motion information includes a block vector difference (BVD) representing a difference between a block vector for the block and a block vector predictor for the block, and the modified BVD is coded in the bitstream representation.
  • VBD block vector difference
  • a vertical component BVDy of the BVD is modified to (BVDy+BH), wherein BH is a constant.
  • BH is 128 or ⁇ 128.
  • BH is the height of a coding tree unit (CTU) of the block or minus the height of a CTU.
  • BH depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • a horizontal component BVDx of the BVD is modified to (BVDy+BW), wherein BW is a constant.
  • BW is 128 or ⁇ 128.
  • BW is 128*128/S, wherein S is (coding tree unit (CTU) size or coding tree block (CTB) size), or minus 128*128/S(CTU size or CTB size).
  • CTU code division multiplexer
  • CTB coding tree block
  • BW depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • the modification is performed for certain BVD value set BVDS1, and is not performed for certain BVD value set BVDS2, and a syntax is signaled for all other BVD values to indicate whether the modification is applied or not.
  • whether to and/or how to modify BVD depend on the sign and/or magnitude of the difference.
  • BVDy when BVDy>BH/2, BVDy is modified to (BVDy ⁇ BH).
  • BVDy when BVDy ⁇ BH/2, BVDy is modified to (BVDy+BH).
  • BVDx when BVDx>BW/2, BVDx is modified to (BVDx ⁇ BW).
  • BVDx when BVDx ⁇ BH/2, BVDx is modified to (BVDx+BW).
  • the motion information includes block vector predictors (BVPs) for the block and the modified BVPs are used for decoding the block.
  • BVPs block vector predictors
  • the modified BVPs are used together with signalled block vector differences (BVDs) to derive final block vector (BV) for the block in an Advanced motion vector prediction (AMVP) mode, wherein BVD represents a difference between a BV for the block and a BVP for the block.
  • VBD signalled block vector differences
  • the modified BVPs are directly used as final BV for the block in a merge mode.
  • a vertical component BVPy of the BVP is modified to (BVPy+BH), wherein BH is a constant.
  • BH is 128 or ⁇ 128.
  • BH is the height of a coding tree unit (CTU) of the block or minus the height of a CTU.
  • BH depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • a horizontal component BVPx of the BVP is modified to (BVPy+BW), wherein BW is a constant.
  • BW is 128 or ⁇ 128.
  • BW is 128*128/S, wherein S is coding tree unit (CTU) size or coding tree block (CTB) size, or minus 128*128/S.
  • CTU coding tree unit
  • CTB coding tree block
  • BW depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • the modification is performed for certain BVP value set BVPS1, and is not performed for certain BVP value set BVPS2, and a syntax is signaled for all other BVP values to indicate whether the modification is applied or not.
  • whether to and/or how to modify BVP depend on the sign and/or magnitude of the BVP.
  • the motion information includes decoded block vectors (BVs) for IBC mode and the modified BVs are used to identify reference blocks for sample copying.
  • BVs decoded block vectors
  • a vertical component BVy of the BV is modified to (BVy+BH) when BVy is used, wherein BH is a constant.
  • BH is 128 or ⁇ 128.
  • BH is the height of a coding tree unit (CTU) or a coding tree block (CTB) of the block or minus the height of a CTU or a CTB.
  • CTU coding tree unit
  • CTB coding tree block
  • BH depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • a horizontal component BVx of the BV is modified to (BVy+BW) when BVx is used, wherein BW is a constant.
  • BW is 128 or ⁇ 128.
  • BW is 128*128/(coding tree unit (CTU) size or coding tree block (CTB) size), or minus 128*128/(CTU size or CTB size).
  • BW depends on the block dimension and/or block position and/or IBC reference region sizes of the block.
  • a motion vector after the modifications needs to be valid.
  • a valid motion vector corresponds to a prediction block not overlapped with the block.
  • a valid motion vector corresponds to a prediction block inside a current picture.
  • a valid motion vector corresponds to a prediction block with all samples reconstructed.
  • the modified BVs are stored and used for motion prediction or/and deblocking.
  • whether to and/or how to modify BVs depend on magnitude of at least one component of the BV.
  • BVy when (CBy+BVy)/(CTU or CTB height) ⁇ CBy/(CTU or CTB height), BVy is modified to (BVy+(CTU or CTB height)), CBx and CBy representing a position of a block relative to the upper-left position of a picture.
  • BVy when (CBy+W+BVy)/(CTU/CTB height)>CBy/(CTU/CTB height), BVy is modified to (BVy ⁇ (CTU/CTB height)), CBx and CBy representing a position of a block relative to the upper-left position of a picture, W and H representing the width and height of the block.
  • BVx when (BVx, BVy) is invalid, BVx is modified to (BVx+BW) if block vector (BVx ⁇ BW, BVy) is valid, where BVy is unmodified or modified vertical component.
  • BVx when (BVx, BVy) is invalid, BVx is modified to (BVx+BW) if block vector (BVx+BW, BVy) is valid, where BVy is unmodified or modified vertical component.
  • the modifications for different components follow a predetermined order.
  • the modification to BVDx is before modification to BVDy.
  • the modification to BVy is before modification to BVx.
  • motion vector predictors associated with the block are formed based on the modified BV or BVD.
  • history-based motion vector prediction is based on the modified BV or BVD.
  • merge candidates are based on the modified BV or BVD.
  • Advanced motion vector prediction is based on the modified BV or BVD.
  • the constants BW and BH are predefined, or signalled in at least one of SPS, PPS, Slice, Tile group, Tile, Brick and CTU level.
  • the modification is disabled when the block is located on at least one of picture boundary, Slice boundary and Tile group boundary.
  • BH is set to 0.
  • BW is set to 0.
  • FIG. 35 is a flowchart of an example method 3500 of video processing.
  • the method includes determining ( 3502 ), for a conversion between a block of a video and a bitstream representation of the block, a weighting factor for intra prediction signal in Combined intra-inter prediction (CIIP) mode based on a motion vector (MV) associated with the block; and wherein a modified value of the BVD is coded in the bitstream representation; and performing ( 3504 ) the conversion based on the weighting factor.
  • CIIP Combined intra-inter prediction
  • the weighting factor for intra prediction signal is set to 1.
  • the weighting factor for intra prediction signal is set to 1.
  • FIG. 36 is a flowchart of an example method 3600 of video processing.
  • the method includes determining ( 3602 ), for a conversion between a block of a video and a bitstream representation of the block, weights used in Triangular prediction mode (TPM) mode based on motion information of one or more partitions of the block; and performing ( 3604 ) the conversion based on the weights.
  • TPM Triangular prediction mode
  • the block is split into an upper-right partition and a bottom-left partition by using anti-diagonal split or is split into an upper-left partition and a bottom-right partition by using diagonal split, and the block has a width W and a height H.
  • the weights are determined depending on whether one or multiple components of motion vector (MV) associated with one partition is equal to 0, wherein the components of the MV include a horizontal component MVx and a vertical component MVy.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 0.
  • the weights are set to 1.
  • the weights are set to 0.
  • the weights are set to 0.
  • FIG. 37 is a flowchart of an example method 3700 of video processing.
  • the method includes determining ( 3702 ), for a conversion between a block of a video and a bitstream representation of the block, whether blending process is applied in Triangular prediction mode (TPM) mode based on transform information of the block; and performing ( 3704 ) the conversion based on the determination.
  • TPM Triangular prediction mode
  • the blending process is not applied.
  • the blending process is not applied.
  • the blending process is applied.
  • the prediction sample of partition X of the block is generated only using motion information of the partition X, wherein X is 0 or 1.
  • whether to enable the modification or the determination depend on at least one of the following:
  • the conversion generates the block of video from the bitstream representation.
  • the conversion generates the bitstream representation from the block of video.
  • Implementations of the subject matter and the functional operations described in this patent document can be implemented in various systems, digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-transitory 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 of them.
  • data processing unit or “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 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 specification 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 nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices.
  • 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)
  • Compression Or Coding Systems Of Tv Signals (AREA)
US17/551,392 2019-06-16 2021-12-15 Interaction between screen content coding tools and motion information Pending US20220109852A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CNPCT/CN2019/091446 2019-06-16
CN2019091446 2019-06-16
PCT/CN2020/096129 WO2020253650A1 (en) 2019-06-16 2020-06-15 Interaction between screen content coding tools and motion information

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/096129 Continuation WO2020253650A1 (en) 2019-06-16 2020-06-15 Interaction between screen content coding tools and motion information

Publications (1)

Publication Number Publication Date
US20220109852A1 true US20220109852A1 (en) 2022-04-07

Family

ID=74037548

Family Applications (1)

Application Number Title Priority Date Filing Date
US17/551,392 Pending US20220109852A1 (en) 2019-06-16 2021-12-15 Interaction between screen content coding tools and motion information

Country Status (3)

Country Link
US (1) US20220109852A1 (zh)
CN (1) CN113966612A (zh)
WO (1) WO2020253650A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11470339B2 (en) * 2013-08-27 2022-10-11 Qualcomm Incorporated Residual prediction for intra block copying
WO2024081315A1 (en) * 2022-10-11 2024-04-18 Comcast Cable Communications, Llc Block vector difference (bvd) indication with reduced overhead

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10375416B1 (en) * 2018-09-05 2019-08-06 Tencent America LLC Segment types in video coding
US20210152833A1 (en) * 2019-05-16 2021-05-20 Huawei Technologies Co., Ltd. Encoder, a decoder and corresponding methods using intra block copy (ibc) dedicated buffer and default value refreshing for luma and chroma component
US20220014775A1 (en) * 2019-05-02 2022-01-13 Xris Corporation Method for encoding/decoding video signal and device therefor

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105208396B (zh) * 2014-06-20 2019-01-15 联想(北京)有限公司 一种视频帧的编码及解码方法和装置
US10306240B2 (en) * 2015-06-08 2019-05-28 Vid Scale, Inc. Intra block copy mode for screen content coding

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10375416B1 (en) * 2018-09-05 2019-08-06 Tencent America LLC Segment types in video coding
US20220014775A1 (en) * 2019-05-02 2022-01-13 Xris Corporation Method for encoding/decoding video signal and device therefor
US20210152833A1 (en) * 2019-05-16 2021-05-20 Huawei Technologies Co., Ltd. Encoder, a decoder and corresponding methods using intra block copy (ibc) dedicated buffer and default value refreshing for luma and chroma component

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11470339B2 (en) * 2013-08-27 2022-10-11 Qualcomm Incorporated Residual prediction for intra block copying
WO2024081315A1 (en) * 2022-10-11 2024-04-18 Comcast Cable Communications, Llc Block vector difference (bvd) indication with reduced overhead

Also Published As

Publication number Publication date
CN113966612A (zh) 2022-01-21
WO2020253650A1 (en) 2020-12-24

Similar Documents

Publication Publication Date Title
US11095917B2 (en) Affine inheritance method in intra block copy mode
US20220086447A1 (en) Combined intra and intra-block copy prediction for video coding
US20220086441A1 (en) Intra block copy with triangular partitions
WO2020244569A1 (en) Conditional implementation of motion candidate list construction process
US20220094927A1 (en) Sub-block based intra block copy
JP7318099B2 (ja) ビデオコーディングにおける変換ブロック・サイズ制約
US11758143B2 (en) Motion vector handling in geometry partition mode
WO2020003281A1 (en) Video bitstream processing using an extended merge mode and signaled motion information of a block
WO2020244660A1 (en) Motion candidate list construction for video coding
US20220109852A1 (en) Interaction between screen content coding tools and motion information
US20220086484A1 (en) History-based motion vector prediction with default parameters
US11863771B2 (en) Updating of history based motion vector prediction tables
WO2021155862A1 (en) Bv list construction process of ibc blocks under merge estimation region
WO2020182187A1 (en) Adaptive weight in multi-hypothesis prediction in video coding
WO2021000883A1 (en) Storage of motion information in history-based motion vector prediction table

Legal Events

Date Code Title Description
AS Assignment

Owner name: BYTEDANCE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:XU, JIZHENG;ZHANG, LI;ZHU, WEIJIA;AND OTHERS;REEL/FRAME:058396/0643

Effective date: 20200525

Owner name: BEIJING BYTEDANCE NETWORK TECHNOLOGY CO., LTD., CHINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LIU, HONGBIN;REEL/FRAME:058396/0804

Effective date: 20200525

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER