Improvements to deblocking filtering

Abstract

A method of video processing is described, comprising determining, for a conversion between a current video block of a video and a bitstream representation of the video, the applicability of an intra-sub-partitioning (ISP) mode according to rules that are independent of a maximum and / or minimum transform size of the current video block; and performing the conversion based on the determination.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 110490, filed on October 10, 2019, in a timely manner under applicable patent law and / or under the Paris Convention. The entire disclosure of the aforementioned application is incorporated by reference as a part of the disclosure of this application for all purposes under law. Technical Field

[0003] This patent document relates to video encoding and decoding. Background Art

[0004] Despite advances in video compression, digital video still consumes the largest amount of bandwidth on the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video usage is expected to continue to grow. Summary of the Invention

[0005] In apparatus, systems and methods related to digital video coding and decoding, particularly video and image coding and decoding, inter-frame prediction is used with triangular or arbitrary geometric partitioning of video blocks.

[0006] In one example aspect, a method of video processing is disclosed. The method includes performing a conversion between a current video block of a video and a bitstream representation of the video according to a rule, wherein a partitioned prediction mode is used for encoding or decoding the current video block, wherein a final prediction of the current video is determined as a weighted sum of two or more predictions of the current video block; wherein the partitioned prediction mode is a first mode based on a plurality of first partitioning schemes or a second mode based on a plurality of second partitioning schemes; and wherein the rule specifies a codec operation for encoding or decoding using the first mode or the second mode.

[0007] In another example aspect, another method of video processing is disclosed. The method includes performing a conversion between a current video block of a video and a bitstream representation of the video, wherein during the conversion, a prediction of the current video block is determined as a weighted sum of two or more predictions of the current video block, and a motion vector storage process for the current video block is determined according to a rule, wherein the current video block uses a partition prediction mode, the partition prediction mode being a first mode based on a plurality of first partitioning schemes or a second mode based on a plurality of second partitioning schemes, and wherein the rule specifies that a process for determining which motion vector to store and how many motion vectors to store is the same for either the first mode or the second mode.

[0008] In one example aspect, a method of video processing is disclosed. The method includes performing a conversion between a current block of video and a bitstream representation of the video, wherein, during the conversion, motion information of a 4x4 unit is used to determine a prediction block for the current block, and wherein the current block is encoded using a partitioned mode.

[0009] In one example aspect, a method of video processing is disclosed. The method includes performing a conversion between a current block of video and a bitstream representation of the video, wherein the current block is encoded or decoded using a partitioning mode, wherein during the conversion, a prediction block for the current block is determined by blending two or more predictions from a mixed region of the current video block according to a rule, and wherein the rule specifies storing an L0 motion vector and an L1 motion vector for subblocks belonging to the mixed region of the current video block.

[0010] In one example aspect, a method of video processing is disclosed. The method includes: for converting between a current video block of a video and a bitstream representation of the video, making a determination to apply a deblocking process to a boundary within the current video block based on rules resulting from using a partitioned prediction mode for the current video block; and performing the converting based on the determination, wherein using the partitioned prediction mode includes determining a final prediction for the current video block as a weighted sum of two or more predictions for the current video block.

[0011] In one example aspect, a method of video processing is disclosed. The method includes: for converting between a current video block of a video and a bitstream representation of the video, determining whether and / or how to apply a deblocking process to the current video block based on a type of partitioned prediction mode for the current video block; and performing the conversion based on the determination, wherein using the partitioned prediction mode includes determining a final prediction for the current video block as a weighted sum of two or more predictions for the current video block.

[0012] In one example aspect, a method of video processing is disclosed, comprising: determining, for a conversion between a current video block of a video and a bitstream representation of the video, applicability of an intra sub-partitioning (ISP) mode according to a rule that is independent of a maximum and / or minimum transform size of the current video block; and performing the conversion based on the determination.

[0013] In one example aspect, a method of video processing is disclosed, comprising: determining, for a conversion between a current video block of a video and a bitstream representation of the video, to apply an intra sub-partitioning (ISP) mode because a size of the current video block is greater than a maximum transform size applicable to the current video block; and performing the conversion based on the determination.

[0014] In one example aspect, a method of video processing is disclosed. The method includes: for converting between a current video block of a video and a bitstream representation of the video, determining to apply a combined inter- and intra-prediction (CIIP) mode or a partitioning mode to the current video block because a size of the current video block is greater than or equal to 128; and performing the conversion based on the determination.

[0015] In one example aspect, a method of video processing is disclosed. The method includes performing a conversion between a current video block and a bitstream representation of the video, wherein the bitstream representation conforms to a format rule that specifies information included in the bitstream representation based on a size of the current video block.

[0016] In one example aspect, a method of video processing is disclosed. The method includes performing a conversion between a current video block and a bitstream representation of the video, wherein the bitstream representation conforms to a format rule that specifies omitting a syntax element indicating use of an intra block copy (IBC) prediction mode from the bitstream representation if a width and / or height of the current video block is equal to or greater than X, where X is an integer.

[0017] In one example aspect, a method of video processing is disclosed. The method includes: for converting between a video including a plurality of color components and a bitstream representation of the video, determining a deblocking parameter offset to be used in a deblocking process for each component according to a rule; and performing the conversion based on the determination, wherein the rule specifies that the deblocking parameter offset is different at a picture level and / or a slice level for each component of the video.

[0018] In one example aspect, a method of video processing is disclosed. The method includes: for converting between chroma video blocks of a video and a bitstream representation of the video, deriving chroma deblocking parameters based on a chroma quantization parameter (QP) determined according to a rule, wherein the chroma video blocks belong to a codec unit and a slice; and performing the conversion based on the chroma deblocking parameters, wherein the rule specifies that the chroma QP is based on a picture-level chroma QP offset and a codec-unit-level chroma QP offset for the chroma video blocks, but is independent of a slice-level chroma QP offset.

[0019] In yet another representative aspect, the above method is implemented in the form of processor-executable code and stored in a computer-readable program medium.

[0020] In another representative aspect, a device configured or operable to perform the above method is disclosed. The device may include a processor programmed to implement the method.

[0021] In yet another representative aspect, a video decoder device may implement a method as described herein.

[0022] The above and other aspects and features of the disclosed technology are described in more detail in the drawings, the description, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 Example locations of spatial merge candidates are shown.

[0024] Figure 2 An example of candidate pairs for redundancy check considering spatial merge candidates is shown.

[0025] Figure 3 It is a diagram of the motion vector scaling of the time domain Merge candidate.

[0026] Figure 4 Examples of candidate positions of time-domain merge candidates (C0 and C1) are shown.

[0027] Figure 5 An example of inter prediction based on triangle partitioning is shown.

[0028] Figure 6 An example of uni-prediction MV selection for triangle partitioning mode is shown.

[0029] Figure 7 shows an example of the weights used in the blending process.

[0030] Figure 8 An example of weights used in the mixing process for an 8x16 TPM block (WD6) is shown.

[0031] Figure 9 Example weight settings for an 8x16 TPM prediction block are shown.

[0032] Figure 10 is a block diagram of an example video processing system in which the disclosed technology may be implemented.

[0033] Figure 11 is a block diagram of an example implementation of a hardware platform for video processing.

[0034] Figure 12 is a flow chart of an example method of video processing.

[0035] Figure 13A An example of TPM design in VTM6.0 is shown.

[0036] Figure 13B A proposed example of a TPM design is shown.

[0037] Figure 14 An example of a GEO partition boundary description is shown.

[0038] Figure 15AAn example of 32 angle schemes for angle quantization of the geometric Merge mode is shown.

[0039] Figure 15B An example of 24 angle schemes for angle quantization of the geometric Merge mode is shown.

[0040] Figure 16 is a block diagram illustrating an example video encoding and decoding system.

[0041] Figure 17 is a block diagram illustrating an encoder according to some embodiments of the disclosed technology.

[0042] Figure 18 is a block diagram illustrating a decoder according to some embodiments of the disclosed technology.

[0043] Figure 19 A flowchart illustrating an example method of video processing based on some implementations of the disclosed technology is shown.

[0044] Figure 20A and 20B A flowchart illustrating an example method of video processing based on some implementations of the disclosed technology is shown.

[0045] Figures 21A to 21E A flowchart illustrating an example method of video processing based on some implementations of the disclosed technology is shown. DETAILED DESCRIPTION

[0046] Embodiments of the disclosed technology can be applied to existing video codec standards (e.g., HEVC, H.265) and future standards to improve compression performance. Section headings are used in this document to improve the readability of the description and do not in any way limit the discussion or embodiments (and / or implementations) to only the individual sections.

[0047] 1. Summary

[0048] This document is related to video codec technology. Specifically, it is about inter-frame prediction and related techniques in video codecs. It can be applied to existing video codec standards (such as HEVC) or to standards to be finalized (Universal Video Codec). It may also be applicable to future video codec standards or video codecs.

[0049] 2. Preliminary Discussion

[0050] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. 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 standard, the H.264 / MPEG-4 Advanced Video Codec (AVC) standard, and the H.265 / HEVC standard. Starting with H.262, video codec standards have been based on a hybrid video codec architecture that utilizes temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software named the Joint Exploration Model (JEM). JVET meetings are held simultaneously every quarter, and the new codec standard aims to reduce bitrates by 50% compared to HEVC. The new video codec standard was officially named the Versatile Video Codec (VVC) at the JVET meeting in April 2018, and the first version of the VVC Test Model (VTM) was released at that time. As part of the ongoing efforts to promote VVC standardization, new codec technologies have been incorporated into the VVC standard at each JVET meeting. The VVC working draft and test model (VTM) are updated after each meeting. The VVC project's current goal is to complete the technical requirements (FDIS) at the July 2020 meeting.

[0051] 2.1 Extended Merge Prediction

[0052] In VTM, the Merge candidate list is constructed by including the following five types of candidates in order:

[0053] 1) Airspace MVP from airspace adjacent CU

[0054] 2) Time-domain MVP from co-located CU

[0055] 3) History-based MVP from FIFO table

[0056] 4) Paired Average MVP

[0057] 5) Zero MV.

[0058] The size of the merge list is signaled in the slice header, and the maximum allowed size of the merge list in the VTM is 6. For each CU code in Merge mode, the index of the best merge candidate is encoded using truncated unary binarization (TU). The first bin of the merge index is coded using context, while bypass coding is used for other bins.

[0059] This session provides the generation process for each category of Merge candidates.

[0060] 2.1.1 Derivation of airspace candidates

[0061] The derivation of spatial merge candidates in VVC is the same as that in HEVC. Figure 1 A maximum of four Merge candidates are selected from the candidates at the positions shown in . The derivation order is A0, B0, B1, A1, and B2. Position B2 is considered only when any CU at position A0, B0, B1, A1 is unavailable (for example, because it belongs to another slice or piece) or when intra coding is performed. After adding the candidate at position A1, the addition of the remaining candidates is subject to redundancy check to ensure that candidates with the same motion information are excluded from the list, thereby improving coding efficiency. In order to reduce computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Instead, only the candidates at Figure 2 The pairs are linked by arrows in , and a candidate is added to the list only if the corresponding candidates used for redundancy checking do not have the same motion information.

[0062] 2.1.2 Derivation of Time Domain Candidates

[0063] In this step, only one candidate is added to the list. In particular, in the derivation of the temporal Merge candidate, the scaled motion vector is derived based on the co-located CU belonging to the co-located reference picture. The reference picture list to be used for co-located CU derivation is explicitly signaled in the slice header. Figure 3 As shown by the dotted line in , a scaled motion vector for the temporal merge candidate is obtained, which is scaled from the motion vector of the collocated CU using the POC distance, tb, and td, where tb is defined as the POC difference between the reference picture of the current picture and the current picture, and td is defined as the POC difference between the reference picture of the collocated picture and the collocated picture. The reference picture index of the temporal merge candidate is set equal to zero.

[0064] Figure 3 It is a diagram of the motion vector scaling of the time domain Merge candidate.

[0065] like Figure 4 As shown in , the position of the temporal candidate is selected between candidates C0 and C1. If the CU at position C0 is not available, is intra-coded, or is outside the current row of the CTU, position C1 is used. Otherwise, position C0 is used in the derivation of the temporal merge candidate.

[0066] Figure 4 Examples of candidate positions of time-domain merge candidates (C0 and C1) are shown.

[0067] 2.1.3 History-based Merge Candidate Export

[0068] After spatial MVP and TMVP, history-based MVP (HMVP) merge candidates are added to the merge list. In this method, the motion information of previously coded blocks is stored in a table and used as the MVP of the current CU. A table with multiple HMVP candidates is maintained during the encoding / decoding process. The table is reset (cleared) when a new CTU row is encountered. Whenever there is a non-sub-block inter-coded CU, the associated motion information is added to the last entry of the table as a new HMVP candidate.

[0069] In the VTM, the HMVP table size S is set to 6, which means that up to 6 history-based MVP (HMVP) candidates can be added to the table. When a new motion candidate is inserted into the table, a constrained first-in-first-out (FIFO) rule is used, where a redundancy check is first applied to find whether there is an identical HMVP in the table. If found, the identical HMVP is removed from the table, and all subsequent HMVP candidates are moved forward.

[0070] HMVP candidates can be used in the Merge candidate list construction process. The latest HMVP candidates in the list are checked in order and inserted into the candidate list after the TMVP candidate. Redundancy check is applied to HMVP candidates in spatial or temporal Merge candidates.

[0071] In order to reduce the number of redundant check operations, the following simplifications are introduced:

[0072] 1. Set the number of HMVP candidates for merge list generation to (N<=4) × M:(8–N), where N indicates the number of existing candidates in the merge list and M indicates the number of HMVP candidates available in the table.

[0073] 2. Once the total number of available Merge candidates reaches the maximum allowed Merge candidate minus 1, the HMVP Merge candidate list construction process terminates.

[0074] 2.1.4 Pairwise Average Merge Candidate Export

[0075] Pairwise average candidates are generated by averaging predefined candidate pairs in the existing merge candidate list. The predefined pairs are defined as {(0,1),(0,2),(1,2),(0,3),(1,3),(2,3)}, where the number represents the merge index of the merge candidate list. The average motion vector is calculated separately for each reference list. If two motion vectors are available in a list, they are averaged even if they point to different reference pictures. If only one motion vector is available, it is used directly; if no motion vector is available, the list is invalidated.

[0076] When the merge list is incomplete after adding pairwise average merge candidates, zero MVPs are inserted at the end until the maximum number of merge candidates is encountered.

[0077] 2.2 Triangle Partitioning for Inter-frame Prediction

[0078] In VTM, triangle partitioning mode (TPM) is supported for inter prediction. Triangle partitioning mode is only applied to CUs of 64 samples or larger, and is encoded or decoded in skip or merge mode instead of regular merge mode, MMVD mode, CIIP mode, or sub-block merge mode. A CU-level flag is used to indicate whether triangle partitioning mode is applied.

[0079] When using this mode, use diagonal or anti-diagonal partitioning ( Figure 5 ) The CU is evenly divided into two triangular partitions. Each triangular partition in the CU uses its own motion for inter-frame prediction. Each partition only allows unidirectional prediction, that is, each partition has one motion vector and one reference index. Unidirectional prediction motion constraints are applied to ensure that, as with conventional bidirectional prediction, only two motion-compensated predictions are required for each CU. The unidirectional prediction motion of each partition is directly derived from the Merge candidate list constructed by extending the merge prediction in 2.1, and the unidirectional prediction motion is selected from the given Merge candidate in the list according to the process in 2.2.1.

[0080] Figure 5 An example of inter prediction based on triangle partitioning is shown.

[0081] If the triangle partitioning mode is used for the current CU, a flag indicating the triangle partitioning (diagonal or anti-diagonal) and two Merge indices (one for each partition) are further signaled. After predicting each triangle partition, a blending process with adaptive weights is used to adjust the sample values ​​along the diagonal or anti-diagonal edges. This is the prediction signaling for the entire CU, and like other prediction modes, the transform and quantization process will be applied to the entire CU. Finally, the motion field of the CU predicted using the triangle partitioning mode is stored in 4x4 units, as in 2.2.3.

[0082] 2.2.1 One-way prediction candidate list construction

[0083] Given a Merge candidate index, the unidirectional prediction motion vector is derived from the Merge candidate list constructed for extended merge prediction using the process in 2.1, such as Figure 6 As shown. For the candidates in the list, the candidate's LX motion vector is used as the unidirectional prediction motion vector for the triangle partitioning mode, where X is equal to the parity of the Merge candidate index value. These motion vectors are Figure 6 In the case where there is no corresponding LX motion vector, the L(1-X) motion vector of the same candidate in the extended merge prediction candidate list is used as the unidirectional prediction motion vector of the triangle partition mode.

[0084] 2.2.2 Blending along triangle split edges

[0085] After predicting each triangle segmentation using its own motion, blending is applied to the two prediction signals to derive samples around diagonal or anti-diagonal edges. The following weights are used in the blending process:

[0086] ·like Figure 7 As shown, the luminance is {7 / 8, 6 / 8, 5 / 8, 4 / 8, 3 / 8, 2 / 8, 1 / 8}, and the chrominance is {6 / 8, 4 / 8, 2 / 8}.

[0087] Figure 7 shows an example of the weights used in the blending process.

[0088] 2.2.3 Motion Field Storage

[0089] The motion vectors of a CU coded in triangle partitioning mode are stored in 4x4 units. Depending on the location of each 4x4 unit, a unidirectional prediction or bidirectional prediction motion vector is stored. Mv1 and Mv2 are denoted as the unidirectional prediction motion vectors for partition 1 and partition 2, respectively. If the 4x4 unit is located at Figure 7If the 4x4 cell is in a non-weighted region as shown in the example of , then Mv1 or Mv2 is stored for that 4x4 cell. Otherwise, if the 4x4 cell is in a weighted region, then a bi-directionally predicted motion vector is stored. The bi-directionally predicted motion vector is derived from Mv1 and Mv2 according to the following process:

[0090] 1) If Mv1 and Mv2 are from different reference picture lists (one from L0 and the other from L1), then Mv1 and Mv2 are simply combined to form a bi-directional prediction motion vector.

[0091] 2) Otherwise, if Mv1 and Mv2 are from the same list, and without loss of generality, they are both assumed to be from L0. In this case,

[0092] 2.a) If the reference picture of Mv2 (or Mv1) is present in L1, then the Mv2 (or Mv1) is converted into an L1 motion vector using the reference picture in L1. The two motion vectors are then combined to form a bi-directionally predicted motion vector.

[0093] Otherwise, instead of bidirectional predicted motion, only unidirectional predicted motion Mv1 is stored.

[0094] 2.3 Triangle Segmentation Specifications in VVC WD6

[0095] The following specification of the deblocking filter process is extracted from the latest VVC working draft JVET-O2001-vE.

[0096] 2.3.1 Merge Data Syntax

[0097]

[0098] 2.3.2 Merge Data Semantics

[0099] ciip_flag[x0][y0] specifies whether combined inter-picture merge and intra-picture prediction is applied to the current codec unit. The array index x0, y0 specifies the position (x0, y0) of the top-left luma sample of the considered codec block relative to the top-left luma sample of the picture.

[0100] When ciip_flag[x0][y0] is not present, the inference is as follows:

[0101] – ciip_flag[x0][y0] is inferred to be equal to 1 if all of the following are true:

[0102] –sps_ciip_enabled_flag is equal to 1.

[0103] –general_merge_flag[x0][y0] is equal to 1.

[0104] –merge_subblock_flag[x0][y0] is equal to 0.

[0105] –regular_merge_flag[x0][y0] is equal to 0.

[0106] –cbWidth is less than 128.

[0107] –cbHeight is less than 128.

[0108] –cbWidth*cbHeight is greater than or equal to 64.

[0109] – Otherwise, ciip_flag[x0][y0] is inferred to be equal to 0.

[0110] When ciip_flag[x0][y0] is equal to 1, the variable IntraPredModeY[x][y] is set equal to INTRA_PLANAR, where x = x0..x0 + cbWidth-1 and y = y0..y0 + cbHeight-1.

[0111] The variable MergeTriangleFlag[x0][y0] specifies whether to use triangle-based motion compensation to generate prediction samples for the current codec unit. When decoding B slices, the variable MergeTriangleFlag[x0][y0] is derived as follows:

[0112] – Set MergeTriangleFlag[x0][y0] equal to 1 if all of the following are true:

[0113] –sps_triangle_enabled_flag is equal to 1.

[0114] –slice_type is equal to B.

[0115] –general_merge_flag[x0][y0] is equal to 1.

[0116] –MaxNumTriangleMergeCand is greater than or equal to 2.

[0117] –cbWidth*cbHeight is greater than or equal to 64.

[0118] –regular_merge_flag[x0][y0] is equal to 0.

[0119] –merge_subblock_flag[x0][y0] is equal to 0.

[0120] –ciip_flag[x0][y0] is equal to 0.

[0121] – Otherwise, set MergeTriangleFlag[x0][y0] equal to 0.

[0122] merge_triangle_split_dir[x0][y0] specifies the split direction of the Merge triangle mode. The array index x0, y0 specifies the position (x0, y0) of the upper left luma sample of the considered codec block relative to the upper left luma sample of the picture.

[0123] When merge_triangle_split_dir[x0][y0] is not present, it is inferred to be equal to 0.

[0124] merge_triangle_idx0[x0][y0] specifies the first Merge candidate index of the triangle-shaped motion compensation candidate list, where x0, y0 specify the position (x0, y0) of the upper left luma sample of the considered codec block relative to the upper left luma sample of the picture.

[0125] When merge_triangle_idx0[x0][y0] is not present, it is inferred to be equal to 0.

[0126] merge_triangle_idx1[x0][y0] specifies the second Merge candidate index of the triangle-shaped motion compensation candidate list, where x0, y0 specify the position (x0, y0) of the upper left luma sample of the considered codec block relative to the upper left luma sample of the picture.

[0127] When merge_triangle_idx1[x0][y0] is not present, it is inferred to be equal to 0.

[0128] 2.3.3 Derivation Process of Triangle Motion Vector Components and Reference Index

[0129] 2.3.3.1 Overview

[0130] The inputs to this process are:

[0131] – The luminance position (xCb, yCb) of the upper left sample of the current luminance codec block relative to the upper left luminance sample of the current picture,

[0132] – The variable cbWidth specifies the width of the current codec block in luminance samples.

[0133] –The variable cbHeight specifies the height of the current codec block in luma samples.

[0134] The output of this process is:

[0135] – Luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy,

[0136] – Chroma motion vectors mvCA and mvCB with 1 / 32 fractional sample accuracy,

[0137] – reference indexes refIdxA and refIdxB,

[0138] –Prediction list flags predListFlagA and predListFlagB.

[0139] Call the derivation process of the luma motion vector for the triangle Merge mode specified in clause 2.3.3.2, with the luma position (xCb, yCb), variables cbWidth and cbHeight as input, and the output being the luma motion vectors mvA, mvB, reference indices refIdxA, refIdxB and prediction list flags predListFlagA and predListFlagB.

[0140] The derivation process of the chroma motion vector in clause 2.3.3.3 is called with mvA and refIdxA as inputs and the output is mvCA.

[0141] The derivation process of the chroma motion vector in clause 2.3.3.3 is called with mvB and refIdxB as inputs and the output is mvCB.

[0142] 2.3.3.2 Derivation of Luminance Motion Vectors for Merge Triangle Mode

[0143] This process is called only when MergeTriangleFlag[xCb][yCb] is equal to 1, where (xCb, yCb) specifies the top left sample of the current luma codec block relative to the top left luma sample of the current picture.

[0144] The inputs to this process are:

[0145] – The luminance position (xCb, yCb) of the upper left sample of the current luminance codec block relative to the upper left luminance sample of the current picture,

[0146] – The variable cbWidth specifies the width of the current codec block in luminance samples.

[0147] –The variable cbHeight specifies the height of the current codec block in luma samples.

[0148] The output of this process is:

[0149] – Luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy,

[0150] – reference indexes refIdxA and refIdxB,

[0151] –Prediction list flags predListFlagA and predListFlagB.

[0152] The motion vectors mvA and mvB, the reference indices refIdxA and refIdxB, and the prediction list flags predListFlagA and predListFlagB are derived by the following ordered steps:

[0153] – Calls the derivation process of luma motion vector for Merge mode as specified in clause 8.5.2.2, with luma position (xCb, yCb), variables cbWidth and cbHeight as input, and outputs are luma motion vectors mvL0[0][0], mvL1[0][0], reference indices refIdxL0, refIdxL1, prediction list utilization flags predFlagL0[0][0] and predFlagL1[0][0], bidirectional prediction weight index bcwIdx and Merge candidate list MergeCandList.

[0154] –Variables m and n are used as the merge indexes of triangle splits 0 and 1 respectively. Use merge_triangle_idx0[xCb][yCb] and merge_triangle_idx1[xCb][yCb] to derive variables m and n as follows:

[0155] m=merge_triangle_idx0[xCb][yCb] (8-475)

[0156] n=merge_triangle_idx1[xCb][yCb]+(merge_triangle_idx1[xCb][yCb]>=m)? 1:0

[0157] (8-476)

[0158] Assume that refIdxL0M and refIdxL1M, predFlagL0M and predFlagL1M, and mvL0M and mvL1M are the reference index, prediction list utilization flag, and motion vector of the Merge candidate M at position m in the Merge candidate list MergeCandList (M=MergeCandList[m]).

[0159] – The variable X is set equal to (m&0x01).

[0160] – When predFlagLXM is equal to 0, set X equal to (1-X).

[0161] – The following apply:

[0162] mvA[0]=mvLXM[0] (8-477)

[0163] mvA[1]=mvLXM[1] (8-478)

[0164] refIdxA=refIdxLXM (8-479)

[0165] predListFlagA=X (8-480)

[0166] Assume that refIdxL0N and refIdxL1N, predFlagL0N and predFlagL1N, and mvL0N and mvL1N are the reference index, prediction list utilization flag, and motion vector of the Merge candidate N at position m in the Merge candidate list MergeCandList (N=MergeCandList[n]).

[0167] – The variable X is set equal to (n & 0x01).

[0168] – When predFlagLXN is equal to 0, set X equal to (1-X).

[0169] – The following apply:

[0170] mvB[0]=mvLXN[0] (8-481)

[0171] mvB[1]=mvLXN[1] (8-482)

[0172] refIdxB=refIdxLXN (8-483)

[0173] predListFlagB=X (8-484)

[0174] 2.3.3.3 Chroma Motion Vector Derivation Process

[0175] The inputs to this process are:

[0176] – Luminance motion vector mvLX, with 1 / 16 fractional sample accuracy,

[0177] – Reference index refIdxLX.

[0178] The output of this process is the chroma motion vector mvCLX with 1 / 32 fractional sample accuracy.

[0179] The chrominance motion vectors are derived from the corresponding luminance motion vectors.

[0180] The chroma motion vector mvCLX is derived as follows:

[0181] mvCLX[0]=mvLX[0]*2 / SubWidthC (8-435)

[0182] mvCLX[1]=mvLX[1]*2 / SubHeightC (8-436)

[0183] 2.3.4 Decoding Process of Triangular Inter-frame Blocks

[0184] 2.3.4.1 Overview

[0185] This process is called when decoding a codec with MergeTriangleFlag[xCb][yCb] equal to 1.

[0186] The inputs to this process are:

[0187] –Specify the luminance position (xCb, yCb) of the upper left sample of the current codec block relative to the upper left luminance sample of the current picture,

[0188] – The variable cbWidth specifies the width of the current codec block in luminance samples.

[0189] – The variable cbHeight specifies the height of the current codec block in luminance samples.

[0190] – Luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy,

[0191] – chroma motion vectors mvCA and mvCB,

[0192] – reference indexes refIdxA and refIdxB,

[0193] –Prediction list flags predListFlagA and predListFlagB.

[0194] The output of this process is:

[0195] – (cbWidth)x(cbHeight) array of brightness prediction samples predSamples L ,

[0196] –(cbWidth / SubWidthC)x(cbHeight /

[0197] SubHeightC) array predSamples Cb ,

[0198] –(cbWidth / SubWidthC)x(cbHeight /

[0199] SubHeightC) array predSamples Cr .

[0200] Assume predSamplesLA L and predSamplesLB L is the (cbWidth)x(cbHeight) array of predicted luminance sample values, and assuming predSamplesLA Cb 、predSamplesLB Cb 、predSamplesLA Cr and predSamplesLB Cr It is a (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array of predicted chroma sample values.

[0201] predSamples L 、predSamples Cb and predSamples Cr It is derived through the following ordered steps:

[0202] 1. For N to be A and B respectively, the following applies:

[0203] – An ordered two-dimensional array of luminance samples refPicLN L and two ordered two-dimensional arrays refPicLN of chrominance samples Cb and refPicLN CrThe constructed reference pictures are derived by calling the procedure specified in clause 8.5.6.2 in VVC WD6 with X set to predListFlagN and refIdxX set to refIdxN as input.

[0204] – Array predSamplesLN L is derived by calling the fractional sample interpolation process specified in clause 8.5.6.3 of VVC WD6, where the luma position (xCb, yCb), the luma codec block width sbWidth set equal to cbWidth, the luma codec block height sbHeight set equal to cbHeight, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvN, and refPicLN set equal to L The reference array refPicLX L , the variable bdofFlag set equal to FALSE, and the variable cIdx set equal to 0 as input.

[0205] – Array predSamplesLN Cb is derived by calling the fractional sample interpolation process specified in clause 8.5.6.3 of VVC WD6, where the luma position (xCb, yCb), the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvCN, and refPicLN set equal to Cb The reference array refPicLX Cb , the variable bdofFlag set equal to false, and the variable cIdx set equal to 1 as input.

[0206] – Array predSamplesLN Cr is derived by calling the fractional sample interpolation process specified in clause 8.5.6.3 of VVC WD6, where the luma position (xCb, yCb), the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvCN, and refPicLN set equal to Cr The reference array refPicLX Cr, the variable bdofFlag set equal to false, and the variable cIdx set equal to 2 as input.

[0207] 2. Set the split direction of the Merge triangle mode variable triangleDir to equal merge_triangle_split_dir[xCb][yCb].

[0208] 3. By setting the codec block width nCbW equal to cbWidth, the codec block height nCbH equal to cbHeight, and the sample array predSamplesLA L and predSamplesLB L , and the variable triangleDir and the variable cIdx equal to 0 are used as input to call the weighted sample prediction process of the triangle Merge mode specified in clause 2.3.4.2 to derive the predicted samples predSamples in the current luminance codec block L [x L ][y L ], where x L = 0..cbWidth–1 and y L =0..cbHeight-1.

[0209] 4. By setting the codec block width nCbW equal to cbWidth / SubWidthC, the codec block height nCbH equal to cbHeight / SubHeightC, and the sample array predSamplesLA Cb and predSamplesLB Cb As well as the variable triangleDir and the variable cIdx equal to 1, the weighted sample prediction process of the triangle Merge mode specified in clause 2.3.4.2 is called as input to derive the predicted samples predSamples in the current chroma component Cb codec block. Cb [x C ][y C ], where x C = 0..cbWidth / SubWidthC–1 and y C =0..cbHeight / SubHeightC-1.

[0210] 5. By setting the codec block width nCbW equal to cbWidth / SubWidthC, the codec block height nCbH equal to cbHeight / SubHeightC, and the sample array predSamplesLA Cr and predSamplesLBCr As well as the variable triangleDir and the variable cIdx equal to 2, the weighted sample prediction process of the triangle Merge mode specified in clause 2.3.4.2 is called as input to derive the predicted samples predSamples within the current chroma component Cr codec block. Cr [x C ][y C ], where x C = 0..cbWidth / SubWidthC–1 and y C =0..cbHeight / SubHeightC-1.

[0211] 6. Call the motion vector storage process of the Merge triangle mode specified in clause 2.3.4.3, with the luma codec block position (xCb, yCb), luma codec block width cbWidth, luma codec block height cbHeight, segmentation direction triangleDir, luma motion vectors mvA and mvB, reference indices refIdxA and refIdxB, and prediction list flags predListFlagA and predListFlagB as input.

[0212] 2.3.4.2 Weighted Sample Point Prediction Process for Triangle Merge Mode

[0213] The inputs to this process are:

[0214] – Two variables nCbW and nCbH specify the width and height of the current codec block,

[0215] – two (nCbW)x(nCbH) arrays predSamplesLA and predSamplesLB,

[0216] – Variable triangleDir, specifies the direction of segmentation,

[0217] –Variable cIdx, specifies the color component index.

[0218] The output of this process is the (nCbW)x(nCbH) array pbSamples of predicted sample values.

[0219] The variable nCbR is derived as follows:

[0220] nCbR=(nCbW>nCbH)? (nCbW / nCbH):(nCbH / nCbW)

[0221] (8-841)

[0222] The variable bitDepth is derived as follows:

[0223] – If cIdx is equal to 0, set bitDepth equal to BitDepth Y .

[0224] – Otherwise, set bitDepth equal to BitDepth C .

[0225] The variables shift1 and offset1 are derived as follows:

[0226] – Set the variable shift1 equal to Max(5, 17-bitDepth).

[0227] – Set the variable offset1 equal to 1<<(shift1-1).

[0228] Depending on the values ​​of triangleDir, wS and cidx, the prediction samples pbSamples[x][y] are derived as follows, where x = 0..nCbW-1 and y = 0..nCbH-1:

[0229] –The variable wIdx is derived as follows:

[0230] – If cIdx is equal to 0 and triangleDir is equal to 0, the following applies:

[0231] wIdx=(nCbW>nCbH)? (Clip3(0,8,(x / nCbR-y)+4)):(Clip3(0,8,(xy / nCbR)+4))(8-842)

[0232] – Otherwise, if cIdx is equal to 0 and triangleDir is equal to 1, the following applies:

[0233] wIdx=(nCbW>nCbH)? (Clip3(0,8,(nCbH-1-x / nCbR-y)+4)): (Clip3(0,8,(nCbW-1-xy / nCbR)+4)) (8-843)

[0234] – Otherwise, if cIdx is greater than 0 and triangleDir is equal to 0, the following applies:

[0235] wIdx=(nCbW>nCbH)? (Clip3(0,4,(x / nCbR-y)+2)):(Clip3(0,4,(xy / nCbR)+2))(8-844)

[0236] – Otherwise (if cIdx is greater than 0 and triangleDir is equal to 1), the following applies:

[0237] wIdx=(nCbW>nCbH)? (Clip3(0,4,(nCbH-1-x / nCbR-y)+2)): (Clip3(0,4,(nCbW-1-xy / nCbR)+2)) (8-845)

[0238] –Use wIdx and cIdx to derive the variable wValue that specifies the prediction sample weight, as shown below:

[0239] wValue=(cIdx==0)? Clip3(0,8,wIdx):Clip3(0,8,wIdx*2)

[0240] (8-846)

[0241] – The predicted sample point values ​​are derived as follows:

[0242] pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(predSamplesLA[x][y]*wValue+predSamplesLB[x][y]*(8-wValue)+offset1)> >shift1) (8 847)

[0243] 2.3.4.3 Motion Vector Storage Process in Triangle Merge Mode

[0244] This process is called when decoding a codec unit with MergeTriangleFlag[xCb][yCb] equal to 1.

[0245] The inputs to this process are:

[0246] – Luma position (xCb, yCb), specifies the top left sample of the current codec block relative to the top left luma sample of the current picture,

[0247] – The variable cbWidth specifies the width of the current codec block in luminance samples.

[0248] – The variable cbHeight specifies the height of the current codec block in luminance samples.

[0249] – Variable triangleDir, specifies the direction of segmentation,

[0250] – Luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy,

[0251] – reference indexes refIdxA and refIdxB,

[0252] –Prediction list flags predListFlagA and predListFlagB.

[0253] The variables numSbX and numSbY, which specify the number of 4x4 blocks in the current codec block in the horizontal and vertical directions, are set equal to numSbX=cbWidth>>2 and numSbY=cbHeight>>2.

[0254] The variable minSb is set equal to Min(numSbX, numSbY)-1.

[0255] The variable cbRatio is derived as follows:

[0256] cbRatio=(cbWidth>cbHeight)? (cbWidth / cbHeight):(cbHeight / cbWidth)

[0257] (8-848)

[0258] For each 4x4 sub-block at sub-block index (xSbIdx, ySbIdx) where xSbIdx = 0..numSbX-1 and ySbIdx = 0..numSbY-1, the following applies:

[0259] – The variables xIdx and yIdx are derived as follows:

[0260] xIdx=(cbWidth>cbHeight)? (xSbIdx / cbRatio):xSbIdx (8-849)

[0261] yIdx=(cbWidth>cbHeight)? ySbIdx:(ySbIdx / cbRatio)(8-850)

[0262] –The variable sType is exported as follows:

[0263] – If triangleDir is equal to 0, the following applies:

[0264] sType=(xIdx==yIdx)? 2:((xIdx>yIdx)?0:1) (8-851)

[0265] – Otherwise (triangleDir is equal to 1), the following applies:

[0266] sType=(xIdx+yIdx==minSb)? 2:((xIdx+yIdx <minSb)?0:1) (8-852)

[0267] – Depending on the value of sType, the following assignments are made:

[0268] – If sType is equal to 0, the following applies:

[0269] predFlagL0=(predListFlagA==0)? 1:0 (8-853)

[0270] predFlagL1=(predListFlagA==0)? 0:1 (8-854)

[0271] refIdxL0=(predListFlagA==0)? refIdxA:-1 (8-855)

[0272] refIdxL1=(predListFlagA==0)? -1:refIdxA (8-856)

[0273] mvL0[0]=(predListFlagA==0)? mvA[0]:0 (8-857)

[0274] mvL0[1]=(predListFlagA==0)? mvA[1]:0 (8-858)

[0275] mvL1[0]=(predListFlagA==0)? 0:mvA[0] (8-859)

[0276] mvL1[1]=(predListFlagA==0)? 0:mvA[1] (8-860)

[0277] – Otherwise, if sType is equal to 1 or (sType is equal to 2 and predListFlagA + predListFlagB are not equal to 1), the following applies:

[0278] predFlagL0=(predListFlagB==0)? 1:0 (8-861)

[0279] predFlagL1=(predListFlagB==0)? 0:1 (8-862)

[0280] refIdxL0=(predListFlagB==0)? refIdxB:-1 (8-863)

[0281] refIdxL1=(predListFlagB==0)? -1:refIdxB (8-864)

[0282] mvL0[0] = (predListFlagB == 0)? mvB[0] : 0 (8 - 865)

[0283] mvL0[1] = (predListFlagB == 0)? mvB[1] : 0 (8 - 866)

[0284] mvL1[0] = (predListFlagB == 0)? 0 : mvB[0] (8 - 867)

[0285] mvL1[1] = (predListFlagB == 0)? 0 : mvB[1] (8 - 868)

[0286] - Otherwise (sType equals 2 and predListFlagA + predListFlagB equals 1), the following applies:

[0287] predFlagL0 = 1 (8 - 869)

[0288] predFlagL1 = 1 (8 - 870)

[0289] refIdxL0 = (predListFlagA == 0)? refIdxA : refIdxB (8 - 871)

[0290] refIdxL1 = (predListFlagA == 0)? refIdxB : refIdxA (8 - 872)

[0291] mvL0[0] = (predListFlagA == 0)? mvA[0] : mvB[0] (8 - 873)

[0292] mvL0[1] = (predListFlagA == 0)? mvA[1] : mvB[1] (8 - 874)

[0293] mvL1[0] = (predListFlagA == 0)? mvB[0] : mvA[0] (8 - 875)

[0294] mvL1[1] = (predListFlagA == 0)? mvB[1] : mvA[1] (8 - 876)

[0295] - The following assignments are made for x = 0..3 and y = 0..3:[[ID=(41)]] [[ID=(42)]]

[0296] MvL0[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=mvL0 (8-877)

[0297] MvL1[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=mvL1 (8-878)

[0298] RefIdxL0[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=refIdxL0 (8-879)

[0299] RedIdxL1[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=refIdxL1 (8-880)

[0300] PredFlagL0[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=predFlagL0 (8-881)

[0301] PredFlagL1[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=predFlagL1 (8-882)

[0302] 2.4 Geometry Merge Mode (GEO)

[0303] In JVET-P0068, the GEO Merge mode is being studied as an extension of the existing TPM in VVC. GEO uses the same prediction blending concept as TPM, but extends the blending mask to 140 different modes with 32 angles and 5 distance offsets. The blending mask for the GEO mode is derived from the distance and partition boundaries of the sample locations using three lookup tables.

[0304] 2.4.1 Concept Description

[0305] Figure 13A and Figure 13B The TPM in VTM-6.0 is shown along with the additional shapes proposed for non-rectangular inter blocks.

[0306] Similar to TPM, the proposed GEO partitioning for inter frames is allowed for unidirectionally predicted blocks of at least 8×8, allowing for the same memory bandwidth at the decoder as for bidirectionally predicted blocks. The motion vector prediction for GEO partitioning is aligned with TPM. In TPM, blending between the two predictions is applied at internal boundaries.

[0307] The division boundary of the geometric merge mode is as follows Figure 14 The angles shown in and distance offset ρ iTo describe. Angle represents a quantized angle between 0 and 360 degrees, and is offset by ρ i Represents the maximum distance ρ max The quantization offset of . The partition directions that overlap with the binary tree partition and TPM partition will be excluded.

[0308] 2.4.2 Angle and distance quantization.

[0309] Use a fixed step size to change the angle between 0 and 360 degrees Quantification.

[0310] In CE4-1.1, CE4-1.2a with 108 modes, and CE4-1.14, the angle between 0 and 360 degrees is adjusted with a step size of 11.25 degrees. Quantify, such as Figure 15A As shown in , there are 32 angles in total.

[0311] In CE4-1.2b with 80 modes, the angle Quantization is still performed with a step size of 11.25 degrees, but since objects and motion are mostly horizontal in natural values, angles close to vertical (close to horizontal partition boundaries) are removed. Figure 15B A reduction to 24 angles is shown.

[0312] From the maximum possible distance ρ max Quantize the distance ρ with a fixed step size i ρ max The value of can be derived geometrically from equation (1), where w or h is equal to 8, and ρ max The value of is scaled by the length of the shorter side using the log2 scaling. When it is equal to 0 degrees, ρ max is equal to w / 2, and for When it is equal to 90 degrees, ρ max Equal to h / 2. The "1.0" sample point is shifted backward to avoid the division boundary being too close to the corner.

[0313]

[0314] In CE4-1.1 and CE4-1.14, the distance ρ is calculated with a step size of 5. i For quantization, considering 32 angles, there are a total of 140 partitioning patterns, excluding binary tree and TPM partitioning.

[0315] In CE4-1.2a with 108 patterns, the distance ρ is calculated with 4 steps. i For quantization, considering 32 angles, there are a total of 108 partitioning patterns, excluding binary tree and TPM partitioning.

[0316] In CE4-1.2b with 80 patterns, the distance ρ is calculated with 4 steps. i For quantization, considering 24 angles, there are a total of 80 partitioning patterns, excluding binary tree and TPM partitioning.

[0317] The angles, distances, and number of modes used for CE testing are summarized in Table 1:

[0318] Table 1 Number of angles, number of distances, and number of division modes

[0319]

[0320]

[0321] 2.4.3 Blending Operations of Luminance Blocks

[0322] In Geometric Merge mode, same as TPM mode, with a final predictor P of 3-bit mix masks W0 and W1 B , as shown in equation (2).

[0323] P B =(W0P0+W1P1+4)>>3(2)

[0324] The blend mask for the geometric Merge mode is derived from the distances between the partition boundaries and the sample locations using a lookup table with equations (3), (4) and (5).

[0325] distFromLine=((x<<1)+1)*Dis[displacementX]+((y<<1)+1))*Dis[displacementY]–rho (3)

[0326] distScaled=Clip3(0,26,(abs(distFromLine)+4)>>3) (4)

[0327] sampleWeightL[x][y]=distFromLine<=0? GeoFilter[distScaled]:8-GeoFilter[distScaled] (5)

[0328] There are three lookup tables involved: Dis[.] with 32 entries, StepDis[.] with 36 entries, and GeoFilter[.] with 26 entries.

[0329] Ensure that the bottom left sample of the current block is predicted from P0. In other words, when distFromLine of the bottom left sample is negative, W0 is equal to sampleWeightL[x][y], and W1 is equal to 8-W0. Otherwise (distFromLine of the bottom left sample is positive), W1 is equal to sampleWeightL[x][y], and W0 is equal to 8-W1.

[0330] Since all remaining operations use lookup tables, the actual computational complexity of the geometric blend mask is derived from Equation (3).

[0331] In the VTM software implementation, equation (3) requires 1 addition per sample and 1 addition per sample row, e.g., in an 8x8 CU, each sample requires 1.125 additions and 0.015625 multiplications.

[0332] To process each 4x4 unit in parallel (e.g. in an 8x8 CU), 1.25 additions and 0.0625 multiplications are required per sample.

[0333] To process each line in parallel (e.g. 8x8 CU), each sample requires 1 addition and 0.125 multiplications.

[0334] To process all samples in a CU in parallel, two multiplications and one addition are required for each sample.

[0335] Table 2 summarizes the worst-case computational complexity for each sample (8x8):

[0336] Table 2 Complexity analysis in the worst case

[0337]

[0338] For more details on the blending operation, refer to the accompanying draft specification modification document "8.5.7.3 Weighted Sample Prediction Process for Geometric Merge Mode".

[0339] 2.4.4 Chroma Block Mixing Operation

[0340] The sample weights calculated for the luma samples are subsampled and used for chroma blending without any calculations. The weight of the chroma sample at coordinate (x, y) is set equal to the weight of the luma sample at coordinate (2x, 2y) relative to the top left sample of the luma block.

[0341] 2.4.5 Motion Vector Export

[0342] The same merge list derivation process used for TPM is used to derive the motion vectors for each partition of the GEO block. Each partition is predicted using only unidirectional prediction.

[0343] 2.4.6 Motion Vector Storage

[0344] In CE4-1.1 and CE4-1.2, the weights of the luma samples at the four corners of a 4x4 motion memory cell are summed. The sum is then compared with two thresholds to decide whether to store either the two unidirectional prediction motion information or the bidirectional prediction motion information. The bidirectional prediction motion information is derived using the same process as TPM.

[0345] In CE4-1.14, the motion vector storage process has been further simplified. The distance between the center position of a 4×4 motion storage unit and the partition boundary is calculated and compared with a fixed threshold to determine whether to store unidirectional or bidirectional prediction motion information for that 4×4 motion storage unit. The sign of the distance indicates which unidirectional prediction motion information should be stored in the case of unidirectional prediction storage. In CE4-1.14, the dependency between the blend mask and motion storage has been removed.

[0346] 2.4.7 Mode Signaling Notification

[0347] According to the proposed method, GEO mode is signaled together with TPM mode as an additional Merge mode.

[0348] Table 3 Syntax elements introduced by this proposal

[0349]

[0350]

[0351] Four CABAC context models are used to signal merge_geo_flag[][]. The first three CABAC context modes are derived depending on the modes of the upper and left neighboring blocks, and the fourth CABAC context mode is derived depending on the aspect ratio of the current block. merge_geo_flag[][] indicates whether the current block uses GEO mode or TPM mode, which is similar to the "most likely mode" flag.

[0352] geo_partition_idx[][] is used as an index into a lookup table that stores the angles and distance ρ i Yes. The geo_partition_idx codec truncates the binary and uses bypass for binarization.

[0353] 3. Examples of technical problems solved by the technical solutions described in this article

[0354] There are several issues in the latest VVC working draft WD6 (JVET-O2001-v14), as described below.

[0355] (1) In WD6, for the mixing process of two triangle partitions, such as Figure 8 As shown in , the chroma weights are not aligned with the luma weights, which may cause visual artifacts.

[0356] (2) In WD6, the setting of weights for triangle prediction does not take into account multiple chroma formats, such as 4:2:2 and 4:4:4, as shown in Figure 8 As shown in .

[0357] (3) In WD6, chrominance only allows even weights, which is inconsistent with luminance because the luminance component allows even and odd integers, such as Figure 8 As shown in .

[0358] (4) In WD6, TPM is allowed for 4xN and Nx4 blocks, where all pixels are required to perform weighted blending, which may not be desirable.

[0359] (5) In WD6, TPM is allowed for blocks with aspect ratios greater than 2, which may not be desirable.

[0360] (6) GEO and TPM are used for independent signaling notification and independent calculation of hybrid weight mask and motion storage mask, respectively.

[0361] Figure 8 An example of weights used in the mixing process for an 8x16 TPM block (WD6) is shown.

[0362] 4. Examples of Embodiments and Technologies

[0363] The items listed below should be considered as examples to explain the general concept. These items should not be interpreted narrowly. In addition, these items can be combined in any way.

[0364] The term "TPM" may refer to a coding method that divides a block into two or more sub-regions and applies a transform to the entire block. The term "TPM" may indicate triangle prediction mode and / or geometry merge mode, which is an extension of triangle prediction mode.

[0365] Weighted sampling points in the TPM mixing process

[0366] 1. The weights of the TPM chrominance prediction samples can be aligned with the weights of the co-located luma prediction samples.

[0367] a) In one example, the weights of TPM-encoded chrominance blocks (eg, Cb blocks and / or Cr blocks) may be set according to the weights of co-located luma blocks.

[0368] b) In one example, the weights of the TPM-encoded chroma blocks may be a subset of the weights of the co-located luma blocks.

[0369] c) In one example, for each position inside the block, a chroma block with dimensions MxN may be assigned the same weight as a luma block with dimensions MxN.

[0370] 2. The weights of the TPM chroma prediction samples may depend on the width and height of the co-located luma block, and / or the color format, including the chroma subsampling rate.

[0371] a) In one example, for a 4:4:4 chroma format, the weights of the TPM chroma prediction samples may be the same as the weights of the co-located luma prediction samples at each position within the block.

[0372] b) In one example, for 4:2:0 and 4:2:2 chroma formats, the weights of the TPM chroma prediction samples may be subsampled from the weights of the TPM luma prediction samples.

[0373] i. For a W×H TPM prediction block, where W is the block width and H is the block height, subWidthC and subHeightC represent the chroma subsampling rates in the width and height directions, respectively. Assuming that the weights of the luma prediction block are represented by a two-dimensional array WeightY[x][y], where x=0…(W-1) and y=0…(H-1), the weights of the co-located chroma prediction block WeightC[x][y] can be calculated by WeightY[f(x)][g(y)], where x=0…(W / subWidthC-1) and y=0…(H / subHeightC-1).

[0374] 1) In one example, f(x)=x*subWidthC+offsetX, g(y)=y*subHeightC+OffsetY, for example, OffsetX=OffsetY=0.

[0375] ii. Assuming a WxH TPM luma block, the weight of a position (x, y) is calculated by w(x, y), e.g., w(x, y) = a*x + b*y + c, where x = 0 ... W-1 and y = 0 ... H-1 are the coordinates of the luma samples, and a, b, c are integers that depend on W and / or H. In one example, the weight of a position (x', y') in a co-located TPM chroma block can be calculated as w(f(x'), g(y')), e.g., w(f(x'), g(y')) = a*(subWidthC*x') + b*(subHeightC*y') + c, where x' = 0 ... W / subWidthC-1 and y' = 0 ... H / subHeightC-1 are the coordinates of the chroma samples.

[0376] c) In one example, the weights used in the TPM may depend only on the dimensions of the block (width or / and height), and the weights used in the TPM may be the same for different color components.

[0377] i. For example, a chroma component with size W*H can use the same weight as a luma component with size W*H.

[0378] ii. In one example, when no weight is defined for a luma block size, TPM may be disabled for chroma blocks of this size.

[0379] d) In one example, the weights used in the TPM may depend on both the dimensions of the block (width and / or height) and the color components of the block.

[0380] i. In one example, the weights for different color components may be different.

[0381] ii. In one example, the weights for the two chroma components may be the same.

[0382] 1) Alternatively, furthermore, the weights for the luma component and the chroma components may be different.

[0383] 3. The weight of the TPM prediction sample point can be equal to the integer X.

[0384] a) In one example, an odd integer or an even integer may be assigned as the weight X (such as X=0...8) of the TPM chroma prediction sample.

[0385] b) The weights of TPM luma / chroma prediction samples can be clipped to the range [M, N], such as M=0, N=8.

[0386] c) In one example, the TPM weight may be less than zero.

[0387] 4. In one example, the hybrid weight masks of the TPM / GEO block may be predefined as N tables (eg, N>0).

[0388] 5. In one example, the hybrid weight mask of the TPM / GEO block can be calculated from the calculation equation.

[0389] General Questions about TPM

[0390] Denote the block width as W and the block height as H.

[0391] 6. Whether TPM is enabled or disabled may depend on the ratio of block width to block height, such as max(H, W) / min(H, W).

[0392] a) Alternatively, whether TPM is enabled or disabled may depend on the difference between the block width and the block height, e.g., Abs(Log2(cbWidth)-Log2(cbHeight)), where Abs(x) returns the absolute value of x and Log2(x) returns the logarithm base 2 of the number x.

[0393] b) TPM may not be allowed for blocks with aspect ratios or height-to-width ratios greater than X (eg, X=2).

[0394] i. In one example, for a W×H prediction block, if W / H>2, then TPM may be disabled.

[0395] ii. In one example, for a W×H prediction block, if H / W>2, then TPM may be disabled.

[0396] 7. Whether TPM use is allowed may depend on the maximum transform size.

[0397] a) In one example, TPM may not be allowed for blocks with width or / and height larger than the maximum transform size.

[0398] 8. Whether TPM usage is allowed may depend on the maximum CU size.

[0399] a) In one example, TPM may not be allowed for blocks with block width or / and block height equal to the maximum CU size.

[0400] 9. TPM may not be allowed for blocks with block width greater than N or / and block height greater than M.

[0401] a) In one example, N=M=64.

[0402] 10. TPM may not be allowed for blocks with block width equal to N or / and block height equal to M.

[0403] a) In one example, N=M=4

[0404] 11. For some color formats, TPM may not be allowed.

[0405] a) In one example, for 4:0:0 chroma formats, TPM may not be allowed.

[0406] b) In one example, for 4:4:4 chroma formats, TPM may not be allowed.

[0407] c) In one example, for 4:2:2 chroma formats, TPM may not be allowed.

[0408] 12. If the resolution of the two reference pictures used in TPM is different, TPM may not be allowed.

[0409] a) Alternatively, if the resolution of one of the reference pictures used in TPM is different from the resolution of the current picture, TPM may not be allowed.

[0410] 13. When TPM is disabled or not allowed, TPM syntax elements (such as merge_triangle_split_dir, merge_triangle_idx0, and merge_triangle_idx1) may not be signaled.

[0411] a) When a syntax element is not signaled, it can be inferred to be 0.

[0412] b) When TPM is disabled or not allowed, TPM-related semantic variables (such as MergeTriangleFlag) can be inferred to be 0.

[0413] 14. The above bullet points can be applied to Triangle Prediction Mode (TPM) and / or Geometry Merge Mode (GEO). In other words, TPM can refer to GEO.

[0414] Unification of TPM and GEO

[0415] 15.TPM and GEO can be unified.

[0416] a) In one example, TPM can be considered a subset of GEO.

[0417] i. Alternatively, GEO can be considered a subset of TPM.

[0418] ii. For example, if codec tool A (or equivalently referred to as "mode A", or simply "A") (such as TPM) is considered to be a subset of codec tool B (or equivalently referred to as "mode B", or simply "B") (such as GEO), the method disclosed below can be applied.

[0419] 1) A and B can be signaled as one pattern.

[0420] a) In one example, mode A and mode B may share the same control flag(s) at SPS / VPS / APS / PPS / slice / sub-picture / slice / brick / VPDU / CTU / TU / CU / PU / picture header / slice header level.

[0421] b) In one example, mode A may be signaled as a subset of B.

[0422] i. For example, define B as a prediction mode containing N (such as N>1) sub-modes, and these N sub-modes are represented as {M0, M1, M2…, MN-1}, and A can be defined as a prediction pattern that includes X sub - patterns (such as X < N), and these X sub - patterns are represented as {M0, M k0 , M k1 …, M kX-1}, where {M0, M k0 , M k1 …, M[[ID=​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

[0437] a) Alternatively, the motion vector storage mask for the GEO may be generated in the same manner as for the TPM.

[0438] b) In one example, a motion vector storage mask may be generated and / or stored that indicates an inter-prediction direction (such as uni-directional prediction or bi-directional prediction) for a particular combination of block width and block height.

[0439] i. In one example, the motion vector storage mask may be generated only for allowed combinations of block width and block height.

[0440] c) In one example, each element of the motion vector storage mask indicates which motion vector of the two sub-partitions is stored, and / or how many motion vectors are stored for the 4×4 sub-block (such as one motion vector or two motion vectors) and / or the inter-prediction direction (such as unidirectional prediction or bidirectional prediction).

[0441] d) In one example, the motion vector storage mask of the TPM / GEO block may be predefined as N tables (eg, N>0).

[0442] e) In one example, the motion vector storage mask of the TPM / GEO block can be calculated from the calculation equation.

[0443] 17. TPM / GEO motion vectors can be stored in 4×4 units.

[0444] a) In one example, each of the two sub-partitions of TPM / GEO has its own motion vector for motion compensation, but the motion vectors stored for spatial / temporal motion vector candidates are in 4x4 units.

[0445] i. In one example, each 4x4 sub-block of the TPM / GEO may have a different motion vector stored in the buffer.

[0446] 18. Both L0 motion vectors and L1 motion vectors may be stored for sub-blocks belonging to mixed regions of TPM / GEO.

[0447] a) In one example, a mixed area may indicate an area overlapped by two sub-segments.

[0448] b) In one example, for those 4x4 sub-blocks outside the mixed area of ​​the TPM / GEO block, the sub-partitioned uni-directional prediction (such as L0 or L1) motion vectors may be stored.

[0449] c) In one example, for those 4x4 sub-blocks belonging to a mixed area of ​​a TPM / GEO block, bi-directionally predicted motion vectors of both sub-partitions may be stored.

[0450] d) In one example, for those 4x4 sub-blocks belonging to a mixed area of ​​TPM / GEO blocks, if both sub-partitions have motion vectors from the same direction, the minimum / maximum / average / weighted motion vector of the two motion vectors may be stored.

[0451] Deblocking of TPM and GEO

[0452] 19. Whether and / or how the deblocking process is applied to a codec block may depend on whether the codec block was encoded using TPM or GEO mode.

[0453] a) In one example, the boundary between two sub-blocks in two different partitions may be filtered in the deblocking filter stage.

[0454] i. In one example, in this case, the boundary strength (BS) is equal to 1.

[0455] ii. In one example, in this case, the boundary strength (BS) is equal to 2.

[0456] 20. Deblocking can be triggered at the boundary between two sub-blocks in a TPM codec / GEO codec block.

[0457] a) In one example, if one of the two sub-blocks except for the intra-TU edge of TPM / GEO mode has a non-zero coefficient, deblocking may be triggered regardless of whether there is a motion difference between the two sub-blocks.

[0458] b) There may be no non-zero coefficients in both sub-blocks.

[0459] i. In one example, if two sub-blocks except for the inner TU edge of the TPM / GEO pattern have all-zero coefficients, but the motion difference of the two sub-blocks is large enough, deblocking can still be triggered.

[0460] ii. Alternatively, if two sub-blocks except for the inner TU edge of the TPM / GEO pattern have all-zero coefficients, but the motion difference of the two sub-blocks is large enough, deblocking may not be triggered.

[0461] c) Whether deblocking is triggered for an edge of two sub-blocks coded in TPM / GEO mode may depend on whether it is a TU edge or an MV edge of the two sub-blocks.

[0462] i. If the motion difference is large enough for the MV edge of TPM / GEO mode, deblocking may be triggered.

[0463] ii. If there are non-zero coefficients in a sub-block besides the TU edge in TPM / GEO mode, deblocking may be triggered.

[0464] iii. When the filtering edge is both a TU edge and an MV edge, deblocking may be triggered if any of the following conditions is met.

[0465] 1) If the motion difference is large enough.

[0466] 2) There are non-zero coefficients in either of the two sub-blocks.

[0467] d) The above-mentioned “TU edge” indicates the actual transform unit edge, and the above-mentioned “MV edge”

[0468] Indicates the PU edge or sub-block edge aligned with the filtering grid.

[0469] e) The above-mentioned "poor movement" may indicate the following situations.

[0470] i. The difference in motion vectors between two sub-blocks is greater than T (such as T = 1 pixel or 1 / 2 pixel or 8 in units of 1 / 16 brightness samples)

[0471] ii. Different reference frame indices

[0472] iii. Different reference POCs

[0473] iv. Different number of reference frames.

[0474] About configurable CTU size and maximum transform size

[0475] 21. Whether ISP is applied may not depend on the maximum transform size and / or the minimum transform size.

[0476] a) In one example, the signaling of an ISP flag (such as intra_subpartitions_mode_flag) may not depend on whether the width of the current block is less than or equal to the maximum transform size, and / or may not depend on whether the height of the current block is less than or equal to the maximum transform size.

[0477] b) In one example, the signaling of an ISP flag (such as intra_subpartitions_mode_flag) may not depend on whether the width multiplied by the height of the current block is greater than the square of the minimum transform size.

[0478] c) In one example, the signaling of an ISP flag (such as intra_subpartitions_mode_flag) may depend on whether the width multiplied by the height of the current block is greater than 16.

[0479] d) In one example, the signaling of an ISP flag (such as intra_subpartitions_mode_flag) may depend on whether the width of the current block is less than or equal to 64, and / or on whether the height of the current block is less than or equal to 64.

[0480] 22. When the dimension of the codec block is larger than the maximum transform size, ISP can be applied.

[0481] a) In one example, when the ISP codec block is larger than the maximum transform size, the ISP block can be implicitly divided in a recursive manner until the size of the sub-partition reaches 64.

[0482] b) In one example, when the ISP codec block is larger than the maximum transform size, the ISP block can be implicitly partitioned in a recursive manner until the size of the sub-partition reaches the maximum transform size.

[0483] 23. When the dimension of the codec block is greater than or equal to 128, CIIP and / or TPM and / or GEO can be applied.

[0484] a) In one example, the maximum CTU size can be set to be greater than 128.

[0485] b) In one example, CIIP may be used for blocks with block dimensions greater than or equal to 128.

[0486] c) In one example, TPM and / or GEO may be applied to blocks with block dimensions greater than 128.

[0487] 24. When the dimension of the codec block is greater than 128, Merge data can be signaled.

[0488] a) In one example, Merge flags (such as regular_merge_flag, mmvd_merge_flag, mmvd_cand_flag, mmvd_distance_idx, mmvd_direction_idx, merge_idx, ciip_flag, merge_triangle_split_dir, merge_triangle_idx0, merge_triangle_idx1) may depend on whether the dimension of the codec block is smaller than the maximum CTU size.

[0489] 25. If the block width and / or block height is equal to or greater than X (such as X=64 or 128), the value of pred_mode_ibc_flag can be inferred to be 0.

[0490] a) In one example, if the block width and block height are greater than 64, the value of pred_mode_ibc_flag may be inferred to be 0.

[0491] b) In one example, if the block width or block height is greater than 64, the value of pred_mode_ibc_flag may be inferred to be 0.

[0492] 26. When the dimension of the codec block is greater than 128, cu_skip_flag and / or pred_mode_flag may be signaled.

[0493] Conventional deblocking

[0494] 27. The picture-level deblocking parameter offsets of β and tC can be different for each component.

[0495] a) In one example, the picture level deblocking parameter offsets for luma, Cb, and Cr may be different and indicated by different syntax elements.

[0496] b) Alternatively, furthermore, the picture level deblocking parameter offsets for the joint_cb_cr codec mode may be different and indicated by different syntax elements.

[0497] 28. The slice-level deblocking parameter offsets of β and tC can be different for each component.

[0498] a) In one example, the slice level deblocking parameter offsets for luma, Cb, and Cr may be different and indicated by different syntax elements.

[0499] b) Alternatively, furthermore, the picture level deblocking parameter offsets for the joint_cb_cr codec mode may be different and indicated by different syntax elements.

[0500] 29. The chroma QP used to derive chroma deblocking parameters can be based on the picture-level chroma QP offset and the CU-level chroma QP offset, but is independent of the slice-level chroma QP offset.

[0501] a) In one example, the chroma QP used to derive the chroma deblocking parameters may depend on pps_cb_qp_offset, pps_cr_qp_offset, pps_cbcr_qp_offset, CuQpOffset Cb 、CuQpOffset Cr and CuQpOffset CbCr, but has nothing to do with slice_cb_qp_offset, slice_cr_qp_offset, and slice_cbcr_qp_offset.

[0502] 5. Examples

[0503] The following are example embodiments that can be applied to the VVC specification. These modifications are based on the latest VVC working draft (JVET-O2001-v14). New additions are highlighted in bold and italics, and deletions from the VVC working draft are marked with double brackets (e.g., [[a]] indicates the deletion of the character "a").

[0504] 5.1 Example 1 of TPM Luminance and Chroma Weights

[0505] The TPM chroma weights are aligned with the luma weights according to the block width, block height, and chroma subsampling rate. Figure 9 Example weight settings for an 8x16 TPM prediction block are shown.

[0506] 5.2 Example 2 of aligning TPM chrominance weights with TPM luminance weights

[0507] 8.5.7 Decoding Process for Triangular Inter-Frame Blocks

[0508] 8.5.7.1 Overview

[0509] This process is called when decoding a codec unit with MergeTriangleFlag[xCb][yCb] equal to 1.

[0510] The inputs to this process are:

[0511] – Luma position (xCb, yCb), specifies the top left sample of the current codec block relative to the top left luma sample of the current picture,

[0512] – The variable cbWidth specifies the width of the current codec block in luminance samples.

[0513] – The variable cbHeight specifies the height of the current codec block in luminance samples.

[0514] – Luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy,

[0515] – chroma motion vectors mvCA and mvCB,

[0516] – reference indexes refIdxA and refIdxB,

[0517] –Prediction list flags predListFlagA and predListFlagB.

[0518] The output of this process is:

[0519] – (cbWidth)x(cbHeight) array of brightness prediction samples predSamples L ,

[0520] – predSamples array of (cbWidth / SubWidthC)x(cbHeight / SubHeightC) of chroma prediction samples of component Cb Cb ,

[0521] – predSamples array of (cbWidth / SubWidthC)x(cbHeight / SubHeightC) of the chroma prediction sample of component Cr Cr .

[0522] Assume predSamplesLA L and predSamplesLB L is the (cbWidth)x(cbHeight) array of predicted luminance sample values, and predSamplesLA Cb 、predSamplesLB Cb 、predSamplesLA Cr and predSamplesLB Cr It is a (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array of predicted chroma sample values.

[0523] predSamples L 、predSamples Cb and predSamples Cr It is derived through the following ordered steps:

[0524] 1. For each of N A and B, the following applies:

[0525] – An ordered two-dimensional array of luminance samples refPicLN L and two ordered two-dimensional arrays refPicLN of chrominance samples Cb and refPicLN CrThe constructed reference pictures are derived by calling the procedure specified in clause 8.5.6.2 in VVC WD6 with X set equal to predListFlagN and refIdxX set equal to refIdxN as input.

[0526] – Array predSamplesLN L is derived by invoking the fractional sample interpolation process specified in clause 8.5.6.3, with the luma position (xCb, yCb), the luma codec block width sbWidth set equal to cbWidth, the luma codec block height sbHeight set equal to cbHeight, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvN, and refPicLN set equal to L The reference array refPicLX L , the variable bdofFlag set equal to false, and the variable cIdx set equal to 0 as input.

[0527] – Array predSamplesLN Cb is derived by calling the fractional sample interpolation process specified in clause 8.5.6.3 of VVC WD6, where the luma position (xCb, yCb), the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvCN, and refPicLN set equal to Cb The reference array refPicLX Cb , the variable bdofFlag set equal to false, and the variable cIdx set equal to 1 as input.

[0528] – Array predSamplesLN Cr is derived by calling the fractional sample interpolation process specified in clause 8.5.6.3 of VVC WD6, where the luma position (xCb, yCb), the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0, 0), the motion vector mvLX set equal to mvCN, and refPicLN set equal to Cr The reference array refPicLX Cr, the variable bdofFlag set equal to false, and the variable cIdx set equal to 2 as input.

[0529] 2. Set the split direction of the Merge triangle mode variable triangleDir to equal merge_triangle_split_dir[xCb][yCb].

[0530] 3. By setting the codec block width nCbW equal to cbWidth, the codec block height nCbH equal to cbHeight, and the sample array predSamplesLA L and predSamplesLB L , and the variable triangleDir and the variable cIdx equal to 0 are used as input to call the weighted sample prediction process of the triangle Merge mode specified in clause 8.5.7.2 to derive the prediction samples predSamples in the current luminance codec block L [x L ][y L ], where x L = 0..cbWidth–1 and y L =0..cbHeight-1.

[0531] 4. By setting the brightness codec block width nCbW equal to cbWidth[[ / SubWidthC]], setting the brightness codec block height nCbH equal to cbHeight[[ / SubHeightC]], and the sample array predSamplesLA Cb and predSamplesLB Cb As well as the variable triangleDir and the variable cIdx equal to 1, the weighted sample prediction process of the triangle Merge mode specified in clause 8.5.7.2 is called as input to derive the prediction samples predSamples within the current chroma component Cb codec block Cb [x C ][y C ], where x C = 0..cbWidth / SubWidthC–1 and y C =0..cbHeight / SubHeightC-1.

[0532] 5. By setting the brightness codec block width nCbW equal to cbWidth[[ / SubWidthC]], setting the brightness codec block height nCbH equal to cbHeight[[ / SubHeightC]], and the sample array predSamplesLACr and predSamplesLB Cr As well as the variable triangleDir and the variable cIdx equal to 2, the weighted sample prediction process of the triangle Merge mode specified in clause 8.5.7.2 is called as input to derive the predicted samples predSamples in the current chroma component Cr codec block. Cr [x C ][y C ], where x C = 0..cbWidth / SubWidthC–1 and y C =0..cbHeight / SubHeightC-1.

[0533] 6. Call the motion vector storage process of the Merge triangle mode specified in clause 8.5.7.3, with the luma codec block position (xCb, yCb), luma codec block width cbWidth, luma codec block height cbHeight, segmentation direction triangleDir, luma motion vectors mvA and mvB, reference indices refIdxA and refIdxB, and prediction list flags predListFlagA and predListFlagB as input.

[0534] 8.5.7.2 Weighted Sample Point Prediction Process for Triangle Merge Mode

[0535] The inputs to this process are:

[0536] – Two variables nCbW and nCbH specify the width and height of the current luminance codec block,

[0537] – Two (nCbW / SubWidthC)x(nCbH / SubHeightC) arrays predSamplesLA

[0538] and predSamplesLB,

[0539] – Variable triangleDir, specifies the direction of segmentation,

[0540] –Variable cIdx, specifies the color component index.

[0541] The output of this process is the (nCbW / SubWidthC)x(nCbH / SubHeightC) array pbSamples of prediction sample values.

[0542] The variable nCbR is derived as follows:

[0543] nCbR=(nCbW>nCbH)? (nCbW / nCbH):(nCbH / nCbW) (8-841)

[0544] The variable bitDepth is derived as follows:

[0545] – If cIdx is equal to 0, then bitDepth is set equal to BitDepth Y .

[0546] – Otherwise, bitDepth is set equal to BitDepth C .

[0547] The variables shift1 and offset1 are derived as follows:

[0548] – The variable shift1 is set equal to Max(5, 17-bitDepth).

[0549] –The variable offset1 is set equal to 1<<(shift1-1).

[0550] Depending on the values ​​of triangleDir[[, wS and cIdx]], the prediction samples pbSamples[x][y] are derived as follows, where x = 0..nCbW / SubWidthC-1 and y = 0..nCbH / SubHeightC-1:

[0551] – The variables xIdx and yIdx are derived as follows:

[0552] xIdx=(cIdx==0)? x:x*SubWidthC

[0553] yIdx=(cIdx==0)? y:y*SubHeightC

[0554] – The variable [[wIdx]]wValue that specifies the predicted sample weight is derived as follows:

[0555] – If [[cIdx equals 0 and ]]triangleDir equals 0, then the following applies:

[0556] [[wIdx]]wValue=(nCbW>nCbH)? (Clip3(0,8,(xIdx / nCbR-yIdx)+4)):(Clip3(0,8,(xIdx-yIdx / nCbR)+4)) (8-842)

[0557] – Otherwise, if cIdx is equal to 0 and triangleDir is equal to 1, then the following applies:

[0558] [[wIdx]]wValue=(nCbW>nCbH)? (Clip3(0,8,(nCbH-1-xIdx / nCbR-yIdx)+4))(Clip3(0,8,(nCbW-1-xIdx-yIdx / nCbR)+4)) (8-843)

[0559] –[[Otherwise, if cIdx is greater than 0 and triangleDir is equal to 0, then the following applies: wIdx = (nCbW>nCbH)? (Clip3(0,4,(x / nCbR-y)+2)):(Clip3(0,4,(xy / nCbR)+2)) (8-844)

[0560] – Otherwise (if cIdx is greater than 0 and triangleDir is equal to 1), the following applies:

[0561] wIdx=(nCbW>nCbH)? (Clip3(0,4,(nCbH-1-x / nCbR-y)+2)): (Clip3(0,4,(nCbW-1-xy / nCbR)+2)) (8-845)

[0562] – Use wIdx and cIdx to derive the variable wValue that specifies the prediction sample weight, as follows: wValue = (cIdx == 0)? Clip3(0,8,wIdx):Clip3(0,8,wIdx*2)

[0563] (8-846)]]

[0564] – The predicted sample point values ​​are derived as follows:

[0565] pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(predSamplesLA[x][y]*wValue+predSamplesLB[x][y]*(8-wValue)+offset1)> >shift1) (8-847)

[0566] 5.3 Example 3 of TPM Conditioned on Block Aspect Ratio

[0567] 7.3.8.7 Merge Data Syntax

[0568]

[0569] 7.4.9.7 Merge Data Semantics

[0570] The variable MergeTriangleFlag[x0][y0] specifies whether triangle-based motion compensation is used to generate prediction samples for the current codec unit when decoding B slices. The variable MergeTriangleFlag[x0][y0] is derived as follows:

[0571] – Set MergeTriangleFlag[x0][y0] to 1 if all of the following are true:

[0572] –sps_triangle_enabled_flag is equal to 1.

[0573] –slice_type is equal to B.

[0574] –general_merge_flag[x0][y0] is equal to 1.

[0575] –MaxNumTriangleMergeCand is greater than or equal to 2.

[0576] –cbWidth*cbHeight is greater than or equal to 64.

[0577] –regular_merge_flag[x0][y0] is equal to 0.

[0578] –merge_subblock_flag[x0][y0] is equal to 0.

[0579] –ciip_flag[x0][y0] is equal to 0.

[0580] –Abs(Log2(cbWidth)-Log2(cbHeight)) is less than or equal to 2

[0581] – Otherwise, set MergeTriangleFlag[x0][y0] equal to 0.

[0582] 5.4 Example #4 of TPM with block width < 128 and block height < 128

[0583] 7.3.8.7 Merge Data Syntax

[0584]

[0585] 7.4.9.7 Merge Data Semantics

[0586] The variable MergeTriangleFlag[x0][y0] specifies whether triangle-based motion compensation is used to generate prediction samples for the current codec unit when decoding B slices. The variable MergeTriangleFlag[x0][y0] is derived as follows:

[0587] – Set MergeTriangleFlag[x0][y0] equal to 1 if all of the following are true:

[0588] –sps_triangle_enabled_flag is equal to 1.

[0589] –slice_type is equal to B.

[0590] –general_merge_flag[x0][y0] is equal to 1.

[0591] –MaxNumTriangleMergeCand is greater than or equal to 2.

[0592] –cbWidth*cbHeight is greater than or equal to 64.

[0593] –regular_merge_flag[x0][y0] is equal to 0.

[0594] –merge_subblock_flag[x0][y0] is equal to 0.

[0595] –ciip_flag[x0][y0] is equal to 0.

[0596] –cbWidth is less than 128.

[0597] –cbHeight is less than 128.

[0598] – Otherwise, set MergeTriangleFlag[x0][y0] to 0.

[0599] 5.5 Example #5 of TPM with block width > 4 and block height > 4

[0600] 7.3.8.7 Merge Data Syntax

[0601]

[0602] 7.4.9.7 Merge Data Semantics

[0603] The variable MergeTriangleFlag[x0][y0] specifies whether triangle-based motion compensation is used to generate prediction samples for the current codec unit when decoding B slices. The variable MergeTriangleFlag[x0][y0] is derived as follows:

[0604] – Set MergeTriangleFlag[x0][y0] equal to 1 if all of the following are true:

[0605] –sps_triangle_enabled_flag is equal to 1.

[0606] –slice_type is equal to B.

[0607] –general_merge_flag[x0][y0] is equal to 1.

[0608] –MaxNumTriangleMergeCand is greater than or equal to 2.

[0609] –cbWidth*cbHeight is greater than or equal to 64.

[0610] –regular_merge_flag[x0][y0] is equal to 0.

[0611] –merge_subblock_flag[x0][y0] is equal to 0.

[0612] –ciip_flag[x0][y0] is equal to 0.

[0613] –cbWidth is greater than 4

[0614] –cbHeight is greater than 4

[0615] – Otherwise, set MergeTriangleFlag[x0][y0] equal to 0.

[0616] 5.6 Example 6 of ISP signaling independent of minimum and maximum transform sizes

[0617] 7.3.8.5 Codec unit syntax

[0618]

[0619] 5.7 Example 7 of ISP for blocks larger than the maximum transform size

[0620] 7.3.8.6 Codec unit syntax

[0621]

[0622]

[0623] 5.8 Example 8 of ISP for block sizes larger than 16 pixels

[0624] 7.3.8.7 Codec unit syntax

[0625]

[0626] 5.9 Example of MV rounding.

[0627] Changes to the Working Draft

[0628] The working draft specified in JVET-O2001-v14 has been changed as follows. New additions are highlighted in bold and italics. Removed sections are marked with double square brackets.

[0629] 8.5.5.3 Derivation Process of Sub-Block-Based Time-Domain Merge Candidates

[0630] The inputs to this process are:

[0631] -…

[0632] The output of this process is:

[0633] -….

[0634] …

[0635] – Invoke the motion vector rounding process as specified in clause 8.5.2.14 with mvX set equal to tempMv[0], rightShift set equal to 4, and leftShift set equal to 0 as inputs, and the rounded tempMv[0] as output.

[0636] – Call the motion vector rounding process as specified in clause 8.5.2.14 with mvX set equal to tempMv[1], rightShift set equal to 4, and leftShift set equal to 0 as inputs, and the rounded tempMv[1] as output.

[0637] – For xSbIdx=0..numSbX-1 and ySbIdx=0..numSbY-1, the motion vector mvLXSbCol[xSbIdx][ySbIdx] and the prediction list are derived using the flag predFlagLXSbCol[xSbIdx][ySbIdx] as follows:

[0638] – The luma position (xSb, ySb) of the top left sample of the current codec sub-block relative to the top left luma sample of the current picture is derived as follows:

[0639] xSb=xCb+xSbIdx*sbWidth+sbWidth / 2 (8-551)

[0640] ySb=yCb+ySbIdx*sbHeight+sbHeight / 2 (8-552)

[0641] – The positions of the collocated sub-blocks within ColPic (xColSb, yColSb) are derived as follows.

[0642] – The following apply:

[0643] yColSb=Clip3(yCtb,Min(CurPicHeightInSamplesY-1,yCtb+(1<<CtbLog2SizeY)-1),ySb+[[(]]tempMv[1][[> >4)]]) (8-553)

[0644] – If subpic_treated_as_pic_flag[SubPicIdx] is equal to 1, the following applies:

[0645] xColSb=Clip3(xCtb,Min(SubPicRightBoundaryPos,xCtb+(1<<CtbLog2SizeY)+3),xSb+[[(]]tempMv[0][[> >4)]]) (8-554)

[0646] Otherwise (subpic_treated_as_pic_flag[SubPicIdx] is equal to 0), the following applies: xColSb = Clip3(xCtb, Min(CurPicWidthInSamplesY-1, xCtb+(1<<CtbLog2SizeY)+3),xSb+[[(]]tempMv[0][[> >4)]]) (8-555)

[0647] …

[0648] 8.5.5.4 Derivation Process of Sub-Block-Based Temporal Merge Basic Motion Data

[0649] The inputs to this process are:

[0650] -…

[0651] The output of this process is:

[0652] -….

[0653] The variable tempMv is set as follows:

[0654] tempMv[0]=0 (8-558)

[0655] tempMv[1]=0 (8-559)

[0656] The variable currPic specifies the current picture.

[0657] When availableFlagA1 is equal to TRUE, the following applies:

[0658] – tempMv is set equal to mvL0A1 if all of the following conditions are true:

[0659] –predFlagL0A1 is equal to 1,

[0660] –DiffPicOrderCnt(ColPic, RefPicList[0][refIdxL0A1]) is equal to 0,

[0661] – Otherwise, if all of the following are true, set tempMv equal to mvL1A1:

[0662] –slice_type is equal to B,

[0663] –predFlagL1A1 is equal to 1,

[0664] –DiffPicOrderCnt(ColPic, RefPicList[1][refIdxL1A1]) is equal to 0.

[0665] – Call the motion vector rounding process as specified in clause 8.5.2.14 with mvX set equal to tempMv[0], rightShift set equal to 4, and leftShift set equal to 0 as inputs, and the rounded tempMv[0] as output.

[0666] – Call the motion vector rounding process as specified in clause 8.5.2.14 with mvX set equal to tempMv[1], rightShift set equal to 4, and leftShift set equal to 0 as inputs, and the rounded tempMv[1] as output.

[0667] The position (xColCb, yColCb) of the co-located block within ColPic is derived as follows.

[0668] – The following apply:

[0669] yColCb=Clip3(yCtb,Min(CurPicHeightInSamplesY-1,yCtb+(1<<CtbLog2SizeY)-1),yColCtrCb+[[(]]tempMv[1][[> >4)]]) (8-560)

[0670] – If subpic_treated_as_pic_flag[SubPicIdx] is equal to 1, the following applies:

[0671] xColCb=Clip3(xCtb,Min(SubPicRightBoundaryPos,xCtb+(1<<CtbLog2SizeY)+3),xColCtrCb+[[(]]tempMv[0][[> >4)]]) (8-561)

[0672] – Otherwise (subpic_treated_as_pic_flag[SubPicIdx] is equal to o), the following applies:

[0673] xColCb=Clip3(xCtb,Min(CurPicWidthInSamplesY-1,xCtb+(1<<CtbLog2SizeY)+3),xColCtrCb+[[(]]tempMv[0][[> >4)]]) (8-562)

[0674] 5.10 Example of Sub-TMVP

[0675] 8.5.5.2 Motion Vector and Reference Index Derivation Process in Sub-Block Merge Mode

[0676] The inputs to this process are:

[0677] – the luma position (xCb, yCb) of the top left sample of the current luma codec block relative to the top left luma sample of the current picture,

[0678] –Two variables cbWidth and cbHeight specify the width and height of the luma codec block.

[0679] The output of this process is:

[0680] – The number of luminance codec sub-blocks in the horizontal direction numSbX and the vertical direction numSbY,

[0681] – reference indices refIdxL0 and refIdxL1,

[0682] – The prediction list uses the flag arrays predFlagL0[xSbIdx][ySbIdx] and predFlagL1[xSbIdx][ySbIdx],

[0683] – Luma subblock motion vector arrays mvL0[xSbIdx][ySbIdx] and mvL1[xSbIdx][ySbIdx] with 1 / 16 fractional sample accuracy, where xSbIdx = 0..numSbX-1, ySbIdx = 0..numSbY-1,

[0684] – Chroma sub-block motion vector arrays mvCL0[xSbIdx][ySbIdx] and mvCL1[xSbIdx][ySbIdx] with 1 / 32 fractional sample accuracy, where xSbIdx = 0..numSbX-1, ySbIdx = 0..numSbY-1,

[0685] – Bidirectional prediction weight index bcwIdx.

[0686] The variables numSbXAff and numSbYAff are set as follows.

[0687] numSbXAff=cbWidth>>2

[0688] numSbYAff=cbHeight>>2

[0689] The variables numSbX, numSbY and subblock Merge candidate list subblockMergeCandList are derived through the following ordered steps:

[0690] 1. When sps_sbtmvp_enabled_flag is equal to 1, the following applies:

[0691] – For the export of availableFlagA1, refIdxLXA1, predFlagLXA1 and mvLXA1,

[0692] The following applies:

[0693] – The luma position (xNbA1, yNbA1) within the adjacent luma codec block is set equal to (xCb-1, yCb+cbHeight-1).

[0694] – Call the derivation process of neighboring block availability as specified in clause 6.4.4, with the current luma position (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma position (xNbA1, yNbA1), checkPredModeY set equal to true, and cIdx set equal to 0 as input, and assign the output to the block availability flag availableA1.

[0695] – The variables availableFlagA1, refIdxLXA1, predFlagLXA1 and mvLXA1 are derived as follows:

[0696] – If availableA1 is equal to false, availableFlagA1 is set equal to 0, both components of mvLXA1 are set equal to 0, refIdxLXA1 is set equal to -1, and predFlagLXA1 is set equal to 0, where X is 0 or 1 and bcwIdxA1 is set equal to 0.

[0697] – Otherwise, availableFlagA1 is set equal to 1 and the following assignments are made:

[0698] mvLXA1=MvLX[xNbA1][yNbA1] (8-498)

[0699] refIdxLXA1=RefIdxLX[xNbA1][yNbA1] (8-499)

[0700] predFlagLXA1=PredFlagLX[xNbA1][yNbA1] (8-500)

[0701] – Call the derivation process of the sub-block based temporal Merge candidate as specified in clause 8.5.5.3, with the luma position (xCb, yCb), luma codec block width cbWidth, luma codec block height cbHeight, availability flag availableFlagA1, reference index refIdxLXA1, prediction list utilization flag predFlagLXA1 and motion vector mvLXA1 as input, and output is the availability flag availableFlagSbC ol, the number of luma codec sub-blocks in the horizontal direction numSbXCol and the vertical direction numSbYCol, the reference index refIdxLXSbCol, the luma motion vector mvLXSbCol[xSbIdx][ySbIdx] and the prediction list utilization flag predFlagLXSbCol[xSbIdx][ySbIdx], where xSbIdx=0..numSbXCol-1, ySbIdx=0..numSbYCol-1 and X is 0 or 1.

[0702] 2. When sps_affine_enabled_flag is equal to 1, the sample positions (xNbA0, yNbA0), (xNbA1, yNbA1), (xNbA2, yNbA2), (xNbB0, yNbB0), (xNbB1, yNbB1), (xNbB2, yNbB2), (xNbB3, yNbB3) and the variables numSbXAff and numSbYAff are derived as follows:

[0703] (xA0,yA0)=(xCb-1,yCb+cbHeight) (8-501)

[0704] (xA1,yA1)=(xCb-1,yCb+cbHeight-1) (8-502)

[0705] (xA2,yA2)=(xCb-1,yCb) (8-503)

[0706] (xB0,yB0)=(xCb+cbWidth,yCb-1) (8-504)

[0707] (xB1,yB1)=(xCb+cbWidth-1,yCb-1) (8-505)

[0708] (xB2,yB2)=(xCb-1,yCb-1) (8-506)

[0709] (xB3,yB3)=(xCb,yCb-1) (8-507)

[0710] [[numSbXAff=cbWidth>>2 (8-508)

[0711] numSbYAff=cbHeight>>2 (8-509)]]3. When sps_affine_enabled_flag is equal to 1, the variable availableFlagA is set equal to false, and the following applies to (xNbA k ,yNbA k )From (xNbA0,yNbA0) to (xNbA1,yNbA1):

[0712] …

[0713] 8. When numCurrMergeCand is less than MaxNumSubblockMergeCand, the following operations are repeated until numCurrMergeCand is equal to MaxNumSubblockMergeCand, where both mvZero[0] and mvZero[1] are equal to 0:

[0714] – Reference index, prediction list utilization flag and zeroCand m The motion vector is derived as follows, where m is equal to (numCurrMergeCand-numOrigMergeCand):

[0715] refIdxL0ZeroCand m =0 (8-515)

[0716] predFlagL0ZeroCand m =1 (8-516)

[0717] cpMvL0ZeroCand m [0] = mvZero (8-517)

[0718] cpMvL0ZeroCand m [1]=mvZero (8-518)

[0719] cpMvL0ZeroCand m [2]=mvZero (8-519)

[0720] refIdxL1ZeroCand m =(slice_type==B)? 0:-1 (8-520)

[0721] predFlagL1ZeroCandm =(slice_type==B)? 1:0 (8-521)

[0722] cpMvL1ZeroCand m [0] = mvZero (8-522)

[0723] cpMvL1ZeroCand m [1]=mvZero (8-523)

[0724] cpMvL1ZeroCand m [2]=mvZero (8-524)

[0725] motionModelIdcZeroCand m =1 (8-525)

[0726] bcwIdxZeroCand m =0 (8-526)

[0727] – Add candidate zeroCand with m equal to (numCurrMergeCand-numOrigMergeCand) at the end of subblockMergeCandList m and increase numCurrMergeCand by 1, as shown below:

[0728] subblockMergeCandList[numCurrMergeCand++]=zeroCand m (8-527)

[0729] The variables refIdxL0, refIdxL1, predFlagL0[xSbIdx][ySbIdx], predFlagL1[xSbIdx][ySbIdx], mvL0[xSbIdx][ySbIdx], mvL1[xSbIdx][ySbIdx], mvCL0[xSbIdx][ySbIdx], and mvCL1[xSbIdx][ySbIdx] are derived as follows, where xSbIdx = 0..numSbX-1, ySbIdx = 0..numSbY-1:

[0730] – If subblockMergeCandList[merge_subblock_idx[xCb][yCb]] is equal to SbCol, then numSbX is set equal to numSbXCol, numSbY is set equal to numSbYCol, the bidirectional prediction weight index bcwIdx is set to 0, and the following applies, where X is 0 or 1:

[0731] refIdxLX=refIdxLXSbCol (8-528)

[0732] – For xSbIdx=0..numSbX-1, ySbIdx=0..numSbY-1, the following applies:

[0733] predFlagLX[xSbIdx][ySbIdx]=predFlagLXSbCol[xSbIdx][ySbIdx] (8-529)

[0734] mvLX[xSbIdx][ySbIdx][0]=mvLXSbCol[xSbIdx][ySbIdx][0] (8-530)

[0735] mvLX[xSbIdx][ySbIdx][1]=mvLXSbCol[xSbIdx][ySbIdx][1] (8-531)

[0736] – When predFlagLX[xSbIdx][ySbIdx] is equal to 1, the derivation process of chroma motion vectors in clause 8.5.2.13 is called with mvLX[xSbIdx][ySbIdx] and refIdxLX as input and the output is mvCLX[xSbIdx][ySbIdx].

[0737] – For x = xCb..xCb + cbWidth–1 and y = yCb..yCb + cbHeight–1, the following assignments are made:

[0738] MotionModelIdc[x][y]=0 (8-532)

[0739] Otherwise (subblockMergeCandList[merge_subblock_idx[xCb][yCb]] is not equal to SbCol), numSbX is set equal to numSbXAff, numSbY is set equal to numSbYAff, and the following applies, where X is 0 or 1:

[0740] - Perform the following allocation, where N is the candidate at position merge_subblock_idx[xCb][yCb] in the subblock Merge candidate list subblockMergeCandList (N=subblockMergeCandList[merge_subblock_idx[xCb][yCb]]):

[0741] Figure 10 1 is a block diagram illustrating an example video processing system 1000 that may implement various techniques disclosed herein. Various implementations may include some or all of the components of system 1000. System 1000 may include an input 1002 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8- or 10-bit multi-component pixel values), or may be received in a compressed or encoded format. Input 1002 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces (such as Ethernet, a passive optical network (PON), etc.) and wireless interfaces (such as Wi-Fi or cellular interfaces).

[0742] System 1000 may include a codec component 1004 that can implement the various codecs or encoding methods described in this document. The codec component 1004 can reduce the average bit rate of the video from the input 1002 of the codec component 1004 to the output of the codec component 1004 to produce a codec representation of the video. Therefore, codec technology is sometimes referred to as video compression or video transcoding technology. The output of the codec component 1004 can be stored or transmitted via a connected communication such as represented by component 1006. The stored or communicated bitstream (or codec) representation of the video received at input 1002 can be used by component 1008 to generate pixel values ​​or displayable video, which is sent to display interface 1010. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it will be understood that the encoding tools or operations are used at the encoder, and the corresponding decoding tools or operations that are the opposite of the encoding results will be performed by the decoder.

[0743] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), or DisplayPort, etc. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The techniques described in this document may be implemented in various electronic devices, such as mobile phones, laptop computers, smart phones, or other devices capable of performing digital data processing and / or video display.

[0744] Figure 11is a block diagram of a video processing device 1100. Device 1100 can be used to implement one or more methods described herein. Device 1100 can be implemented in a smartphone, tablet computer, computer, Internet of Things (IoT) receiver, etc. Device 1100 may include one or more processors 1102, one or more memories 1104, and video processing hardware 1106. (Multiple) processors 1102 can be configured to implement one or more methods described in this document. Memory(s) 1104 can be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 1106 can be used to implement some of the techniques described in this document in hardware circuits. In some embodiments, hardware 1106 can be entirely or partially in processor 1101, for example as a graphics processor.

[0745] Figure 16 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure.

[0746] like Figure 16 As shown in , a video codec system 100 may include a source device 110 and a destination device 120. The source device 110 generates encoded video data, which may be referred to as a video encoding device. The destination device 120 may decode the encoded video data generated by the source device 110, which may be referred to as a video decoding device.

[0747] Source device 110 may include a video source 112 , a video encoder 114 , and an input / output (I / O) interface 116 .

[0748] The video source 112 may include a source (such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system for generating video data, or a combination of these sources). The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bitstream. The bitstream may include a sequence of bits that form a codec representation of the video data. The bitstream may include codec pictures and associated data. A codec picture is a codec representation of a picture. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The encoded video data may be sent directly to the destination device 120 via the I / O interface 116 via the network 130a. The encoded video data may also be stored on a storage medium / server 130b for access by the destination device 120.

[0749] Destination device 120 may include an I / O interface 126 , a video decoder 124 , and a display device 122 .

[0750] I / O interface 126 may include a receiver and / or a modem. I / O interface 126 may obtain encoded video data from source device 110 or storage medium / server 130b. Video decoder 124 may decode the encoded video data. Display device 122 may display the decoded video data to a user. Display device 122 may be integrated with destination device 120 or may be external to destination device 120, configured to interface with an external display device.

[0751] The video encoder 114 and the video decoder 124 may operate according to a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVC) standard, and other current and / or future standards.

[0752] Figure 17 is a block diagram illustrating an example of a video encoder 200, which may be Figure 16 The video encoder 114 in the system 100 is shown in FIG.

[0753] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. Figure 17 In the example of , video encoder 200 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of video encoder 200. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0754] The functional components of the video encoder 200 may include a segmentation unit 201, a prediction unit 202 (which may include the prediction unit 202 of the mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205 and an intra-frame prediction unit 206), a residual generation unit 207, a transform unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transform unit 211, a reconstruction unit 212, a buffer 213 and an entropy coding unit 214.

[0755] In other examples, the video encoder 200 may include more, fewer, or different functional components. In one example, the prediction unit 202 may include an intra block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode in which at least one reference picture is the picture in which the current video block is located.

[0756] Furthermore, some components such as the motion estimation unit 204 and the motion compensation unit 205 may be highly integrated but are not shown for the purpose of explanation. Figure 17 In the examples, they are respectively represented.

[0757] The segmentation unit 201 may segment a picture into one or more video blocks. The video encoder 200 and the video decoder 300 may support various video block sizes.

[0758] The mode selection unit 203 can, for example, select one of the intra or inter coding modes based on the error result, and provide the resulting intra or inter coding block to the residual generation unit 207 to generate residual block data, and provide the resulting intra or inter coding block to the reconstruction unit 212 to reconstruct the coding block for use as a reference picture. In some examples, the mode selection unit 203 can select a combined intra prediction and inter prediction (CIIP) mode, in which the prediction is based on inter prediction signaling and intra prediction signaling. In the case of inter prediction, the mode selection unit 203 can also select a resolution of the motion vector (e.g., sub-pixel or integer pixel precision) for the block.

[0759] To perform inter-frame prediction on the current video block, the motion estimation unit 204 may generate motion information for the current video block by comparing the current video block with one or more reference frames from the buffer 213. The motion compensation unit 205 may determine a predicted video block for the current video block based on decoded samples and motion information of pictures other than the picture associated with the current video block from the buffer 213.

[0760] For example, motion estimation unit 204 and motion compensation unit 205 may perform different operations on the current video block depending on whether the current video block is in an I slice, a P slice, or a B slice.

[0761] In some examples, motion estimation unit 204 may perform unidirectional prediction on the current video block, and motion estimation unit 204 may search for a reference picture in list 0 or list 1 of the reference video block for the current video block. Motion estimation unit 204 may then generate a reference index indicating the reference picture in list 0 or list 1 containing the reference video block, and a motion vector indicating the spatial displacement between the current video block and the reference video block. Motion estimation unit 204 may output the reference index, prediction direction indicator, and motion vector as motion information for the current video block. Motion compensation unit 205 may generate a predicted video block for the current block based on the reference video block indicated by the motion information of the current video block.

[0762] In other examples, the motion estimation unit 204 may perform bidirectional prediction on the current video block. The motion estimation unit 204 may search for reference pictures in list 0 of the reference video block for the current video block and may also search for reference pictures in list 1 of another reference video block for the current video block. The motion estimation unit 204 may then generate reference indexes indicating the reference pictures in list 0 and list 1 containing the reference video block, and a motion vector indicating the spatial displacement between the reference video block and the current video block. The motion estimation unit 204 may output the motion vector and reference index of the current video block as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0763] In some examples, motion estimation unit 204 may output the full set of motion information for use in the decoding process of the decoder.

[0764] In some examples, motion estimation unit 204 may not output a full set of motion information for the current video. Instead, motion estimation unit 204 may reference motion information of another video block to signal the motion information of the current video block. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of a neighboring video block.

[0765] In one example, motion estimation unit 204 may indicate a value in a syntax structure associated with the current video block that indicates to video decoder 300 that the current video block has the same motion information as another video block.

[0766] In another example, the motion estimation unit 204 may identify another video block and a motion vector difference (MVD) in a syntax structure associated with the current video block. The motion vector difference indicates the difference between the motion vector of the current video block and the motion vector of the indicated video block. The video decoder 300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0767] As discussed above, the video encoder 200 may predictively signal motion vectors.Two examples of predictive signaling techniques that may be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and Merge mode signaling.

[0768] The intra-frame prediction unit 206 can perform intra-frame prediction on the current video block. When the intra-frame prediction unit 206 performs intra-frame prediction on the current video block, the intra-frame prediction unit 206 can generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block can include the predicted video block and various syntax elements.

[0769] The residual generation unit 207 may generate residual data for the current video block by subtracting (e.g., indicated by a minus sign) the predicted video block(s) of the current video block from the current video block. The residual data for the current video block may include residual video blocks corresponding to different sample components of the samples in the current video block.

[0770] In other examples, such as in skip mode, there may be no residual data for the current video block, and the residual generation unit 207 may not perform a subtraction operation.

[0771] Transform processing unit 208 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video block associated with the current video block.

[0772] After transform processing unit 208 generates a transform coefficient video block associated with the current video block, quantization unit 209 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0773] The inverse quantization unit 210 and the inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct a residual video block from the transform coefficient video block. The reconstruction unit 212 may add the reconstructed residual video block to corresponding samples of one or more prediction video blocks generated by the prediction unit 202 to generate a reconstructed video block associated with the current block for storage in the buffer 213.

[0774] After the reconstruction unit 212 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking artifacts in the video block.

[0775] The entropy encoding unit 214 may receive data from other functional components of the video encoder 200. When the entropy encoding unit 214 receives the data, the entropy encoding unit 214 may perform one or more entropy encoding operations to generate entropy-encoded data and output a bitstream including the entropy-encoded data.

[0776] Figure 18 is a block diagram illustrating an example of a video decoder 300, which may be Figure 16 The video decoder 114 in the system 100 is shown in FIG.

[0777] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. Figure 18 In the example of FIG, video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of video decoder 300. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0778] exist Figure 18 In the example of FIG, the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 can perform operations generally related to the video encoder 200 (e.g., Figure 17 ) is the decoding process that is the inverse of the encoding process described.

[0779] The entropy decoding unit 301 can retrieve a coded bitstream. The coded bitstream can include entropy-coded video data (e.g., coded blocks of video data). The entropy decoding unit 301 can decode the entropy-coded video data, and the motion compensation unit 302 can determine motion information including motion vectors, motion vector precision, reference picture list index, and other motion information from the entropy-decoded video data. The motion compensation unit 302 can determine such information, for example, by implementing AMVP and Merge modes.

[0780] The motion compensation unit 302 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of an interpolation filter to be used with sub-pixel precision may be included in the syntax element.

[0781] Motion compensation unit 302 may use interpolation filters, such as those used by video encoder 20, during encoding of a video block to calculate interpolated values ​​for sub-integer pixels of a reference block. Motion compensation unit 302 may determine the interpolation filters used by video encoder 200 based on received syntax information and use the interpolation filters to produce a prediction block.

[0782] The motion compensation unit 302 may use some syntax information to determine the size of blocks used to encode frame(s) and / or slice(s) of the coded video sequence, partitioning information for each macroblock describing how the pictures of the coded video sequence are partitioned, a mode indicating how each partition is to be encoded, one or more reference frames (and reference frame lists) for each inter-coded block, and other information used to decode the coded video sequence.

[0783] The intra prediction unit 303 can use, for example, an intra prediction mode received in the bitstream to form a prediction block from spatially adjacent blocks. The inverse quantization unit 303 inversely quantizes (i.e., dequantizes) the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 303 applies an inverse transform.

[0784] The reconstruction unit 306 can add the residual block to the corresponding prediction block generated by the motion compensation unit 202 or the intra prediction unit 303 to form a decoded block. If necessary, a deblocking filter can also be applied to the decoded block to remove blocking artifacts. The decoded video block is then stored in the buffer 307, which provides reference blocks for subsequent motion compensation.

[0785] Some embodiments of the disclosed technology include making a decision or determination to enable a video processing tool or mode. In an example, when a video processing tool or mode is enabled, the encoder will use or implement the tool or mode in processing blocks of the video, but will not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, when a video processing tool or mode is enabled based on the decision or determination, the conversion from blocks of the video to a bitstream representation of the video will use the video processing tool or mode. In another example, when a video processing tool or mode is enabled, the decoder will process the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, the conversion from the bitstream representation of the video to blocks of the video will be performed using the video processing tool or mode enabled based on the decision or determination.

[0786] Some embodiments of the disclosed technology include making a decision or determination to disable a video processing tool or mode. In one example, when the video processing tool or mode is disabled, the encoder will not use the tool or mode in converting blocks of video to a bitstream representation of the video. In another example, when the video processing tool or mode is disabled, the decoder will process the bitstream knowing that the bitstream has been modified using the video processing tool or mode enabled based on the decision or determination.

[0787] In this document, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of the current video block may correspond to bits that are co-located or distributed throughout the bitstream, as defined by the syntax. For example, a macroblock may be encoded based on error residual values ​​from transforms and codecs, and also using bits from headers and other fields in the bitstream.

[0788] In some embodiments, the following first set of clauses may be implemented.

[0789] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 1).

[0790] 1. A method for video processing (e.g., Figure 12), comprising: for a conversion between a video unit comprising a luma block and a chroma block co-located with the luma block and a codec representation of the video unit, determining (1202) chroma weights for conversion of the chroma blocks using a triangular partitioning pattern (TPM) by aligning the chroma weights with luma weights for conversion of the luma block; and performing (1204) the conversion based on a result of the determining.

[0791] 2. A method according to clause 1, wherein the chrominance weight is determined as a function of the luma weight.

[0792] 3. A method according to any of clauses 1-2, wherein the chrominance weights are a subset of the luma weights.

[0793] 4. A method according to any of clauses 1-3, wherein for equal-sized portions of the luma block that coincide with the chroma block, the chroma weights are equal to the luma weights.

[0794] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 2).

[0795] 5. A method of video processing, comprising: for a conversion between a video unit including a luma block and a chroma block co-located with the luma block and a codec representation of the video unit, determining a chroma weight for conversion of the chroma block using a triangular partitioning pattern (TPM) based on a characteristic of the luma block or a characteristic of the video unit; and performing the conversion based on a result of the determination.

[0796] 6. The method of clause 5, wherein the characteristic of the luminance block comprises a height or a width of the luminance block.

[0797] 7. The method of any of clauses 5-6, wherein the characteristic of the video unit comprises a color format of the video unit or a chroma subsampling rate of the video unit.

[0798] 8. A method according to any of clauses 5-7, wherein the chroma weights further depend on the colour component identities of the chroma blocks.

[0799] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 3).

[0800] 9. A method according to any one of clauses 1-8, wherein the chroma weight and / or the luma weight is equal to an integer.

[0801] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 4).

[0802] 10. A method of video processing, comprising: for conversion between a video unit of a video including a luma block and a chroma block co-located with the luma block and a codec representation of the video unit, determining, based on characteristics of the video unit, whether a triangle partitioning mode (TPM) is used for the conversion; and performing the conversion based on a result of the determination.

[0803] 11. The method of clause 10, wherein the characteristic is a dimensionality ratio equal to max(H,W) / min(H,W), where max and min are maximum and minimum functions, and H and W are the height and width of the video unit in pixels.

[0804] 12. The method of clause 10, wherein the characteristic is a dimensionality ratio equal to Abs(Log2(cbWidth)-Log2(cbHeight)), where Abs is an absolute function and cbWidth and cbHeight are the pixel width and pixel height of the chroma block.

[0805] 13. The method of clause 10, wherein the determining results in disabling the TPM due to the dimensionality ratio being greater than 2.

[0806] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 5).

[0807] 14. The method of clause 10, wherein the characteristics of the video unit include a maximum transform size for conversion of the video.

[0808] 15. The method of clause 14, wherein the determining disables use of the TPM because a height or width of the video unit is greater than the maximum transform size.

[0809] The following items can be implemented in conjunction with the additional techniques described in the items listed in the previous section (e.g., item 6).

[0810] 16. The method of clause 10, wherein the characteristics of the video unit include a maximum codec unit size used during conversion of the video.

[0811] 17. The method of clause 16, wherein the determining disables use of the TMP because the height or width of the video unit is equal to the maximum codec unit size.

[0812] The following items can be implemented in conjunction with the additional techniques described in the items listed in the previous section (e.g., item 7).

[0813] 18. The method of clause 10, wherein the characteristic of the video unit comprises a height or a width of the video unit, and wherein the determination disables use of a TMP because the height is greater than N or the width is greater than M.

[0814] The following items can be implemented in conjunction with the additional techniques described in the items listed in the previous section (e.g., item 8).

[0815] 19. The method of clause 10, wherein the characteristic of the video unit comprises a height or a width of the video unit, and wherein the determination disables use of a TMP because the height is N or the width is M.

[0816] The following items can be implemented in conjunction with the additional techniques described in the items listed in the previous section (e.g., item 9).

[0817] 20. The method of clause 10, wherein the characteristics of the video unit include a chroma format of the video unit, and wherein the determining disables use of a TMP because the chroma format is a particular format.

[0818] 21. The method of clause 20, wherein the specific format is 4:0:0.

[0819] The following items can be implemented with the additional techniques described in the items listed in the previous section (e.g., item 10).

[0820] 22. The method of clause 1, wherein the characteristics of the video unit include resolutions of reference pictures used in conversion of the video unit, and wherein the determining disables use of TMP because the resolutions differ from one another.

[0821] The following items can be implemented in conjunction with the additional techniques described in the items listed in the previous section (e.g., item 11).

[0822] 23. The method of any preceding clause, wherein, in case the TPM mode is determined to be disabled, the codec representation omits syntax elements for TMP syntax elements.

[0823] 24. A method as described in any of clauses 1 to 23, wherein the converting comprises encoding the video into the codec representation.

[0824] 25. A method according to any of clauses 1 to 23, wherein the converting comprises decoding the codec representation to generate pixel values ​​of the video.

[0825] 26. A video decoding apparatus comprising a processor configured to implement the method of one or more of clauses 1 to 25.

[0826] 27. A video encoding apparatus comprising a processor configured to implement the method of one or more of clauses 1 to 25.

[0827] 28. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method of any of clauses 1 to 25.

[0828] 29. The methods, apparatus, or systems described in this document.

[0829] The second set of clauses describes certain features and aspects of the technology disclosed in the previous section (e.g., item 15).

[0830] 1. A method of video processing (e.g., Figure 19 ), comprising: performing (1910) a conversion between a current video block of a video and a bitstream representation of the video according to a rule, wherein a partitioned prediction mode is used for encoding or decoding the current video block, wherein a final prediction of the current video block is determined as a weighted sum of two or more predictions of the current video block; wherein the partitioned prediction mode is a first mode based on a plurality of first partitioning schemes or a second mode based on a plurality of second partitioning schemes; and wherein the rule specifies a codec operation for encoding or decoding using the first mode or the second mode.

[0831] 2. The method of clause 1, wherein the first mode is a triangle partitioning mode and the second mode is a geometric partitioning mode.

[0832] 3. The method of clause 1 or 2, wherein the plurality of first partitioning schemes is a subset of the plurality of second partitioning schemes.

[0833] 4. A method according to clause 2, wherein the geometric partitioning pattern includes the plurality of second partitioning schemes, and wherein at least one of the plurality of second partitioning schemes divides the current video block into two sub-partitions, such that at least one of the two sub-partitions is non-square and non-rectangular.

[0834] 5. The method of clause 2, wherein the geometric partitioning pattern comprises a triangle partitioning pattern.

[0835] 6. The method of clause 1, wherein the first mode is a triangle partitioning mode and the second mode is a non-triangle partitioning mode.

[0836] 7. The method of clause 1, wherein the partition prediction mode is a geometric partition mode that divides the current video block, which is a rectangular block, into two triangular sub-partitions or two non-triangular sub-partitions.

[0837] 8. The method of clause 1, wherein the rules specify that the first mode and the second mode be signaled as a single mode.

[0838] 9. The method of clause 8, wherein the first mode and the second mode share the same control flags at a sequence parameter set (SPS), video parameter set (VPS), activity parameter set (APS), picture parameter set (PPS), slice, sub-picture, slice, brick, virtual pipeline data unit (VPDU), codec tree unit (CTU), transform unit (TU), codec unit (CU), prediction unit (PU), picture header, or slice header level.

[0839] 10. A method as described in clause 8, wherein the first pattern is signaled as a subset of the second pattern.

[0840] 11. The method according to clause 10, wherein the second pattern is defined as comprising N sub-patterns and represented as {M0, M1, M2, ..., M N-1} prediction mode, and the first mode is defined as including X sub-modes and represented as {M0,M k0 ,M k1 ,…,M kX-1} another prediction mode, where {M0,M k0 ,M k1 ,…,M kX-1} is {M0,M1,M2,…,M N-1}, where N is an integer greater than 1 and greater than X.

[0841] 12. A method according to clause 5, wherein a first syntax element is signalled to indicate whether the second mode applies and / or a second syntax element is signalled to indicate whether the first mode applies.

[0842] 13. The method of clause 1, wherein the rules specify that the first mode and the second mode share logic for computing a blending weight mask used to determine the final prediction.

[0843] 14. The method of clause 1, wherein the rule specifies that the first mode and the second mode share logic for computing a motion storage mask for storing motion.

[0844] 15. A method according to clause 13 or 14, wherein for the first mode and the second mode the same table is used to derive the blending weight mask or the motion storage mask.

[0845] 16. A method as described in any of clauses 1 to 15, wherein the converting comprises encoding the video into the bitstream representation.

[0846] 17. A method as described in any of clauses 1 to 15, wherein the converting comprises decoding the bitstream representation to generate the video.

[0847] 18. A video processing device, comprising: a processor configured to implement the method described in any one or more of clauses 1 to 17.

[0848] 19. A computer-readable medium storing program code which, when executed, causes a processor to implement the method of any one or more of clauses 1 to 17.

[0849] 20. A computer-readable medium storing a codec representation or a bitstream representation generated according to any of the above methods.

[0850] The third group of items describes certain features and aspects of the technology disclosed in the previous section (e.g., items 16 to 18).

[0851] 1. A method of video processing, comprising: performing a conversion between a current video block of a video and a bitstream representation of the video, wherein during the conversion, a prediction of the current video block is determined as a weighted sum of two or more predictions of the current video block, and a motion vector storage process for the current video block is determined according to a rule, wherein the current video block uses a partition prediction mode, the partition prediction mode being a first mode based on a plurality of first partitioning schemes or a second mode based on a plurality of second partitioning schemes, and wherein the rule specifies that a process for determining which motion vector to store and how many motion vectors to store is the same for either the first mode or the second mode.

[0852] 2. The method of clause 1, wherein the partitioning prediction mode is a geometric partitioning mode that divides the current video block, which is a rectangular block, into two triangular sub-partitions or two non-triangular sub-partitions.

[0853] 3. The method of clause 1, wherein the first mode and the second mode comprise partitioning the current video block into two or more partitions.

[0854] 4. The method of clause 3, wherein at least one partition resulting from the partitioning of the current video block has angled edges.

[0855] 5. The method of clause 1, wherein the first mode is a triangle partitioning mode and the second mode is a geometric partitioning mode.

[0856] 6. The method of clause 1, wherein the first mode is a triangle partitioning mode and the second mode is a non-triangle partitioning mode.

[0857] 7. A method according to clause 5, wherein the geometric partitioning mode includes the plurality of second partitioning schemes, and wherein at least one of the plurality of second partitioning schemes divides the current video block into two sub-partitions, such that at least one of the two sub-partitions is non-square and non-rectangular.

[0858] 8. The method of clause 5, wherein the geometric partitioning pattern comprises a triangle partitioning pattern.

[0859] 9. The method of clause 1, wherein the rule specifies which motion vector in two inter-predicted partitions is stored for the current video block.

[0860] 10. The method of clause 1, wherein the rule specifies whether to store at least one of an L0 motion vector or an L1 motion vector for the current video block.

[0861] 11. The method of clause 1, wherein the rule specifies that only the motion vectors for allowable combinations of width and height of the current video block are to be stored.

[0862] 12. A method according to clause 1, wherein the rule specifies that each element of the stored motion vector indicates i) one or more motion vectors of one of two or more partitions, ii) multiple motion vectors, and / or iii) stores inter-frame prediction directions for N×N sub-blocks of the current video block, where N is an integer greater than 0.

[0863] 13. The method of clause 12, wherein N is equal to 4.

[0864] 14. The method of clause 1, wherein the rule specifies computing the motion vector based on N predefined tables storing logic, rules, and / or procedures, wherein N is an integer greater than 0.

[0865] 15. The method of clause 1, wherein the rule specifies using a calculation equation to calculate the motion vector storing logic, rules and / or procedures.

[0866] 16. A method of video processing, comprising: performing a conversion between a current block of a video and a bitstream representation of the video, wherein, during the conversion, motion information in 4×4 units is used to determine a prediction block for the current block, and wherein a partitioning mode is used to encode and decode the current block.

[0867] 17. The method of clause 16, wherein the current video block is partitioned into two or more partitions using the partitioning pattern.

[0868] 18. A method according to clause 16, wherein the partitioning mode is a geometric partitioning mode, which includes a plurality of partitioning schemes, and wherein at least one of the plurality of partitioning schemes divides the current video block into two sub-partitions, such that at least one of the two sub-partitions is non-square and non-rectangular.

[0869] 19. The method of clause 18, wherein the geometric partitioning pattern comprises a triangle partitioning pattern.

[0870] 20. The method of clause 16, wherein the partitioning mode is a geometric partitioning mode that divides the current video block, which is a rectangular block, into two triangular sub-partitions or two non-triangular sub-partitions.

[0871] 21. The method of clause 16, wherein at least one segmentation resulting from the segmentation pattern has angled edges.

[0872] 22. The method of clause 16, wherein the partitioning pattern is a triangle partitioning pattern or a geometric partitioning pattern.

[0873] 23. The method of clause 17, wherein at least one of the two or more partitions has a corresponding motion vector for motion compensation.

[0874] 24. The method of clause 16, wherein the 4x4 unit comprises a motion vector for the current video block stored for a spatial or temporal motion vector candidate.

[0875] 25. The method of clause 16, wherein each of the 4x4 sub-blocks of the current video block has its own motion vector, the motion vectors being stored in a buffer.

[0876] 26. A method of video processing, comprising: performing a conversion between a current block of a video and a bitstream representation of the video, wherein the current block is encoded using a partitioned mode, wherein during the conversion, a prediction block for the current block is determined according to a rule by mixing two or more predictions in a mixed region of the current video block, and wherein the rule specifies that L0 motion vectors and L1 motion vectors are stored for sub-blocks belonging to the mixed region of the current video block.

[0877] 27. The method of clause 26, wherein the current video block is partitioned into two or more partitions using the partitioning pattern.

[0878] 28. A method according to clause 26, wherein the partitioning mode is a geometric partitioning mode, the geometric partitioning mode includes a plurality of partitioning schemes, and at least one of the partitioning schemes divides the current video block into two sub-partitions, such that at least one of the two sub-partitions is non-square and non-rectangular.

[0879] 29. The method of clause 28, wherein the geometric partitioning pattern comprises a triangular partitioning pattern.

[0880] 30. The method of clause 26, wherein at least one segmentation resulting from the segmentation pattern has angled edges.

[0881] 31. The method of clause 26, wherein the partitioning pattern is a triangle partitioning pattern or a geometric partitioning pattern.

[0882] 32. The method of clause 27, wherein the mixed region indicates a region overlapped by the two or more partitions.

[0883] 33. A method according to clause 26, wherein, in the weighting process applied to generate the final prediction of the 4x4 sub-block within the mixed area as a weighted sum of prediction samples, the weights of the prediction samples of the 4x4 sub-block within the mixed area are not equal to 0.

[0884] 34. The method of clause 26, wherein the rule specifies that for 4x4 sub-blocks outside a mixed region of the current video block, partitioned uni-directionally predicted motion vectors are stored.

[0885] 35. The method of clause 27, wherein the rule specifies that the two or more partitioned bi-predictive motion vectors are stored for 4x4 sub-blocks belonging to a mixed region of the current video block.

[0886] 36. A method according to clause 35, wherein the rule specifies that in case two partitions have motion vectors from the same direction, one of the minimum, maximum, average or weighted motion vector of the two motion vectors is stored for the sub-block.

[0887] 37. A method according to clause 35, wherein the rule specifies that if two partitions have motion vectors from the same direction, the predefined motion vectors of the two partitions are stored for the sub-block.

[0888] 38. A method as described in any of clauses 1 to 37, wherein performing the conversion includes generating the codec representation from the current video block.

[0889] 39. A method as described in any of clauses 1 to 37, wherein performing the conversion includes generating the current video block from the codec representation.

[0890] 40. A video processing apparatus comprising a processor configured to implement the method of any one or more of clauses 1 to 39.

[0891] 41. A computer-readable medium storing program code which, when executed, causes a processor to implement the method of any one or more of clauses 1 to 39.

[0892] 42. A computer-readable medium storing a codec representation or a bitstream representation generated according to any one of the above methods.

[0893] The fourth group of items describes certain features and aspects of the technology disclosed in the previous section (e.g., item 19 and item 20).

[0894] 1. A method for video processing (e.g., Figure 20A 2010), comprising: for a conversion between a current video block of a video and a bitstream representation of the video, making (2012) a determination to apply a deblocking process to boundaries within the current video block based on rules resulting from using a partitioned prediction mode for the current video block; and performing (2014) the conversion based on the determination, wherein using the partitioned prediction mode includes determining a final prediction for the current video block as a weighted sum of two or more predictions for the current video block.

[0895] 2. The method of clause 1, wherein the current video block is divided into two or more partitions.

[0896] 3. The method of clause 1 , wherein the partition prediction mode is a first mode in which the two or more predictions are based on a plurality of first partition schemes or a second mode in which the two or more predictions are based on a plurality of second partition schemes.

[0897] 4. The method of clause 1, wherein the partition prediction mode is a first mode based on a plurality of first partition schemes or a second mode based on a plurality of second partition schemes.

[0898] 5. The method of clause 1, wherein the first mode is a triangle partitioning mode and the second mode is a geometric partitioning mode.

[0899] 6. A method according to clause 5, wherein the geometric partitioning mode includes a plurality of second partitioning schemes, and at least one of the plurality of second partitioning schemes divides the current video block into two sub-partitions, such that at least one of the two sub-partitions is non-square and non-rectangular.

[0900] 7. The method of clause 5, wherein the geometric partitioning pattern comprises a triangle partitioning pattern.

[0901] 8. A method according to clause 1, wherein the rule specifies that the deblocking process is applied on an edge between two sub-blocks of the current video block if the edge is a transform unit (TU) edge and one of the two sub-blocks has non-zero coefficients, regardless of whether there is a motion difference between the two sub-blocks.

[0902] 9. The method of clause 8, wherein no non-zero coefficients are present in the two sub-blocks.

[0903] 10. The method of clause 9, wherein the rule specifies that the deblocking process is applied if the two sub-blocks have all-zero coefficients but the difference in motion between the two sub-blocks is greater than a certain value.

[0904] 11. The method of clause 9, wherein the rule specifies that the deblocking process is not applied if the two sub-blocks have all-zero coefficients but the motion difference between the two sub-blocks is greater than a certain value.

[0905] 12. A method according to clause 1, wherein the rule specifies whether the deblocking process is triggered for an edge of two sub-blocks of the current video block encoded and decoded in the partitioned prediction mode depends on whether the edge corresponds to a transform unit (TU) edge or a motion vector (MV) edge of the two sub-blocks.

[0906] 13. The method of clause 12, wherein the rule specifies that the deblocking process is triggered if the difference in motion between the two sub-blocks is greater than a certain value of the MV edge.

[0907] 14. The method of clause 12, wherein the rule specifies that the deblocking process is triggered if there are non-zero coefficients in a sub-block located on one side of the TU edge.

[0908] 15. A method according to clause 1, wherein the rule specifies that the deblocking process is triggered for both the TU edge and the MV edge in the following cases: 1) the motion difference between two sub-blocks of the current video block is greater than a certain value of the MV edge, or 2) there are non-zero coefficients in the sub-block.

[0909] 16. A method according to clause 8 or 12, wherein the transform unit (TU) edge indicates an actual transform unit edge.

[0910] 17. The method of clause 12, wherein the motion vector (MV) edge indicates a prediction unit (PU) edge or a sub-block edge aligned with a filtering grid.

[0911] 18. A method according to any one of clauses 8, 10, 11, 13, 15, wherein the motion difference comprises: i) a motion vector difference of the two sub-blocks greater than T, and / or ii) different reference frame indices, and / or iii) different reference POCs (picture order counts), and / or iv) different numbers of reference frames.

[0912] 19. A method of video processing (e.g., Figure 20B 2020), comprising: for a conversion between a current video block of a video and a bitstream representation of the video, determining (2022) whether and / or how to apply a deblocking process to the current video block based on a type of partitioned prediction mode for the current video block; and performing (2024) the conversion based on the determination, and wherein using the partitioned prediction mode comprises determining a final prediction for the current video block as a weighted sum of two or more predictions for the current video block.

[0913] 20. The method of clause 19, wherein the type of partition prediction mode comprises a first mode in which the two or more predictions are based on a first partition scheme or a second mode in which the two or more predictions are based on a second partition scheme.

[0914] 21. The method of clause 19, wherein the first mode is a triangle partitioning mode and the second mode is a geometric partitioning mode.

[0915] 22. The method of clause 19, wherein a boundary between two sub-blocks of the current video block is filtered in the deblocking process.

[0916] 23. The method of clause 19, wherein a vertical or horizontal boundary across two partitions of the current video block is filtered in the deblocking process.

[0917] 24. The method of clause 19, wherein the boundary strength is equal to 1 or 2.

[0918] 25. The method of any of clauses 1 to 24, wherein performing the conversion comprises generating the codec representation from the current video block.

[0919] 26. A method as recited in any one of clauses 1 to 24, wherein performing the conversion comprises generating the current video block from the codec representation.

[0920] 27. A video processing apparatus comprising: a processor configured to implement the method of any one or more of clauses 1 to 26.

[0921] 28. A computer-readable medium storing program code which, when executed, causes a processor to implement the method of any one or more of clauses 1 to 26.

[0922] 29. A computer-readable medium storing a codec representation or a bitstream representation generated according to any one of the above methods.

[0923] The fifth group of items describes certain features and aspects of the technology disclosed in the previous section (e.g., items 21 to 29).

[0924] 1. A method for video processing (e.g., Figure 21A The method 2110 shown in , comprises: for a conversion between a current video block of a video and a bitstream representation of the video, determining (2112) the applicability of an intra-frame sub-partitioning (ISP) mode according to rules that are independent of the maximum and / or minimum transform size of the current video block; and performing (2114) the conversion based on the determination.

[0925] 2. The method of clause 1 , wherein the ISP mode comprises partitioning the current video block into sub-blocks.

[0926] 3. A method according to clause 1, wherein the rule specifies that the signaling notification of the ISP flag does not depend on whether the width of the current video block is less than or equal to the maximum transform size, and / or does not depend on whether the height of the current video block is less than or equal to the maximum transform size.

[0927] 4. The method of clause 1, wherein the rule specifies that signaling of the ISP flag does not depend on whether the product of the width and height of the current video block is greater than the square of the minimum transform size.

[0928] 5. The method of clause 1, wherein the rule specifies that signaling of the ISP flag depends on whether the product of the width and height of the current video block is greater than N, where N is an integer greater than 0.

[0929] 6. The method of clause 5, wherein N is a fixed value.

[0930] 7. The method of clause 6, wherein N is 16.

[0931] 8. The method of clause 5, wherein N depends on the minimum allowed transform size of the video unit.

[0932] 9. The method of clause 1, wherein the rule specifies that signaling of the ISP flag depends on whether the width of the current video block is less than or equal to N, and / or depends on whether the height of the current video block is less than or equal to N.

[0933] 10. The method of clause 9, wherein N is a fixed value.

[0934] 11. The method of clause 10, wherein N is 64.

[0935] 12. The method of clause 9, wherein N depends on the maximum allowed transform size of the video unit.

[0936] 13. A method of video processing (e.g., Figure 21B The method 2120 shown in , comprises: for a conversion between a current video block of a video and a bitstream representation of the video, because the size of the current video block is larger than the maximum transform size applicable to the current video block, determining (2122) that an intra sub-partitioning (ISP) mode is to be applied; and performing (2124) the conversion based on the determination.

[0937] 14. The method of clause 13, wherein the ISP mode comprises partitioning the current video block into sub-blocks.

[0938] 15. The method of clause 13, wherein, if the current video block encoded using the ISP mode is larger than the maximum transform size, the current video block is implicitly partitioned in a recursive manner until the size of the sub-blocks is 64.

[0939] 16. The method of clause 13, wherein, when the current video block encoded and decoded using the ISP mode is larger than the maximum transform size, the current video block is implicitly split in a recursive manner until the size of the sub-blocks is the maximum transform size.

[0940] 17. A method of video processing (e.g., Figure 21C The method 2130 shown in ) includes: for a conversion between a current video block of a video and a bitstream representation of the video, because the size of the current video block is greater than or equal to 128, determining (2132) to apply a combined inter-frame and intra-frame prediction (CIIP) mode or a partitioning mode to the current video block; and performing (2134) the conversion based on the determination.

[0941] 18. The method of clause 17, wherein the size refers to the width or height of the current video block.

[0942] 19. The method of clause 17, wherein the size refers to the total number of pixels in the current video block.

[0943] 20. The method of clause 17, wherein the CIIP mode comprises combining intra-prediction signaling and inter-prediction signaling using weighting coefficients, and wherein the partitioning mode comprises partitioning the current video block into two or more partitions, wherein at least one partition has an angled edge.

[0944] 21. The method of clause 17, wherein the partitioning pattern comprises a triangle partitioning pattern or a geometric partitioning pattern.

[0945] 22. The method of clause 21, wherein the geometric partitioning mode comprises a plurality of partitioning schemes, and at least one of the plurality of partitioning schemes divides the current video block into two partitions such that at least one of the two partitions is non-square and non-rectangular.

[0946] 23. The method of clause 21, wherein the geometric partitioning pattern comprises a triangle partitioning pattern.

[0947] 24. The method of clause 17, wherein the maximum codec tree unit (CTU) size is set to be greater than 128.

[0948] 25. A method of video processing, comprising: performing a conversion between a current video block and a bitstream representation of the video, wherein the bitstream representation conforms to a format rule that specifies information included in the bitstream representation based on a size of the current video block.

[0949] 26. The method of clause 25, wherein the format rule specifies that Merge data is included in the bitstream representation because the size of the current video block is greater than 128.

[0950] 27. The method of clause 26, wherein a Merge flag indicating the Merge data depends on whether a size of the current video block is smaller than a maximum codec tree unit (CTU) size.

[0951] 28. The method of clause 25, wherein the format rules specify that due to the dimensions of the current video block being greater than 128, at least one of a cu_skip_flag or a pred_mode_ibc_flag be included in the bitstream representation.

[0952] 29. A method of video processing, comprising: performing a conversion between a current video block and a bitstream representation of a video, wherein the bitstream representation conforms to a format rule, the format rule specifying that, if a width and / or height of the current video block is equal to or greater than X, a syntax element indicating use of an intra block copy (IBC) prediction mode is omitted from the bitstream representation, where X is an integer.

[0953] 30. The method of clause 29, wherein the format rule specifies that the value of the syntax element is to be inferred to be 0.

[0954] 31. The method of clause 29, wherein the format rule specifies that the IBC prediction mode is not to be used for the current video block.

[0955] 32. A method as described in clause 29, wherein the syntax element corresponds to pred_mode_ibc_flag.

[0956] 33. The method of clause 29, wherein X is 64 or 128.

[0957] 34. The method of clause 29, wherein the format rule specifies that if the width and height of the current video block are greater than 64, the value of the syntax element is inferred to be 0.

[0958] 35. The method of clause 29, wherein the format rule specifies that if the width or height of the current video block is greater than 64, the value of the syntax element is inferred to be 0.

[0959] 36. A method of video processing (e.g., Figure 21D), comprising: for conversion between a video comprising a plurality of color components and a bitstream representation of the video, determining (2142) a deblocking parameter offset to be used in a deblocking process for each component according to a rule; and performing (2144) the conversion based on the determination, wherein the rule specifies that the deblocking parameter offset at a picture level and / or a slice level is different for each component of the video.

[0960] 37. The method of clause 36, wherein the rule further specifies that the deblocking parameter offsets at the picture level for luma, Cb, and Cr components are different and are indicated by different syntax elements.

[0961] 38. A method according to clause 36, wherein the rule further specifies that the deblocking parameter offset at the picture level of the joint coding mode is different from the deblocking parameter offset of the non-joint mode and is indicated by different syntax elements, wherein the joint coding mode jointly generates the prediction residual block of the current video block for the Cb component and the Cr component.

[0962] 39. The method of clause 36, wherein the rule further specifies that the deblocking parameter offsets at the slice level for luma, Cb, and Cr components are different and indicated by different syntax elements.

[0963] 40. A method according to clause 36, wherein the rule further specifies that the deblocking parameter offset at the picture level of the joint coding mode is different from the deblocking parameter offset of the non-joint mode and is indicated by different syntax elements, wherein the joint coding mode jointly generates the prediction residual block of the current video block for the Cb component and the Cr component.

[0964] 41. A method of video processing (e.g., Figure 21E ) comprising: for converting between a chroma video block of a video and a bitstream representation of the video, deriving (2152) chroma deblocking parameters based on a chroma quantization parameter (QP) determined according to a rule, wherein the chroma video block belongs to a codec unit and a slice; and performing (2154) the converting based on the chroma deblocking parameters, and wherein the rule specifies that the chroma QP is based on a picture-level chroma QP offset and a codec-unit-level chroma QP offset for the chroma video block, but is independent of a slice-level chroma QP offset.

[0965] 42. The method of clause 41, wherein the rule further specifies that the chroma QP depends on pps_cb_qp_offset, pps_cr_qp_offset, pps_cbcr_qp_offset, CuQpOffset Cb 、CuQpOffset Cr and CuQpOffset CbCr , but has nothing to do with slice_cb_qp_offset, slice_cr_qp_offset and slice_cbcr_qp_offset, where pps_cb_qp_offset, pps_cr_qp_offset, pps_cbcr_qp_offset specify the Qp′ Cb , Qp′ Cr and Qp′ CbCr The picture-level offset used in the export, and CuQpOffset Cb 、CuQpOffset Cr and CuQpOffset CbCr Specify when determining the Qp′ for the chroma video block Cb , Qp′ Cr and Qp′ CbCr The value to use when quantizing the corresponding value of the parameter.

[0966] 43. A method as described in any of clauses 1 to 42, wherein performing the conversion comprises generating the codec representation from the current video block.

[0967] 44. A method as described in any of clauses 1 to 42, wherein performing the conversion comprises generating the current video block from the codec representation.

[0968] 45. A video processing apparatus comprising a processor configured to implement the method of any one or more of clauses 1 to 44.

[0969] 46. ​​A computer-readable medium storing program code which, when executed, causes a processor to implement the method of any one or more of clauses 1 to 44.

[0970] 47. A computer-readable medium storing a codec representation or a bitstream representation generated according to any of the above methods.

[0971] The disclosed and other solutions, examples, embodiments, modules, and 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 any combination thereof. 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 a data processing apparatus or to control the operation of the 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 that effects a machine-readable propagated signal, or any combination thereof. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer or multiple processors, or a computer. In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or any combination thereof. A propagated signal is an artificially generated signal, such as a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to an appropriate receiver device.

[0972] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language (including compiled or interpreted languages) and may 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 may 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 storing one or more modules, subroutines, or portions of code). A computer program may be deployed for execution on one or more computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0973] 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 be implemented as, special-purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0974] By way of example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from read-only memory or random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or be operatively coupled to one or more mass storage devices to receive data from them or transfer data to one or more mass storage devices, or both. However, 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 storage devices, including, by way of example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated into, special-purpose logic circuitry.

[0975] While this patent document contains many details, they should not be construed as limitations on the scope of any subject matter or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular technologies. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various functions described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, while features may be described as functioning in certain combinations, and even initially claimed to be so, in some cases one or more features in a claimed combination may be deleted from the combination, and a claimed combination may be directed to a subcombination or variations of a subcombination.

[0976] Similarly, although operations may be described in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, in order to achieve desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0977] Only a few implementations and examples are described, and other implementations, enhancements, and variations can be made based on what is described and illustrated in this patent document.

Claims

1. A video processing method, comprising: For conversion between a current video block of a video and a bitstream of the video, determining applicability of an intra sub-partitioning ISP mode according to rules that are independent of a maximum and / or minimum transform size of the current video block; as well as performing said converting based on said determining; The rule specifies that signaling of the ISP flag does not depend on whether the product of the width and height of the current video block is greater than the square of the minimum transform size.

2. The method according to claim 1, wherein The ISP mode includes partitioning the current video block into sub-blocks.

3. The method according to claim 1, wherein The rules specify that signaling of the ISP flag does not depend on whether the width of the current video block is less than or equal to the maximum transform size and / or does not depend on whether the height of the current video block is less than or equal to the maximum transform size.

4. The method according to claim 1, wherein The rule specifies that signaling of the ISP flag depends on whether the product of the width and height of the current video block is greater than N, where N is an integer greater than 0.

5. The method according to claim 4, wherein N is a fixed value.

6. The method according to claim 5, wherein: N is 16.

7. The method according to claim 4, wherein: N depends on the minimum allowed transform size of the video unit.

8. The method according to claim 1, wherein The rule specifies that signaling of the ISP flag depends on whether the width of the current video block is less than or equal to N, and / or depends on whether the height of the current video block is less than or equal to N.

9. The method according to claim 8, wherein N is a fixed value.

10. The method according to claim 9, wherein: N is 64.

11. The method according to claim 8, wherein N depends on the maximum allowed transform size of the video unit.

12. The method according to claim 1, wherein Since the size of the current video block is larger than the maximum transform size applicable to the current video block, it is determined that the ISP mode is to be applied.

13. The method according to claim 12, wherein: The ISP mode includes partitioning the current video block into sub-blocks.

14. The method according to claim 12, wherein: When the current video block encoded and decoded using the ISP mode is larger than the maximum transform size, the current video block is implicitly divided in a recursive manner until the size of the sub-blocks is 64.

15. The method according to claim 12, wherein: In a case where the current video block encoded and decoded using the ISP mode is larger than the maximum transform size, the current video block is implicitly divided in a recursive manner until the size of the sub-blocks is the maximum transform size.

16. The method according to claim 1, wherein Since the size of the current video block is greater than or equal to 128, it is determined that the combined inter-frame and intra-frame prediction CIIP mode or the partition mode is applied to the current video block.

17. The method according to claim 16, wherein The size refers to the width or height of the current video block.

18. The method according to claim 16, wherein The size refers to the total number of pixels in the current video block.

19. The method according to claim 16, wherein The CIIP mode includes combining intra prediction signaling and inter prediction signaling using weighting coefficients, and wherein the partitioning mode includes partitioning the current video block into two or more partitions, wherein at least one partition has an angled edge.

20. The method according to claim 16, wherein The segmentation mode includes a geometric segmentation mode.

21. The method according to claim 20, wherein The geometric partitioning mode includes a plurality of partitioning schemes, and at least one of the plurality of partitioning schemes divides the current video block into two partitions such that at least one of the two partitions is non-square and non-rectangular.

22. The method according to claim 20, wherein The geometric partitioning mode includes a triangle partitioning mode.

23. The method according to claim 16, wherein The maximum codec tree unit (CTU) size is set to be greater than 128.

24. The method according to claim 1, wherein The bitstream conforms to format rules that specify information included in the bitstream based on a size of the current video block.

25. The method according to claim 24, wherein The format rule specifies that since the size of the current video block is greater than 128, Merge data is included in the bitstream.

26. The method according to claim 25, wherein The Merge flag indicating the Merge data depends on whether the size of the current video block is smaller than the maximum codec tree unit CTU size.

27. The method according to claim 24, wherein The format rules specify that since the dimension of the current video block is greater than 128, at least one of cu_skip_flag or pred_mode_ibc_flag is included in the bitstream.

28. The method according to claim 1, wherein The bitstream complies with a format rule that specifies that, if a width and / or a height of the current video block is equal to or greater than X, a syntax element indicating use of an intra block copy (IBC) prediction mode is omitted from the bitstream, where X is an integer.

29. The method according to claim 28, wherein The format rule specifies that the value of the syntax element is inferred to be 0.

30. The method of claim 28, wherein The format rules specify that the IBC prediction mode is not used for the current video block.

31. The method of claim 28, wherein The syntax element corresponds to pred_mode_ibc_flag.

32. The method of claim 28, wherein: X is 64 or 128.

33. The method of claim 28, wherein: The format rule specifies that if the width and height of the current video block are greater than 64, the value of the syntax element is inferred to be 0.

34. The method of claim 28, wherein The format rule specifies that if the width or height of the current video block is greater than 64, the value of the syntax element is inferred to be 0.

35. The method of claim 1, wherein For conversion between a video comprising a plurality of color components and a bitstream of the video, determining a deblocking parameter offset used in a deblocking process for each component according to a rule; Wherein the rules specify that the deblocking parameter offsets at picture level and / or slice level are different for each component of the video.

36. The method according to claim 35, wherein The rules further specify that the deblocking parameter offsets at the picture level for luma, Cb, and Cr components are different and are indicated by different syntax elements.

37. The method according to claim 35, wherein The rule further specifies that the deblocking parameter offset at the picture level of the joint coding mode is different from the deblocking parameter offset of the non-joint mode and is indicated by different syntax elements, wherein the joint coding mode jointly generates a prediction residual block of the current video block for the Cb component and the Cr component.

38. The method of claim 35, wherein: The rule further specifies that the deblocking parameter offsets at the slice level for luma, Cb, and Cr components are different and are indicated by different syntax elements.

39. The method of claim 1, wherein For conversion between a chroma video block of the video and a bitstream of the video, deriving a chroma deblocking parameter based on a chroma quantization parameter QP determined according to a rule, wherein the chroma video block belongs to a codec unit and a slice; as well as performing said conversion based on said chroma deblocking parameters, and The rule specifies that the chroma QP is based on a picture-level chroma QP offset and a codec-unit-level chroma QP offset of the chroma video block, but is independent of a slice-level chroma QP offset.

40. The method of claim 39, wherein the rule further specifies that the chroma QP depends on pps_cb_qp_offset, pps_cr_qp_offset, pps_cbcr_qp_offset, CuQpOffset Cb 、CuQpOffset Cr and CuQpOffset CbCr , but has nothing to do with slice_cb_qp_offset, slice_cr_qp_offset and slice_cbcr_qp_offset, where pps_cb_qp_offset, pps_cr_qp_offset, pps_cbcr_qp_offset specify the Qp' Cb 、Qp' Cr and Qp' CbCr The picture-level offset used in the export, and CuQpOffset Cb 、CuQpOffset Cr and CuQpOffset CbCr Specify when determining the Qp' for the chroma video block respectively Cb 、Qp' Cr and Qp' CbCr The value to use when quantizing the corresponding value of the parameter.

41. The method according to any one of claims 1 to 40, wherein Performing the conversion includes generating the bitstream from the current video block.

42. The method according to any one of claims 1 to 40, wherein Performing the conversion includes generating the current video block from the bitstream.

43. A video processing device comprising: A processor configured to implement the method according to any one of claims 1 to 42.

44. A computer readable medium storing program code, which, when executed, causes a processor to implement the method of any one of claims 1 to 42.

45. A method for storing a bitstream of a video, comprising: The bit stream generated by the method according to any one of claims 1 to 42 is stored in a non-transitory computer-readable recording medium.

Images