JP2022522149A - Size-dependent intercoding - Google Patents

Abstract

Techniques for implementing video processing techniques are described. In an exemplary implementation, the method of video processing is based on whether the conditions related to the size of the current block are satisfied for the conversion between the current block of video and the bitstream representation of the video. Partially involves determining how the coding information of the current block is represented in the bitstream representation. The method also includes the step of performing the transformation based on the decision.

Description

This patent document relates to image and video coding and decoding.

Digital video occupies the largest bandwidth usage on the Internet and other digital communication networks. Bandwidth demand for digital video utilization is expected to continue to grow as the number of connected user devices capable of receiving and displaying video increases.

The present patent document discloses various video processing techniques that can be used by video encoders and decoders during encoding and decoding operations.

In one exemplary embodiment, a method of video processing is disclosed. The method is for the conversion using the affine coding tool between the current block of the video and the bitstream representation of the video, the first motion vector of the subblock of the current block and the representative motion for the current block. The second motion vector, which is a vector, includes a step of determining that it follows a size constraint. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method comprises determining an affine model with six parameters for the conversion between the current block of video and the bitstream representation of the video. The affine model is inherited from the affine coding information of the adjacent block of the current block. The method also includes the step of performing the transformation based on the affine model.

In another exemplary embodiment, a method of video processing is disclosed. The method determines whether bi-predictive coding techniques are applicable to the block for the conversion between the block of video and the bitstream representation of the video, assuming that W and H are positive integers, the width W and It comprises a step of determining based on the size of the block having the height H. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is a subblock that is a child coding unit of a block that follows the coding tree splitting process to determine if the coding tree splitting process is applicable to the block for the conversion between the video block and the video bitstream representation. Includes steps to determine based on the size of. The subblock has a width W and a height H, where W and H are positive integers. The method also includes the steps of performing the conversion according to the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method derives an index of the Bi-prediction with Coding unit level weight (BCW) coding mode for the conversion between the current block of video and the bitstream representation of the video. Includes a step to determine whether or not based on the rules for the current block position. In BCW coding mode, a weight set containing multiple weights is used to generate the bipredicted value of the current block. The method also includes the steps of performing the conversion according to the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is the intra-prediction of adjacent blocks for the conversion between the current block of video coded using the Combined Inter and Intra Prediction (CIIP) coding technique and the bitstream representation of the video. Includes a mode-independent step to determine the intra-prediction mode for the current block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is the first intra-prediction mode of the first adjacent block and for the conversion between the current block of video and the bitstream representation of the video coded using inter and intra-complex prediction (CIIP) coding techniques. A step of determining the intra prediction mode of the current block according to the second intra prediction mode of the second adjacent block is included. The first adjacent block is coded using the intra-predictive coding technique and the second adjacent block is coded using the CIIP coding technique. The first intra prediction mode is given a different priority than the second intra prediction mode. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is to determine if the inter- and intra-composite prediction (CIIP) process is applicable to the color components of the current block for the conversion between the current block of video and the bitstream representation of the video. Includes steps to determine based on the size of the block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method currently determines whether inter- and intra-composite prediction (CIIP) coding techniques should be applied to the current block for the conversion between the current block of video and the bitstream representation of the video. Includes steps to determine based on the characteristics of the block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is whether the coding tool should be disabled for the current block due to the conversion between the current block of video and the bitstream representation of the video, whether the current block is inter and intra. Includes steps to determine based on whether or not it is coded by a compound predictive (CIIP) coding technique. Coding tools include Bi-Directional Optical Flow (BDOF), Overlapped Block Motion Compensation (OBMC), or Decoder-side Motion Vector Refinement process (DMVR). ), At least one of. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is used for the first prediction P1 used for the motion vector for spatial motion prediction and the motion vector for temporal motion prediction for the conversion between the video block and the video bitstream representation. A step of determining the second prediction P2 is included. P1 and / or P2 are fractions, and neither P1 nor P2 is transmitted in bitstream representation. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method comprises determining a motion vector (Mvx, MVy) by prediction (Px, Py) for conversion between a block of video and a bitstream representation of the video. Px is associated with MVx and Py is associated with MVy. MVx and MVy are stored as integers, each having N bits, MinX ≦ MVx ≦ MaxX and MinY ≦ MVy ≦ MaxY, and MinX, MaxX, MinY, and MaxY are real numbers. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is to determine if the shared merge list is applicable to the current block for the conversion between the current block of video and the bitstream representation of the video, according to the coding mode of the current block. include. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is dimension for motion compensation during conversion (W + N-1) × (H + N-1) for conversion between the current block of video having a size of W × H and the bitstream representation of the video. Includes a step to determine the second block of. The second block is determined based on the reference block of dimensions (W + N-1-PW) × (H + N-1-PH). N represents the filter size, and W, H, N, PW and PH are non-negative integers. Both PW and PH are not equal to zero. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is dimension for motion compensation during conversion (W + N-1) × (H + N-1) for conversion between the current block of video having a size of W × H and the bitstream representation of the video. Includes a step to determine the second block of. W and H are non-negative integers and N is a non-negative integer based on the filter size. During the transformation, the refined motion vector is determined based on a multipoint search according to the motion vector refinement action against the original motion vector, and the pixel length boundaries of the reference block are determined by repeating one or more non-boundary pixels. It is determined. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is to convert a block of video coded using the Inter-Intra Composite Prediction (CIIP) coding technique to a bitstream representation of the video by predicting the predicted value at a position within the block at that position. Includes steps to determine based on the weighted sum of inter-predicted and intra-predicted values. The weighted sum is based on adding an offset to the initial sum obtained based on the inter-predicted and intra-predicted values, and the offset is added before the right shift operation performed to determine the weighted sum. The method also includes the step of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is partly based on the coding information of the current block based on whether the conditions related to the size of the current block are met for the conversion between the current block of the video and the bitstream representation of the video. Includes steps to determine how is represented in the bitstream representation. The method also includes the steps of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is to determine a modified motion vector set for the conversion between the current block of video and the bitstream representation of the video, and to perform the transformation based on the modified motion vector set. And include. If the current block satisfies the condition, the modified motion vector set is a modified version of the motion vector set associated with the current block.

In another exemplary embodiment, a method of video processing is disclosed. The method comprises determining a unidirectional motion vector from a bidirectional motion vector if the block dimensional conditions are met for the conversion between the current block of video and the bitstream representation of the video. The one-way motion vector is then used as a merge candidate for the transformation. The method also includes the steps of performing the transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is to limit the motion candidates of the current block to one-way predictive direction based on the dimensions of the current block due to the conversion between the current block of the video and the bitstream representation of the video. Includes a step to determine and a step to perform a transformation based on the decision.

In another exemplary embodiment, a method of video processing is disclosed. The method is a bitstream representation by using the steps of determining the size limit between the representative motion vector of the current video block to be fin-coded and the motion vector of the subblocks of the current video block, and the size limit. Includes steps to perform a conversion between and the pixel values of the current video block or subblock.

In other exemplary embodiments, other methods of video processing are disclosed. The method is a step of determining one or more subblocks of the current video block to be fincoded, where each subblock is M, assuming that M and N are multiples of 2 or 4. A bitstream representation of a bitstream representation and the current video block by using a step with a size of × N pixels, a step to match the motion vector of the subblock to the size limit, and a size limit conditionally based on a trigger. Includes steps to perform conversions between pixel values.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is to determine that the current video block satisfies the size requirement, and based on that determination, the bitstream representation and the current video block by excluding the bi-predictive coding mode for the current video block. Includes steps to perform conversions to and from pixel values.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method comprises a step of determining that the current video block satisfies the size requirement and, based on that determination, performing a conversion between the bitstream representation and the pixel values of the current video block. The inter-prediction mode is conveyed in bitstream representation according to size limits.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method comprises a step of determining that the current video block satisfies the size requirement and, based on that determination, performing a conversion between the bitstream representation and the pixel values of the current video block. The generation of the merge candidate list during conversion depends on the size condition.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method consists of determining that the child coding unit of the current video block satisfies the size requirement, and then performing a conversion between the bitstream representation and the pixel values of the current video block based on that determination. The coding tree splitting process used to generate the child coding units, including, depends on the size condition.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is to determine the weight index of the generalized bi-prediction (GBi) process for the current video block based on the position of the current video block, and to implement the GBi process. Includes steps to perform a conversion between the current video block and its bitstream representation using the index.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is the step of determining that the current video block is coded as an Intra-Inter Prediction (IIP) coding block and the Intra-Inter Prediction mode or Most Probable for the current video block. Includes steps to perform a conversion between the current video block and its bitstream representation using a simplification rule that determines Mode, MPM).

In yet another exemplary embodiment, other methods of video processing are disclosed. The method disables the conversion between the current video block and the bitstream representation, the step of determining that the current video block meets the simplification criteria, and the use of the inter-intra prediction mode for that conversion. Includes steps performed by making it or by disabling any further coding tools used for its conversion.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method comprises performing a conversion between the current video block and a bitstream representation of that current video block using a motion vector based encoding process, wherein (a) accuracy P1 is spatial motion. Used to store the prediction result, precision P2 is used to store the time motion prediction result during the conversion process, P1 and P2 are fractions, or (b) precision Px is the x motion vector. The precision Py is used to store the y motion vector, and Px and Py are fractions.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is to fetch a block of (W2 + N-1-PW) × (H2 + N-1-PH) assuming that W1, W2, H1, H2, and PW and PH are integers, and pixel pad the fetched block. By performing boundary pixel iterations on the pixel-padded blocks and getting the pixel values of the smaller subblocks, the smaller W1xH1 size sub-blocks within the larger W2xH2 size subblocks of the current video block. It involves interpolating blocks and performing conversions between the current video block and the bitstream representation of that current video block using the interpolated pixel values of the smaller subblocks.

In other exemplary embodiments, other methods of video processing are disclosed. The method fetches (W + N-1-PW) × (H + N-1-PH) reference pixels during conversion of the current video block of W × H dimension and the bitstream representation of the current video block. By padding a reference pixel that is larger than the fetched reference pixel during the motion compensation operation, the steps to perform the motion compensation operation and the result of the motion compensation operation are used to the current video block and its current video block. W, H, N, PW and PH are integers, including the step of performing a conversion to and from the bitstream representation.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is to determine that bi-prediction or one-sided prediction of the current video block is not allowed based on the size of the current video block, and to disable the bi-prediction or one-sided prediction mode based on that decision. By including a step of performing a conversion between the bitstream representation and the pixel values of the current video block.

In yet another exemplary embodiment, other methods of video processing are disclosed. The method is to determine that bi-prediction or one-sided prediction of the current video block is not allowed based on the size of the current video block, and to disable the bi-prediction or one-sided prediction mode based on that decision. By including a step of performing a conversion between the bitstream representation and the pixel values of the current video block.

In yet another exemplary embodiment, a video encoder device is disclosed. The video encoder has a processor configured to implement the above method.

In yet another exemplary embodiment, a video decoder device is disclosed. The video decoder has a processor configured to implement the above method.

In yet another exemplary embodiment, a computer readable medium storing the code is disclosed. The code embodies one of the methods described herein in the form of processor executable code.

These and other features are described throughout this document.

An example of subblock-based prediction is shown. A four-parameter affine model is shown. A 6-parameter affine model is shown. An example of an affine motion vector field for each subblock is shown. An example of a candidate for AF_MERGE is shown. Other examples of candidates for AF_MERGE are shown. Shows candidate positions for affine merge mode. An example of a constrained subblock motion vector for an affine mode coding unit (CU) is shown. An example of a 135 degree partition that divides the CU into two triangular prediction units is shown. An example of a 45-degree partitioning pattern that divides the CU into two triangular prediction units is shown. An example of the position of the adjacent block is shown. An example of repeating boundary pixels of the reference block before interpolation is shown. An example of a coding tree unit (CTU) and a CTU (region) line is shown. Shared CTUs (regions) are in one CTU (region) line and non-shared CTUs (regions) are in other CTU (regions) lines. FIG. 3 is a block diagram of an example hardware platform that implements the video decoders or video encoders described herein. It is a flowchart about the method which becomes an example of video processing. An example of the motion vector difference MVD (0,1) mirrored between List 0 and List 1 in DMVR is shown. An example MV that can be checked in one iteration is shown. Shows the required reference sample and the padded boundaries for the calculation. It is a block diagram of an example of a video processing system in which the disclosed technique can be implemented. It is a flowchart representation of the video processing method according to this disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of another method of video processing according to the present disclosure. It is a flowchart representation of yet another method of video processing according to the present disclosure.

Section headings are used in this document for ease of understanding and do not limit the applicability of the techniques and embodiments disclosed in each section to that section alone.

[1. overview]
This patent document relates to video / image coding techniques. Specifically, it concerns reducing the bandwidth and line buffers of some coding tools in video / image coding. It may be applied to existing video coding standards such as HEVC, or standards to be completed (Versatile Video Coding). It may also be applicable to future video / image coding standards or video / image codecs.

[2. background]
Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T is H.T. 261 and H. 263 was produced, ISO / IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced H.M. 262 / MPEG-2 Video and H264 / MPEG-4 AVC (Advanced Video Coding) and H.M. Created the 265 / HEVC standard. H. Since 262, the video coding standard is based on a hybrid video coding structure, utilizing time prediction and conversion coding. JVET (Joint Video Exploration Team) was co-founded by VCEG and MPEG in 2015 to explore future video coding technologies beyond HEVC. Since then, many new methods have been introduced by JVET and placed in reference software named JEM (Joint Exploration Model). In April 2018, the JVET (Joint Video Expert Team) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) aims to reduce the bit rate by 50% compared to HEVC. Made to tackle.

[2.1 Inter-prediction in HEVC / VVC]
<Interpolation filter>
In HEVC, the luma subsample is generated by the 8-tap interpolation filter and the chroma subsample is generated by the 4-tap interpolation filter.

The filter is separable in two dimensions. Samples are first filtered horizontally and then vertically.

[2.2 Subblock-based prediction technology]
Subblock-based predictions are first introduced into the video coding standard by HEVC Annex I (3D-HEVC). According to sub-block based predictions, blocks such as Coding Units (CUs) or Prediction Units (PUs) are divided into several non-overlapping sub-blocks. Different sub-blocks may be assigned different motion information such as reference indexes or motion vectors (MV), and motion compensation (MC) is performed individually for each sub-block. FIG. 1 shows the concept of subblock-based prediction.

JVET (Joint Video Exploration Team) was co-founded by VCEG and MPEG in 2015 to explore future video coding technologies beyond HEVC. Since then, many new methods have been introduced by JVET and placed in reference software named JEM (Joint Exploration Model).

In JEM, subblock-based predictions include Affin Prediction, Alternative Temporal Motion Vector Prediction (ATMVP), Spatial-Temporal Motion Vector Prediction (STMVP), and Bi-Temporal Motion Vector Prediction (STMVP). -Used in several coding tools such as directional Optical flow (BIO) and Frame-Rate Up Conversion (FRUC). Affine prediction is also used in VVC.

[2.3 Affine prediction]
In HEVC, only translational motion models are applied for Motion Compensation Prediction (MCP). On the other hand, in the real world, there are many types of movements, such as zoom in / out, rotation, projection movements, and other irregular movements. In VVC, simplified affine transformation motion compensation prediction is applied. As shown in FIGS. 2A-2C, the affine play field of the block is represented by two control point motion vectors (in the four-parameter affine model) or three control point motion vectors (in the six-parameter affine model).

The motion vector field (MVF) of the block is a 4-parameter affine model in equation (1) (4 parameters are defined as variables a, b, e and f) and 6 parameters in equation (2). The affine model (6 parameters are defined as variables a, b, c, d, e and f) is expressed by the following equations, respectively:

Here, (mv ^h ₀ , mv ^v ₀ ) is the motion vector of the control point in the upper left corner, and (mv ^h ₁ , mv ^v ₁ ) is the motion vector of the control point in the upper right corner ^. ₂ , mv ^v ₂ ) is the motion vector of the control point at the lower left corner, and all three motion vectors are called control point motion vectors (CPMV), and (x, y) is currently Represents the coordinates of the representative point for the upper left sample in the block of. The CP motion vector may be notified (as in affine AMVP mode) or derived on the fly (as in affine merge mode). w and h are the width and height of the current block. In fact, the split is implemented by a right shift with a rounding operation. In VTM, the representative point is defined to be the center position of the subblock, for example, the coordinates of the representative point when the coordinates of the upper left corner of the subblock with respect to the upper left sample in the current block are (xs, ys). Is defined as (xs + 2, ys + 2).

として実装される。 In a design without division, equations (1) and (2) are:

Implemented as.

In the case of the 4-parameter affine model shown in equation (1):

In the case of the 6-parameter affine model shown in equation (2):

Finally,

Here, S represents the calculation accuracy, and for example, in VVC, S = 7. In VVC, the MV used in the MC for the subblock by the upper left sample at (xs, ys) is calculated by equation (6) using x = xs + 2 and y = ys + 2.

The motion vector of the central sample of each subblock, as shown in FIG. 3, is calculated according to Eq. (1) or Eq. (2) to derive the motion vector of each 4 × 4 subblock and is a 1/16 fraction. Rounded to precision. A motion compensation interpolation filter is then applied to generate a prediction for each subblock from the derived motion vector.

The affine model can be inherited from spatially adjacent affine coding blocks such as left, top, top right, bottom left and top left adjacent blocks as shown in FIG. 4A. For example, when the lower left adjacent block A in FIG. 4 is coded in affine mode as represented by A0 in FIG. 4B, the control points of the upper left corner, upper right corner, and lower left corner of the adjacent CU / PU including the block A. (CP) Motion vectors mv ₀ ^N , mv ₁ ^N and mv ₂ ^N are fetched. Then, the lower left angle / upper right / lower left motion vectors mv ₀ ^C , mv ₁ ^C and mv ₂ ^C on the current CU / PU are calculated based on mv ₀ ^N , mv ₁ ^N and mv ₂ ^N. It should be noted that in VTM-2.0, when the current block is affine coded, the subblock (eg 4x4 block in VTM) LT stores mv0 and RT stores mv1. It is a point. If the current block is coded by the 6-parameter affine model, LB stores mv2, otherwise (according to the 4-parameter affine model), LB stores mv2'. The other subblock stores the MV used for the MC.

It should be noted that if the CU is coded by affine merge mode, for example in AF_MERGE mode, it will get the first block coded by affine mode from the valid adjacent reconstructed blocks. The selection order of the candidate blocks is from left to top, top right, bottom left, and top left, as shown in FIG. 4A.

The derived CP MV mv ₀ ^C , mv ₁ ^C and mv ₂ ^C of the current block can be used as the CP MV in the affine merge mode. Alternatively, they can be used in VVC as MVPs for affine intermode. It should be noted that for merge mode, if the current block is coded by affine mode, the current block may be further subdivided into multiple subblocks after deriving the CP MV of the current block. , Each block derives its motion information based on the derived CP MV of the current block.

[2.4 Example Embodiment in JVET]
Unlike VTMs where only one affine space flanking block can be used to derive the affine motion of a block, in some embodiments a separate list of affine candidates is configured for AF_MERGE mode.

1) Inserting the inherited affine candidate into the candidate list The inherited affine candidate means that the candidate is derived from a valid adjacent reconstruction block coded by the affine mode. As shown in FIG. 5, the scanning order of the candidate blocks is A ₁ , B ₁ , B ₀ , A ₀ , and B ₂ . When a block is selected (eg A ₁ ), a two-step procedure is applied.

1. 1. a First, to derive the 2/3 control points of the current block, we use the motion vectors of the 3 corners of the CU covering the block.

1. 1. b Based on the control points of the current block to derive the subblock motion of each subblock in the current block.

2) Inserting the configured affine candidates When the number of candidates in the affine merge candidate list is less than MaxNumAfineCand, the configured affine candidates are inserted into the candidate list.

The configured affine candidate means that the candidate is configured by combining the adjacent motion information of each control point.

The motion information of the control point is first derived from the designated spatial and temporal neighborhoods shown in FIG. CPk (k = 1, 2, 3, 4) represents the kth control point. A ₀ , A ₁ , A ₂ , B ₀ , B ₁ , B ₂ and B ₃ are spatial positions for predicting CPk (k = 1, 2, 3), and T is for predicting CP 4. Time position.

The coordinates of CP1, CP2, CP3 and CP4 are (0,0), (W,0), (H,0) and (W, H), respectively, where W and H are the current blocks. Width and height of.

The motion information of each control point is acquired according to the following priority order.

2. 2. For a CP1, the check priority is B _2- > B _3- > A ₂ . B ₂ is used when it is available. If not, B ₃ is used if B ₃ is available. If both B2 and B3 are unavailable, _A2 is used. If all three candidates are unavailable, CP1 motion information cannot be obtained.

2. 2. b For CP2, the check priority is B ₁ −> B ₀ .

2. 2. c For CP3, the check priority is A _1- > A ₀ .

2. 2. d For CP4, T is used.

Second, the combination of control points is used to construct the motion model.

Motion vectors of three control points are needed to calculate the transformation parameters in the 6-parameter affine model. The three control points are from one of the following four combinations ({CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4}). Can be selected. For example, CP1, CP2, and CP3 control points are used to construct a 6-parameter affine motion model represented as Affine (CP1, CP2, CP3).

Motion vectors of the two control points are needed to calculate the transformation parameters in the four-parameter affine model. The two control points are among the following six combinations ({CP1, CP4}, {CP2, CP3}, {CP1, CP2}, {CP2, CP4}, {CP1, CP3}, {CP3, CP4}). Can be selected from one of. For example, CP1 and CP2 control points are used to construct a four-parameter affine motion model represented as Affine (CP1, CP2).

The configured combinations of affine candidates are in the following order: {CP1, CP2, CP3}, {CP1, CP2, CP4}, {CP1, CP3, CP4}, {CP2, CP3, CP4}, {CP1, CP2} , {CP1, CP3}, {CP2, CP3}, {CP1, CP4}, {CP2, CP4}, {CP3, CP4} are inserted into the candidate list.

3) Insert zero motion vector If the number of candidates in the affine merge candidate list is less than MaxNumAfineCand, the zero motion vector is inserted into the candidate list until the list is full.

[2.5 Affine Merge Candidate List]
[2.5.1 Affine merge mode]
In the affine merge mode of VTM-2.0.1, only the first available affine neighborhood can be used to derive the motion information of the affine merge mode. In some embodiments, the candidate list for the affine merge mode is constructed by searching for valid affine neighborhoods and combining adjacent motion information for each control point.

The affine merge candidate list is organized as the following steps.

1) Inserting the inherited affine candidate The inherited affine candidate means that the candidate is derived from the affine motion model of the valid adjacent affine coding block. On a general basis, as shown in FIG. 5, the scanning order of the candidate positions is A ₁ , B ₁ , B ₀ , A ₀ , and B ₂ .

After the candidates are derived, a full pruning process is performed to check if the same candidates are inserted in the list. If the same candidate exists, the derived candidate is discarded.

2) Inserting the configured affine candidates When the number of candidates in the affine merge candidate list is less than MaxNumAfineCand (set to 5 in this application), the configured affine candidates are inserted into the candidate list. The configured affine candidate means that the candidate is configured by combining the adjacent motion information of each control point.

The motion information of the control point is first derived from the specified spatial and time neighborhoods. CPk (k = 1, 2, 3, 4) represents the kth control point. A ₀ , A ₁ , A ₂ , B ₀ , B ₁ , B ₂ and B ₃ are spatial positions for predicting CPk (k = 1, 2, 3), and T is for predicting CP 4. Time position.

The coordinates of CP1, CP2, CP3 and CP4 are (0,0), (W,0), (H,0) and (W, H), respectively, where W and H are the current blocks. Width and height of.

The motion information of each control point is acquired according to the following priority order.

For CP1, the check priority is B _2- > B _3- > A ₂ . B ₂ is used when it is available. If not, B ₃ is used if B ₃ is available. If both B2 and B3 are unavailable, _A2 is used. If all three candidates are unavailable, CP1 motion information cannot be obtained.

For CP2, the check priority is B _1- > B ₀ .

For CP3, the check priority is A _1- > A ₀ .

For CP4, T is used.

Second, the combination of control points is used to construct the affine merge candidates.

Motion information of the three control points is needed to construct the six-parameter affine candidates. The three control points are from one of the following four combinations ({CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4}). Can be selected. The combinations {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4} are transformed into a 6-parameter motion model represented by the upper left, upper right, and lower left control points.

Motion vectors of two control points are needed to construct a four-parameter affine candidate. The two control points are among the following six combinations ({CP1, CP4}, {CP2, CP3}, {CP1, CP2}, {CP2, CP4}, {CP1, CP3}, {CP3, CP4}). Can be selected from one of. The combinations {CP1, CP4}, {CP2, CP3}, {CP2, CP4}, {CP1, CP3}, {CP3, CP4} are transformed into a four-parameter motion model represented by the upper left and upper right control points.

The configured combinations of affine candidates are in the following order: {CP1, CP2, CP3}, {CP1, CP2, CP4}, {CP1, CP3, CP4}, {CP2, CP3, CP4}, {CP1, CP2} , {CP1, CP3}, {CP2, CP3}, {CP1, CP4}, {CP2, CP4}, {CP3, CP4} are inserted into the candidate list.

For the combination reference list X (where X is 0 or 1), the reference index with the highest utilization among the control points is selected as the reference index for list X, and the motion vector pointing to the differential reference picture is scaled. Will be done.

After the candidates are derived, a full pruning process is performed to check if the same candidates are inserted in the list. If the same candidate exists, the derived candidate is discarded.

3) Padding with zero motion vector If the number of candidates in the affine merge candidate list is less than 5, a zero motion vector with a zero reference index is inserted into the candidate list until the list is full.

[2.5.2 Example affine merge mode]
In some embodiments, the affine merge mode can be simplified as follows.

1) The pruning process for the inherited affine candidates is simplified by comparing the coding units covering the adjacent positions instead of comparing the affine candidates derived in VTM-2.0.1. Up to two inherited affine candidates are inserted into the affine merge list. The pruning process for the configured affine candidates is deleted as a whole.

2) The MV scaling operation in the configured affine candidates is deleted. If the reference indexes of the control points are different, the constructed motion model is discarded.

3) The number of configured affine candidates is reduced from 10 to 6.

4) In some embodiments, other merge candidates by subblock prediction, such as ATMVP, are also included in the affine merge candidate list. In that case, the affine merge candidate list may be renamed with some other name, such as the subblock merge candidate list.

[2.6 Example control point MV offset for affine merge mode]
New affine merge candidates are generated based on the CPMV offset of the first affine merge candidate. If the first affine merge candidate enables the four-parameter affine model, two CPMVs for each new affine merge candidate are derived by offsetting the two CPMVs of the first affine merge candidate, otherwise (6). To enable the parameter affine model), three CPMVs for each new affine merge candidate are derived by offsetting the three CPMVs for the first affine merge candidate. In one-sided prediction, the CPMV offset is applied to the first candidate CPMN. In the bi-prediction with Listing 0 and Listing 1 in the same direction, the CPMN offset applies to the first candidate as follows:
MV _{new (L0), i} = MV _{old (L0)} + MV _{offset (i)} Equation (8)
MV _{new (L1), i} = MV _{old (L1)} + MV _{offset (i)} Equation (9)

In the bidirectional prediction by Listing 0 and Listing 1, the CPMV offset is applied to the first candidate as follows:
MV _{new (L0), i} = MV _{old (L0)} + MV _{offset (i)} Equation (10)
MV _{new (L1), i} = MV _{old (L1)} -MV _{offset (i)} equation (11)

Different offset directions with different offset sizes can be used to generate new affine merge candidates. Two practices were tested.

(1) 16 new affine merge candidates with 2 different offset sizes and 8 different offset directions are the next set of offsets:

Offset set = {(4,0), (0,4), (-4,0), (0, -4), (-4, -4), (4, -4), (4, 4) ), (-4,4), (8,0), (0,8), (-8,0), (0,-8), (-8,-8), (8,-8), (8,8), (-8,8)}

Generated as shown by.

The affine merge list is increased to 20 for this design. The total number of possible affine merge candidates is 31.

(2) Four affine merge candidates with four different offset directions with one offset size are the next set of offsets:

Offset set = {(4,0), (0,4), (-4,0), (0, -4)}

Generated as shown by.

The affine merge list is kept at 5 as VTM 2.0.1. The four time-reconstructed affine merge candidates are excluded so as not to change the number of possible affine merge candidates (eg, 15 in total). It is assumed that the coordinates of CPMV1, CPMV2, CPMV3, and CPMV4 are (0,0), (W,0), (H,0), and (W, H). Note that CPMV4 is derived from temporal MV as shown in FIG. The excluded candidates are the following four time-related reconstructed affine merge candidates: {CP2, CP3, CP4}, {CP1, CP4}, {CP2, CP4}, {CP3, CP4}. ..

[2.7 Bandwidth problem of affine motion compensation]
Since the current block is divided into 4x4 subblocks for the luma component and 2x2 subblocks for the two chroma components to provide motion compensation, the total bandwidth requirement is from the non-subblock interprediction. Is much higher. Several approaches are proposed to address the bandwidth problem.

[2.7.1 Example 1]
4x4 blocks are used as the subblock size of the unidirectional affine-coded CU, while 8x4 / 4x8 blocks are used as the subblock size of the bidirectional predictive affine-coded CU.

[2.7.2 Example 2]
For affine modes, the affine CU subblock motion vector is constrained to be within a predefined motion vector field. Assuming that the motion vector of the first (upper left) subblock is (v _0x , v _0y ) and the second subblock is ( _vix , _viy ), the values of _vix and _viy are the following constraints. Shows:

v _ix ∈ [v _0x −H, v _0x + H] Equation (12)
v _iy ∈ [v _0y −V, v _0y + V] Equation (13)

If the motion vector of any subblock exceeds a predefined motion vector field, the motion vector is clipped. An example of the idea of a constrained subblock motion vector is given in FIG.

Given that the memory is read per CU rather than per subblock, the values H and V are chosen so that the worst memory bandwidth of the affine CU does not exceed that of the normal inter-MC of the 8x8 dual predictor block. Will be done. Note that the values of H and V are adaptable to CU size and single or bi-prediction.

[2.7.3 Example 3]
To reduce the memory bandwidth requirement in affine prediction, each 8x8 block within a block is considered as the basic unit. The MVs of all four 4x4 subblocks in an 8x8 block are constrained so that the maximum difference between the integer parts of the four 4x4 subblocks is no greater than one pixel. As a result, the bandwidth is (8 + 7 + 1) × (8 + 7 + 1) / (8 × 8) = 4 samples / pixel.

In some cases, after the MVs of all subblocks in the current block have been calculated by the affine model, the MVs of the subblocks containing the control points are first replaced by the corresponding control point MVs. This means that the MVs of the upper left, upper right, and lower left subblocks are replaced by the upper left, upper right, and lower left control point MVs, respectively. Then, for each 8x8 block in the current block, the MVs of all four 4x4 subblocks ensure that the maximum difference between the integer parts of those four MVs is no greater than one pixel. It is clipped like. It should be noted here that the subblocks containing the control points (upper left, upper right and lower left subblocks) use the corresponding control point MV to be involved in the MV clipping process. During the clipping process, the MV at the upper right control point is invariant.

The clipping process applied to each 8x8 block is described as follows.

1. 1. The minimum and maximum values of the MV components MVminx, MVminy, MVmaxx, MVmaxy are first determined for each 8x8 block as follows:
a) Obtain the smallest MV component among the four 4x4 subblock MVs MVminx = min (MVx0, MVx1, MVx2, MVx3)
MVminy = min (MVy0, MVy1, MVy2, MVy3)
b) MVminx = MVminx >> MV_precision << MV_precision using the integer part of MVminx and MVminy as the minimum MV component
MVminy = MVminy >> MV_precision << MV_precision
c) The maximum MV component is calculated as follows:
MVmaxx = MVminx + (2 << MV_precision) -1
MVmaxy = MVminy + (2 << MV_precision) -1
d) When the upper right control point is in the current 8x8 block MVminx = (MV1x >> MV_precision)-(1 << MV_precision) if MV1x> MVmaxx
MVmaxx = MVminx + (2 << MV_precision) -1
If MV1y> MVmaxy,
MVminy = (MV1y >> MV_prescription << MV_precision)-(1 << MV_precision)
MVmaxy = MVminy + (2 << MV_precision) -1

2. 2. The MV component of each 4x4 block in this 8x8 block is clipped as follows:
MVxi = max (MVminx, min (MVmaxx, MVxi))
MVyi = max (MVminy, min (MVmaxy, MVyi))

Here, (MVxi, MVyi) is the MV of the i-th subblock in one 8 × 8 block, i is 0, 1, 2, 3 and (MV1x, MV1y) is the upper right control point. MV_precision is equal to 4 corresponding to 1/16 motion vector fractional accuracy. Since the difference between the integer parts of MVminx and MVmaxx (MVminy and MVmaxy) is 1 pixel, the maximum difference between the integer parts of the four 4x4 subblock MVs is not greater than 1 pixel.

Similar methods may be used to handle planar modes in some embodiments.

[2.7.4 Example 4]
In some embodiments, a limitation to the affine mode for bandwidth reduction in the worst case. To ensure that the worst-case bandwidth of the affine block is not worse than the INTER_4 × 8 / INTER_8 × 4 block or INTER_9 × 9 block, the motion vector difference between the affine control points is a subblock of the affine block. Used to determine if the size is 4x4 or 8x8.

<General affine restrictions to reduce bandwidth in the worst case>
Memory bandwidth reduction for affine mode is controlled by limiting motion vector differences (also referred to as control point differences) between affine control points. In general, affine motion uses 4x4 subblocks (ie, 4x4 affine mode) if the control point difference satisfies the following limitations: If not, it is using an 8x8 subblock (8x8 affine mode). Limitations for the 6-parameter and 4-parameter models are given as follows.

To derive constraints for different block sizes (w × h), the motion vector differences at the control points are:
Norm (v _1x -v _0x ) = (v _1x -v _0x ) x (128 / w)
Norm (v _1y -v _0y ) = (v _1y -v _0y ) x (128 / w)
Norm (v _2x -v _0x ) = (v _2x -v _0x ) x (128 / h)
Norm (v _2y −v _0y ) = (v _2y −v _0y ) × (128 / h) Equation (14)
Normalized as.

In the 4-parameter affine model, (v _2x − v _0x ) and (v _2y − v _0y ) are set as follows:
(V _2x -v _0x ) =-(v _1y -v _0y )
(V _2y -v _0y ) =-(v _1x -v _0x ) Equation (15)

Therefore, the norms of (v _2x -v _0x ) and (v _2y -v _0y ) are:
Norm (v _2x -v _0x ) =-Norm (v _1y -v _0y )
Norm (v _2y -v _0y ) = Norm (v _1x -v _0x ) Equation (16)
Is given.

The limitation to ensure bandwidth in the worst case is to achieve INTER_4x8 or INTER_8x4:
| Norm (v _1x -v _0x ) + Norm (v _2x -V _0x ) + 128 | +
| Norm (v _1y -v _0y ) + Norm (v _2y -v _0y ) + 128 | +
| Norm (v _1x -v _0x ) -Norm (v _2x -v _0x ) | +
| Norm (v _1y -v _0y ) -Norm (v _2y -v _0y ) |
<128 × 3.25 formula (17)

Here, the left side of the equation (17) represents the shrink or span level of the subaffe block, while (3.25) represents the pixel shift of 3.25.

The limitation to ensure bandwidth in the worst case is to achieve INTER_9x9:
(4 x Norm (v _1x -v _0x )> -4 x pel && + 4 x Norm (v _1x -v _0x ) <pel) &&
(4 x Norm (v _1y -v _0y )>-pel && 4 x Norm (v _1y -v _0y ) <pel) &&
(4 x Norm (v _2x -v _0x )> -pel && 4 x Norm (v _2x -v _0x ) <pel) &&
(4 × Norm (v _2y − v _0y )> -4 × pel && 4 × Norm (v _2y − v _0y ) <pel) &&
((4 x Norm (v _1x -v _0x ) + 4 x Norm (v _2y -v _0y )> -4 x pel) &&
(4 x Norm (v _1x -v _0x ) + 4 x Norm (v _2x -v _0x ) <pel)) &&
((4 x Norm (v _1y -v _0y ) + 4 x Norm (v _2x -v _0x )> -4 x pel) &&
(4 x Norm (v _1y -v _0y ) + 4 x Norm (v _2y -v _0yx ) <pel))
Equation (18)

Here, pel = 128 × 16 (128 and 16 are normalization coefficients and motion vector accuracy, respectively).

[2.8 Generalized double prediction improvement]
Some embodiments have improved the trade-off between gain and complexity for GBi and have been adopted in BMS 2.1. GBi is also called Bi-prediction with CU-level Weight (BCW). BMS 2.1 GBi applies unequal weights to predictors from L0 and L1 in bi-prediction mode. In inter-prediction mode, multiple weight pairs containing equal weight pairs (1/2, 1/2) are evaluated based on Rate-Distortion Optimization (RDO) and the selected weight pair GBi. The index is notified to the decoder. In merge mode, the GBi index is inherited from the adjacent CU. In BMS2.1 GBi, predictor generation in bi-predictive mode is shown in Eq. (19):

P _GBi = (w ₀ x P _L0 + w ₁ x P _L1 + RoundingOffset _GBi )
>> shiftNum _GBi formula (19)

Here, PGBi is the final predictor of _GBi . w ₀ and w ₁ are selected GBi weight pairs, which apply to List 0 (L0) and List 1 (L1), respectively. The RoundingOffset _GBi and shiftNum _GBi are used to normalize the final predictor in the GBi. The supported w ₁ is set to {-1 / 4,3 / 8, 1/2, 5/8, 5/4}, and these five weights are one equal weight pair and four unequal weight pairs. Corresponds to. The blending gain, for example the sum of w ₁ and w ₀ , is fixed at 1.0. Therefore, the corresponding w0 weight set is {5 / 4,5 / 8,1 / 2,3 / 8, -1/4 _} . Weight vs. selection is at the CU level.

For non-low latency pictures, the weight set size is reduced from 5 to 3. At this time, the w ₁ weight set is {3/8, 1/2, 5/8}, and the w ₀ weight set is {5/8, 1/2, 3/8}. The weight set size reduction for non-low latency pictures applies to BMS 2.1 GBi and all GBi tests in this contribution.

In some embodiments, the following changes are applied on top of the existing GBi design in BMS 2.1 to further improve GBi performance.

[2.8.1 GBi encoder bug fix]
To reduce the GBi encoding time, in the current encoder design, the encoder stores one-sided predictive motion vectors estimated from GBi weights equal to 4/8 and uses them for one-sided predictive search of other GBi weights. To reuse. This fast encoding method applies to both translational and affine motion models. In VTM2.0, a 6-parameter affine model was adopted together with a 4-parameter affine model. The BMS 2.1 encoder does not distinguish between a 4-parameter affine model and a 6-parameter affine model when the GBi weight is equal to 4/8 and it holds a one-sided predictive affine MV. As a result, the 4-parameter affine MV can be overwritten by the 6-parameter affine MV after encoding with the GBi weight 4/8. The conserved 6-parameter affine MV may be used for a 4-parameter affine ME for other GBi weights, or the conserved 4-parameter affine MV may be used for a 6-parameter affine ME. There is a possibility. The proposed GBi encoder bug fix is to separate the 4-parameter and 6-parameter affine MV storage. The encoder stores these affine MVs based on the affine model type when the GBi weight is equal to 4/8 and reuses the corresponding affine MVs based on the affine model types of other GBi weights.

[2.8.2 CU size constraint for GBi]
In this method, GBi is disabled for small CUs. In inter-prediction mode, bi-prediction is used and when the CU area is smaller than 128 luma samples, GBi is unknowingly disabled without any signaling.

[2.8.3 Merge mode by GBi]
According to the merge mode, the GBi index is not notified. Instead, it is inherited from the adjacent block to which it is merged. If a TMVP candidate is selected, GBi is turned off in this block.

[2.8.4 GBi affine prediction]
GBi can be used if the current block is coded by affine prediction. For the affine intermode, the GBi index is notified. For affine merge mode, the GBi index is inherited from the adjacent block to which it is merged. If the configured affine model is selected, GBi is turned off in this block.

[2.9 Examples of Inter-Intra Prediction Mode (IIP)]
According to the Inter-Intra Prediction Mode, also known as Inter and Intra Composite Prediction (CIIP), a multi-hypothesis prediction combines one intra prediction and one merge indexing prediction. Such blocks are treated as special intercoding blocks. In the merge CU, one flag is notified about the merge mode in order to select the intra mode from the intra candidate list if the flag is true. For the luma component, the intra-candidate list is derived from four intra-prediction modes, including DC, planar, horizontal, and vertical modes, and the size of the intra-candidate list can be 3 or 4 depending on the block shape. .. If the CU width is greater than twice the CU height, the horizontal mode is removed from the intramode list, and if the CU height is greater than twice the CU height, the vertical mode is removed from the intralist mode. One intra prediction mode selected by the intramode index and one merge indexing prediction selected by the merge index are combined using a weighted average. For chroma components, DM is always applied, regardless of extra signaling.

The weights for combining the predictions are explained as follows. If DC or planar mode is selected, or if the CB width or height is less than 4, equal weights are applied. For CBs with a CB width and height of 4 or greater, one CB is initially divided vertically / horizontally into four areas of equal area when the horizontal / vertical mode is selected. .. i is 1 to 4, (w_intra ₁ , w_inter ₁ ) = (6, 2), (w_intra ₁ , w_inter ₂ ) = (5, 3), (w_intra ₃ , w_inter ₃ ) = (3, 5), And (w_intra ₄ , w_inter ₄ ) = (2, 6), each weight set represented by (w_intra _i , w_inter _i ) will be applied to the corresponding region. (W_intra ₁ , w_inter ₁ ) is for the region closest to the reference sample, and (w_intra ₄ , w_inter ₄ ) is for the region farthest from the reference sample. The combined predictions can then be calculated by summing the two weighted predictions and shifting them to the right by 3 bits. In addition, the intra-prediction mode for the predictor's intra-hypothesis may be saved for the next adjacent CU reference.

It is assumed that the intra and inter predicted values are Pintra and PInter, and the weighting factors are w_intra and w_inter, respectively. The predicted value at the position (x, y) is calculated as (Pintra (x, y) × w_intra (x, y) + Pinter (x, y) × w_inter (x, y)) >> N. Here, w_intra (x, y) + w_inter (x, y) = ^2N .

<Intra-predictive mode signaling in IIP coding block>
When the inter-intra mode is used, one of four allowed intra prediction modes, DC, planar, horizontal and vertical, is selected and notified. The three most probable modes (Most Probable Mode (s), MPM) consist of left and upper adjacent blocks. The intra-prediction mode of an intra-coded adjacent block or an IIP-coded adjacent block is treated as one MPM. If the intra prediction mode is not one of the four allowed intra prediction modes, it will be rounded to vertical or horizontal mode depending on the angle difference. The adjacent block should be on the same CTU line as the current block.

It is assumed that the width and height of the current block are W and H. If W> 2 × H or H> 2 × W, only one of the three MPMs can be used in inter-intra mode. If not, all four valid intra prediction modes are available in inter-intra mode.

It should be noted that the intra prediction mode in the inter-intra mode cannot be used to predict the intra prediction mode in a normal intracoded block.

Inter-intra prediction can only be used when W × H> = 64.

[Triangle prediction mode as an example of 2.10]
The concept of Triangular Prediction Mode (TPM) is to introduce a new triangular partition for motion-compensated prediction. As shown in FIGS. 7A-7B, it divides the CU into two triangular prediction units, either diagonally or counter-diagonally. Each triangular prediction unit in the CU is inter-predicted using its own one-sided motion vector and reference frame index derived from the one-sided prediction candidate list. The adaptive weighting process is performed on the diagonals after predicting the triangular prediction unit. The transformation and quantization process is then applied to the entire CU. This mode is known to apply only to skip and merge modes.

[2.10.1 TPM Candidate List]
The one-sided prediction candidate list consists of five one-sided prediction motion vector candidates. It is derived from seven adjacent blocks, including five spatially adjacent blocks (1-5) and two time-coordinate blocks (6-7), as shown in FIG. The motion vectors of the seven adjacent blocks are collected and the order of the one-sided prediction motion vectors, the L0 motion vector of the bi-predicted motion vector, the L1 motion vector of the bi-predicted motion vector, and the averaging of the L0 and L1 motion vectors of the bi-predicted motion vector. It is placed in the one-sided prediction candidate list according to the motion vector. If the number of candidates is less than 5, a zero motion vector is added to the list. The motion candidates added to this list are called TPM motion candidates.

More specifically, it involves the following steps:

1) Movement candidates are acquired from A ₁ , B ₁ , B ₀ , A ₀ , B ₂ , Col and Col 2 (corresponding to blocks 1 to 7 in FIG. 8) regardless of any pruning operation.

2) Set the variable numCurrMergeCand = 0.

3) When each movement candidate is derived from A ₁ , B ₁ , B ₀ , A ₀ , B ₂ , Col and Col 2, and the numCurrMergeCand is smaller than 5, the movement candidate is one-sided prediction (either List 0 or List 1). If (from one), it is added to the merge list by incrementing the numCurrMergeCand by 1. Such added movement candidates are called "originally uni-predicted candidates". Full pruning is applied.

4) If each movement candidate is derived from A ₁ , B ₁ , B ₀ , A ₀ , B ₂ , Col and Col 2, and the numCurrMergeCand is smaller than 5, and the movement candidate is bipredicted, from list 0. The movement information of is added to the merge list (that is, changed to be a one-sided prediction from list 0), and the numCurrMergeCand is incremented by 1. Such added candidates are referred to as "Truncated List0-predicted candidates". Full pruning is applied.

5) If each movement candidate is derived from A ₁ , B ₁ , B ₀ , A ₀ , B ₂ , Col and Col 2, and the numCurrMergeCand is smaller than 5, then the movement candidate is bipredicted from Listing 1. The movement information of is added to the merge list (that is, changed to be a one-sided prediction from the list 1), and the numCurrMergeCand is incremented by 1. Such added candidates are referred to as "Truncated List1-predicted candidates". Full pruning is applied.

6) If each movement candidate is derived from A ₁ , B ₁ , B ₀ , A ₀ , B ₂ , Col and Col 2, and the numCurrMergeCand is smaller than 5, then the movement candidate is bipredicted.
-If the slice quantization parameter (QP) of the list 0 reference picture is smaller than the slice QP of the list 1 reference picture, the motion information of list 1 is first scaled to the list 0 reference picture and two MVs (one is). The average from the original list 0 and the other is the scaled MV from list 1) is added to the merge list. This is an averaged piece prediction from the list 0 movement candidates, and the numCurrMergeCand is incremented by 1.
-Otherwise, the motion information in Listing 0 is first scaled to the Listing 1 reference picture, two MVs (one from the original Listing 1 and the other from Listing 0). ) Is added to the merge list. This is an averaged piece prediction from the list 1 movement candidates, and the numCurrMergeCand is incremented by 1.

Full pruning is applied.

7) When the numCurrMergeCand is smaller than 5, zero motion vector candidates are added.

[2.11 Decoder-side motion vector refinement (DMVR) in VVC]
For DMVR in VVC, MVD mirroring between Listing 0 and Listing 1 is considered as shown in FIG. 13, and bilateral matching is used to refine the MV, eg, for some MVD candidates. It is executed to find the best MVD among them. The MVs of the two reference pictures are represented by MVL0 (L0X, L0Y) and MVL1 (L1X, L1Y). The MVD represented by (MvdX, MvdY) for Listing 0 that can minimize the cost function (eg SAD) is defined as the best MVD. For the SAD function, it was derived by the motion vector (L0X + MvdX, L0Y + MvdY) in the list 0 reference picture and by the motion vector (L1X-MvdX, L1Y-MvdY) in the list 1 reference picture. Defined as SAD to and from the reference block in Listing 1.

The motion vector refinement process may be repeated twice. At each iteration, at most 6 MVDs (with integer pel precision) are checked in two steps, as shown in FIG. In the first step, MVD (0,0), (-1,0), (1,0), (0, -1), (0,1) are checked. In the second step, one of MVD (-1, -1), (-1, 1), (1, -1), or (1, 1) may be selected and further checked. Suppose the function Sad (x, y) returns the SAD value of MVD (x, y). The MVD represented by (MvdX, MvdY) checked in the second step is determined as follows:
MvdX = -1;
MvdY = -1;
if (Sad (1,0) <Sad (-1,0))
MvdX = 1;
if (Sad (0,1) <Sad (0, -1))
MvdY = 1

In the first iteration, the starting point is the notified MV, and in the second iteration, the starting point is the notified MV plus the best selected MVD in the first iteration. DMVR applies only if one reference picture is a leading picture, the other reference picture is a trailing picture, and the two reference pictures are at the same picture order count distance from the current picture.

To further simplify the DMVR process, the following key features can be implemented in some embodiments.

1. 1. Early termination when the (0,0) position SAD between Listing 0 and Listing 1 is less than the threshold.

2. 2. Early termination if the SAD between Listing 0 and Listing 1 is zero for some position.

3. 3. Assuming that W and H are the width and height of the block, the block size of DMVR: W × N> = 64 && H> = 8.

4. If the DMVR has a CU size> 16x16, the CU is divided into a plurality of 16x16 subblocks. If only the width or height of the CU is greater than 16, it will only be split vertically or horizontally.

5. Reference block size (W + 7) x (H + 7) (about luma).

6.25 point SAD-based integer pel search (eg, (+-) 2 refined search range, single stage).

7. DMVR based on bilinear interpolation.

8. Subpel refinement based on "parametric error surface equations". This procedure is performed only if the minimum SAS cost is not equal to zero and the best MVD is (0,0) in the last MV refinement iteration.

9. Ruma / Chroma MC with reference block padding (if required).

10. A refined MV used only for MC and TMVP.

[2.11.1 Use of DMVR]
DMVR can be enabled if all of the following conditions are true:
-The DMVR enable flag in the SPS (eg sps_dmvr_enabled_flag) is equal to 1.
-The TPM flag, interaffine flag, subblock merge flag (either ATMVP or affine merge), and MMVD flag are all equal to 0.
-The merge flag is equal to 1.
-The current block is bi-predicted and the Picture Order Count (POC) distance between the current picture and the reference picture in List 1 is between the reference picture in List 0 and the current picture. Equal to the POC distance between.
-Current CU height is 8 or more.
-The number of luma samples (CU width x height) is 64 or more.

[2.11.2 Subpel refinement based on "parametric error surface equation"]
The method is summarized below.

1. 1. Parametric error surface fit is calculated only if the center position is the best cost position in a given iteration.

2. 2. The center position cost and the cost at (-1,0), (0, -1), (1,0), and (0,1) positions from the center are as follows:

E (x, y) = A (x-x ₀ ) ² + B (y-y ₀ ) ² + C

Used to fit the two-dimensional radiation error surface equation of. Here, (x ₀ , y ₀ ) corresponds to the position having the minimum cost, and C corresponds to the minimum cost value. By solving 5 equations of 5 unknowns, (x ₀ , y ₀ ) is:

x ₀ = (E (-1,0) -E (1,0)) / (2E (-1,0) + E (1,0) -2E (0,0))
y ₀ = (E (0, -1) -E (0, 1)) / (2E (0, -1) + E (0, 1) -2E (0, 0))

Is calculated. (X ₀ , y ₀ ) can be calculated for any required subpixel accuracy by adjusting the accuracy with which the division is performed (eg, how many bits of the quotient are calculated). For 1/16 pel accuracy, only 4 bits of the absolute value of the quotient need to be calculated. This is useful for implementing a fast shift subtraction base of the two divisions required for each CU.

3. 3. The calculated (x ₀ , y ₀ ) is added to the integer distance refinement MV to obtain the exact refinement delta MV for the subpixels.

[2.11.3 Required reference sample in DMVR]
For blocks of size W × H, it is assumed that the maximum permissible MVD value is ± offSet (eg, 2 for VVC) and the filter size is filterSize (eg, for VVC, 8 for luma and 4 for chroma). Therefore, (W + 2 × offSet + filterSize-1) × (H + 2 × offSet + filterSize-1) reference samples are required. In order to reduce the memory bandwidth, the central (W + filterSize-1) × (H + filterSize-1) reference samples are fetched, and the remaining pixels are generated by repeating the boundaries of the fetched samples. An example of an 8x8 block is shown in FIG. 15, where 15x15 reference samples are fetched and the bounds of the fetched samples are repeated to generate a 17x17 region.

During motion vector refinement, bilinear motion compensation is performed using those reference samples. On the other hand, final motion compensation is also performed using those reference samples.

[2.12 Bandwidth calculation for different block sizes]
Based on the current 8-tap ruma interpolation filter and 4-tap chroma interpolation filter, the memory bandwidth of each block unit (4: 2: 0 color format, one MxN with two M / 2xN / 2 chroma blocks. Luma blocks) are displayed in Table 1 below.

Similarly, based on the current 8-tap ruma interpolation filter and 4-tap chroma interpolation filter, the memory bandwidth of each M × N luma block unit is tabulated in Table 2 below.

Therefore, regardless of the color format, the bandwidth requirements for each block size in descending order are:
4x4Bi>4x8Bi>4x16Bi>4x4Uni>8x8Bi>4x32Bi>4x64Bi>4x128Bi>8x16Bi>4x8Uni>8x32Bi> ...
Is.

[2.13 Motion vector accuracy problem in VTM-3.0]
In VTM-3.0, the MV accuracy is 1/16 luma pixels in storage. When the MV is signaling, the finest precision is 1/4 luma pixel.

[3. Examples of issues solved by the disclosed embodiments]
1. 1. Bandwidth control methods for affine accuracy are not clear enough and should be more flexible.

2. 2. In HEVC design, in the worst case of memory bandwidth requirements, even if the coding unit (CU) can be split by asymmetric precision mode (eg, it is split into PUs of equal size to 4x16 and 12x16). One 16x16), 8x8 twin prediction. In VVC, the new QTBT partition structure allows one CU to be set to 4x16 and bi-prediction could be enabled. The bi-predicted 4x16CU requires much higher memory bandwidth compared to the bi-predicted 8x8CU. No method is known for dealing with block sizes that require higher bandwidth (eg, 4x16 or 16x4).

3. 3. New coding tools such as GBi introduce more line buffer problems.

4. Inter-intra mode requires more memory and logic to convey the intra prediction mode used in the intercoded block.

1/16 Luma Pixel MV accuracy requires higher memory storage.

6. In order to interpolate four 4x4 blocks within one 8x8 block, it is necessary to fetch (8 + 7 + 1) x (8 + 7 + 1) reference pixels, non-affine / non-planar mode 8x8 blocks. Requires about 14% more pixels when compared to.

7. The averaging behavior in intra- and inter-composite predictions should be aligned with other coding tools such as weighted predictions, local luminance compensation, OBMC and triangular predictions, and offsets are added prior to the shift.

[4. Example of embodiment]
The techniques disclosed herein can reduce the bandwidth and line buffer required by affine prediction and other new coding tools.

The following description should be considered as an example to illustrate the general concept and should not be construed in a narrow sense. Further, the embodiments can be combined in any way.

In the discussion below, the widths and heights of the current affine-coded CUs are w and h, respectively. It is assumed that the interpolation filter tap (in motion compensation) is N (eg, 8, 6, 4 or 2) and the current block size is W × H.

<Bandwidth control for affine prediction>
Example 1: If the motion vector of the subblock SB in the affine-coded block is MV _SB (represented as (MVx, MVy)), the MV _SB is a representative motion vector MV'(MV). It can be within a specific range for'x, MV'y).

In some embodiments, MVx> = MV'x-DH0 and MVx <= MV'x + DH1 and MVy> = MV'y-DV0 and MVy <= MV'y + DV1 where MV'= (MV' x, MV'y). In some embodiments, DH0 may or may not be equal to or equal to DH1, and DV0 may or may not be equal to DV1. In some embodiments, DH0 may or may not be equal to DV0 and DH1 may or may not be equal to DV1. In some embodiments, DH0 does not have to be equal to DH1 and DV0 does not have to be equal to DV1. In some embodiments, the DH0, DH1, DV0 and DV1 may be notified from the encoder to the decoder, eg, in VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU / PU. In some embodiments, DH0, DH1, DV0 and DV1 may be specified differently for different standard profiles / levels / tiers. In some embodiments, DH0, DH1, DV0 and DV1 may depend on the width and height of the current block. In some embodiments, DH0, DH1, DV0 and DV1 may depend on whether the current block is single-predictive or bi-predictive. In some embodiments, DH1, DH1, DV0 and DV1 may depend on the position of the subblock SB. In some embodiments, DH0, DH1, DV0 and DV1 may depend on the method of obtaining MV'.

In some embodiments, the MV'can be one CPMV, such as MV0, MV1 or MV2.

In some embodiments, the MV'can be the MV used in the MC for one of the corner subblocks, such as MV0', MV1', or MV2' in FIG.

In some embodiments, the MV'can be an MV derived using the affine model of the current block, either inside or outside the current block. For example, it may be derived for the center position of the current block (eg x = w / 2 and y = h / 2).

In some embodiments, MV'has been used in the MC for any subblock of the current block, such as one of the central subblocks (C0, C1, C2 or C3 shown in FIG. 3). It can be MV.

In some embodiments, if the MV _SB does not meet the constraints, the MV _SB should be clipped to a valid area. In some embodiments, the clipped MV _SB is stored in the MV buffer and subsequently used to predict the MV of the coded block. In some embodiments, the MV _SB before clipping is stored in the MV buffer.

In some embodiments, the bitstream is considered non-compliant (invalid) if the MV _SB does not meet the constraints. In one example, the standard may specify that the MV _SB must or should meet the constraints. This constraint should be obeyed by any conforming encoder, otherwise the encoder is considered non-compliant.

In some embodiments, the MV _SB and MV'can be represented by signaling MV accuracy (eg, 1/4 pixel accuracy). In some embodiments, the MV _SB and MV'can be represented by a storage MV accuracy (eg, 1/16 accuracy). In some embodiments, the MV _SB and MV'may be rounded to a different precision (eg, integer precision) than the signaling or storage precision.

Example 2: For affine-coded blocks, each MxN (eg, 8x4, 4x8 or 8x8) block within the block is considered the basic unit. The MVs of all 4x4 subblocks in MxN are constrained so that the maximum difference between the integer parts of the four 4x4 subblocks MVs is no greater than K pixels.

In some embodiments, whether and how this constraint should be applied depends on whether the current block applies bi-prediction or one-sided prediction. For example, constraints apply only to bi-prediction, not to one-sided prediction. As another example, M, N and K differ for bi-prediction and one-sided prediction.

In some embodiments, M, N and K may depend on the width and height of the current block.

In some embodiments, whether the constraint should be applied may be notified from the encoder to the decoder, eg, VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU / PU. For example, an on / off flag is notified to indicate whether the constraint should be applied. As another example, M, N and K are notified.

In some embodiments, M, N and K may be specified differently for different standard profiles / levels / tiers.

Example 3: The width and height of the subblocks may be calculated differently for different, affine-coded blocks.

In some embodiments, the calculation method is different for each affine-coded block with one-sided and two-sided predictions. In one example, the subblock size is fixed for blocks with one-sided prediction (eg, 4x4, 4x8 or 8x4). In another example, the subblock size is calculated for blocks with bi-prediction. In this case, the subblock size may be different for each of the two different, bipredicted affine blocks.

In some embodiments, the width and / or height of the subblocks from reference list 0 and the width and / or height of the subblocks from reference list 1 may differ for the bipredicted affine blocks. In one example, the width and height of the subblocks from reference list 0 are Wsb0 and Hsb0, respectively, and the width and height of the subblocks from reference list 1 are Wsb1 and Hsb1, respectively. In that case, the final width and height of the subblocks for both Reference List 0 and Reference List 1 are calculated as Max (Wsb0, Wsb1) and Max (Hsb0, Hsb1), respectively.

In some embodiments, the calculated widths and heights of the subblocks apply only to the luma component. For the chroma component, it is always fixed, eg, a 4x4 chroma subblock corresponding to an 8x8 luma block in 4: 2: 0 color format.

In some embodiments, MVx-MV'x and MVy-MV'y are calculated to determine the width and height of the subblocks. (MVx, MVy) and (MV'x, MV'y) are defined in Example 1.

In some embodiments, the MV involved in the calculation can be represented by signaling MV accuracy (eg, 1/4 pixel accuracy). In one example, these MVs may be represented by storage MV accuracy (eg, 1/16 accuracy). As another example, these MVs may be rounded to a different precision (eg, integer precision) than the signaling or storage precision.

In some embodiments, the thresholds used in the calculations to determine the width and height of the subblock are from the encoder to the decoder, eg VPS / SPS / PPS / slice header / tile group header / tile / CTU. It may be notified in / CU / PU.

In some embodiments, the thresholds used in the calculations to determine the width and height of the subblocks may vary for different standard profiles / levels / tiers.

Example 4: (W2 + N-1-PW) × (H2 + N-1-PH) blocks are fetched first to interpolate the W1 × H1 subblock within one W2 × H2 subblock / block, and then the example. The pixel padding method described in 6 (eg, the boundary pixel iteration method) is applied to generate larger blocks. The larger block is then used to interpolate the W1 × H1 subblock. For example, W2 = H2 = 8, W1 = H1 = 4 and PW = PH = 0.

In some embodiments, the integer part of the MV of any W1xH1 subblock may be used to fetch the entire W2xH2 subblock / block, with different boundary pixel iteration methods accordingly. May be needed. For example, if the maximum difference between the MV integer parts of all W1 x H1 subblocks is not greater than 1 pixel, the MV integer part of the upper left W1 x H1 subblock is the W2 x H2 subblock / block. Used to fetch the entire. The right and bottom boundaries of the reference block are repeated once. As another example, when the maximum difference between the integer parts of the MV of all W1 × H1 subblocks is not greater than 1 pixel, the integer part of the MV of the lower right W1 × H1 subblock is W2 × H2. Used to fetch the entire subblock / block. The left and top boundaries of the reference block are repeated once.

In some embodiments, the MV of any W1xH1 subblock may be modified first and then used to fetch the entire W2xH2 subblock / block, with different boundary pixel iterations. Laws may be required accordingly. For example, if the maximum difference between the integer parts of the MV of all W1 × H1 subblocks is not greater than 2 pixels, the integer part of the MV of the upper left W1 × H1 subblock is increased by (1,1). Often (where 1 means 1 integer pixel distance), then used to fetch the entire W2 × H2 subblock / block. In this case, the left, right, top and bottom boundaries of the reference block are repeated once. As another example, if the maximum difference between the integer parts of the MVs of all W1xH1 subblocks is not greater than 2 pixels, then the integer part of the MVs of the lower right W1xH1 subblock is (-1). , -1) may be increased (where 1 means 1 integer pixel distance) and then used to fetch the entire W2 × H2 subblock / block. In this case, the left, right, top and bottom boundaries of the reference block are repeated once.

<Bandwidth control for a specific block size>
Example 5: If w and h of the current block satisfy one or more of the following conditions, bi-prediction is not allowed.

A. w is equal to T1 and h is equal to T2, or h is equal to T1 and w is equal to T2. In one example, T1 = 4 and T2 = 16.

B. w is equal to T1 and h is not greater than T, or h is equal to T1 and w is not greater than T2. In one example, T1 = 4 and T2 = 16.

C. w is not greater than T1 and h is not greater than T2, or h is not greater than T1 and w is not greater than T2. In one example, T1 = 8 and T2 = 8. In another example, T1 == 8 and T2 == 4. In another example, T1 == 4 and T2 == 4.

In some embodiments, bi-prediction may be disabled for 4x8 blocks. In some embodiments, bi-prediction may be disabled for 8x4 blocks. In some embodiments, bi-prediction may be disabled for 4x16 blocks. In some embodiments, bi-prediction may be disabled for 16x4 blocks. In some embodiments, bi-prediction may be disabled for 4x8, 8x4 blocks. In some embodiments, bi-prediction may be disabled for 4x16, 16x4 blocks. In some embodiments, bi-prediction may be disabled for 4x8, 16x4 blocks. In some embodiments, bi-prediction may be disabled for 4x16, 8x4 blocks. In some embodiments, biprediction may be disabled for 4 × N blocks, eg, N <= 16. In some embodiments, bi-prediction may be disabled for N × 4 blocks, eg, N <= 16. In some embodiments, bi-prediction may be disabled for 8 × N blocks, eg, N <= 16. In some embodiments, bi-prediction may be disabled for N × 8 blocks, eg, N <= 16. In some embodiments, bi-prediction may be disabled for 4x8, 8x4, 4x16 blocks. In some embodiments, bi-prediction may be disabled for 4x8, 8x4, 16x4 blocks. In some embodiments, bi-prediction may be disabled for 8x4, 4x16, 16x4 blocks. In some embodiments, bi-prediction may be disabled for 4x8, 8x4, 4x16, 16x4 blocks.

In some embodiments, the block size disclosed herein may refer to one color component, such as a luma component, and the determination as to whether bi-prediction is invalidated is for all color components. Can be applied to. For example, if bi-prediction is invalidated according to the block size of the block's luma component, bi-prediction is also invalidated for the corresponding blocks of other color components. In some embodiments, the block size disclosed herein may refer to one color component, such as a luma component, and the determination as to whether bi-prediction is invalidated is to that color component. Can only be applied.

In some embodiments, if bi-prediction is disabled for a block and the selected merge candidate is bi-predicted, then only one MV from reference list 0 or reference list 1 of that merge candidate is that block. Assigned to.

In some embodiments, the Triangular Prediction Mode (TPM) is not allowed for a block if bi-prediction is disabled for that block.

In some embodiments, the method of notifying the prediction direction (single prediction from list 0/1, double prediction) may depend on the block dimensions. In one example, 1) block width x block height <62, or 2) block width x block height = 64, but the width is not equal to the height, one-sided prediction from list 0/1. Instructions may be notified. As another example, if 1) block width x block height> 64, or 2) n width x block height = 64 and the width is equal to the height, the piece from list 0/1. Instructions for prediction or bi-prediction may be notified.

In some embodiments, both one-sided and two-sided predictions may be disabled for 4x4 blocks. In some embodiments, it may be disabled for affine-coded blocks. Alternatively, it may be disabled for non-affine coded blocks. In some embodiments, the instructions for quadtree splitting for 8x8 blocks, binary splitting for 8x4 or 4x8 blocks, and ternary splitting for 4x16 or 16x4 blocks are skipped. good. In some embodiments, the 4x4 block should be coded as an intrablock. In some embodiments, the 4x4 block MV should be in integer precision. For example, the IMV flag for 4x4 blocks should be 1. As another example, a 4x4 block MV should be rounded to integer precision.

In some embodiments, bi-prediction is allowed. However, if the interpolation filter tap is N, instead of fetching (W + N-1) × (H + N-1) reference pixels, (W + N-1-PW) × (H + N-1-PH) Only the reference pixel of is fetched. On the other hand, the pixels at the reference block boundaries (top, left, bottom and right boundaries) are the (W + N-1) × (H + N-1) blocks as shown in FIG. 9, which are used for the final interpolation. Is repeated to generate. In some embodiments, the PH is zero and only the left and / and right boundaries are repeated. In some embodiments, the PW is zero and only the upper and / and lower boundaries are repeated. In some embodiments, both PW and PH are greater than zero, first repeating the left and / and right boundaries, then repeating the upper and / and lower boundaries. In some embodiments, both PW and PH are greater than zero, first repeating the upper and / and lower boundaries, then repeating the left and / and right boundaries. In some embodiments, the left boundary is repeated M1 times and the right boundary is repeated PW-M1 times. In some embodiments, the upper boundary is repeated M2 times and the lower boundary is repeated PH-M2 times. In some embodiments, such a boundary pixel iteration method may be applied to some or all reference pixels. In some embodiments, PW and PH may be different for different color components such as Y, Cb and Cr.

FIG. 9 shows an example of repeating boundary pixels of the reference block before interpolation.

Example 6: In some embodiments, (W + N-1-PW) × (H + N-1-PH) reference pixels are replaced by ((W + N-1) × (H + N-1) reference pixels. ) It may be fetched for motion compensation of the W × H block. Samples outside the range (W + N-1-PW) × (H + N-1-PH) but within (W + N-1) × (H + N-1) are padded to perform the interpolation process. In one padding method, the pixels at the reference block boundaries (top, left, bottom and right boundaries) are used for the final interpolation, as shown in FIG. 11 (W + N-1) × (H + N). -1) Repeated to generate blocks.

In some embodiments, the PH is zero and only the left and / and right boundaries are repeated.

In some embodiments, the PW is zero and only the upper and / and lower boundaries are repeated.

In some embodiments, both PW and PH are greater than zero, first repeating the left and / and right boundaries, then repeating the upper and / and lower boundaries.

In some embodiments, both PW and PH are greater than zero, first repeating the upper and / and lower boundaries, then repeating the left and / and right boundaries.

In some embodiments, the left boundary is repeated M1 times and the right boundary is repeated PW-M1 times.

In some embodiments, the upper boundary is repeated M2 times and the lower boundary is repeated PH-M2 times.

In some embodiments, such a boundary pixel iteration method may be applied to some or all reference pixels.

In some embodiments, PW and PH may be different for different color components such as Y, Cb and Cr.

In some embodiments, the PW and PH may be different for different block sizes or shapes.

In some embodiments, PW and PH may differ for one-sided and two-sided predictions.

In some embodiments, the padding may not be performed in affine mode.

In some embodiments, samples that are outside the range (W + N-1-PW) x (H + N-1-PH) but within (W + N-1) x (H + N-1) are single values. Set to be. In some embodiments, the single value is 1 << (BD-1), where BD is the bit depth of the sample, eg 8 or 10. In some embodiments, the single value is notified from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU / PU. In some embodiments, the single value is derived from a sample within the range (W + N-1-PW) × (H + N-1-PH).

Example 7: Instead of fetching (W + filterSize-1) × (H + filterSize-1) samples in DMVR, (W + filterSize-1-PW) × (H + filterSize-1-PH) reference samples may be fetched. All other required samples may be generated by repeating the boundaries of the fetched reference samples, where PW> = 0 and PH> = 0.

In some embodiments, the method proposed in Example 6 may be used to pad an unfetched sample.

In some embodiments, the padding does not have to be performed again in the final motion compensation of the DMVR.

In some embodiments, whether or not the above method should be applied may depend on the block dimensions.

Example 8: The signaling method of inter_pred_odc may depend on whether w and h satisfy the condition of Example 5. An example is shown in Table 3 below.

Other examples are shown in Table 4 below.

Another example is shown in Table 5 below.

Example 9: The merge candidate list construction process may depend on whether w and h satisfy the condition of Example 4. The following embodiment describes the case where w and h satisfy the conditions.

In some embodiments, if one merge candidate uses bi-prediction, only the predictions from reference list 0 are retained and the merge candidates are treated as one-sided predictions that refer to reference list 0.

In some embodiments, if one merge candidate uses bi-prediction, only the predictions from reference list 1 are retained and the merge candidates are treated as one-sided predictions that refer to reference list 1.

In some embodiments, if one merge candidate uses bi-prediction, the candidate is treated as unusable. That is, such merge candidates are excluded from the merge list.

In some embodiments, the merge candidate list construction process for triangular prediction mode is used instead.

Example 10: The coding tree division process may depend on whether the width and height of the child CU after division satisfy the conditions of Example 5.

In some embodiments, division is not permitted if the width and height of the child CU after division satisfy the conditions of Example 5. In some embodiments, the signaling of the coding tree split may depend on whether one type of split is allowed. In one example, if one type of split is not allowed, the codeword representing the split is removed.

Example 11: Does the signaling of the skip flag and / and the Intra Block Copy (IBC) flag satisfy certain conditions (eg, the conditions described in Example 5) for the width and / or height of the block? You may depend on it.

In some embodiments, the condition is to include a sample with no more luma blocks than X. For example, X = 16.

In some embodiments, the condition is that the luma block contains X samples. For example, X = 16.

In some embodiments, the condition is that the width and height of the luma block are both equal to X. For example, X = 4.

In some embodiments, intermode and / or IBC mode are not allowed for such blocks if one or more of the above conditions are true.

In some embodiments, if intermode is not allowed for the block, the skip flag need not be notified about it. Alternatively, the skip flag can also be presumed to be false.

In some embodiments, if intermode and IBC modes are not allowed for the block, the skip flag need not be notified about it and can be implicitly derived as false (eg, the block is non-blocking). It is derived that it is coded in skip mode.)

In some embodiments, intermode is not allowed for a block, but if IBC mode is allowed for that block, the skip flag may still be notified. In some embodiments, the IBC flag need not be notified if the block is coded in skip mode, and the IBC flag is implicitly derived as true (eg, the block is in IBC mode). Coded with, and derived.).

Example 12: Predictive mode signaling may depend on whether the width and / or height of the block satisfies certain conditions (eg, the conditions described in Example 5).

In some embodiments, the condition is to include a sample with no more luma blocks than X. For example, X = 16.

In some embodiments, the condition is that the luma block contains X samples. For example, X = 16.

In some embodiments, the condition is that the width and height of the luma block are both equal to X. For example, X = 4.

In some embodiments, intermode and / or IBC mode are not allowed for such blocks if one or more of the above conditions are true.

In some embodiments, signaling of a particular mode of instruction may be skipped.

In some embodiments, if intermode and IBC mode are not allowed for the block, signaling of inter and IBC mode instructions is skipped and the remaining allowed modes (eg, it is intramode or palette mode). Whether or not) may still be notified.

In some embodiments, the predictive mode need not be notified if the intermode and IBC modes are not allowed for the block. Alternatively, further, the predictive mode can be implicitly derived as the intramode.

In some embodiments, if intermode is not allowed for the block, signaling of intermode instructions is skipped and the remaining allowed modes (eg, whether it is intramode or IBC mode). May still be notified. Alternative, remaining permitted modes (eg, whether it is intra mode or IBC mode or palette mode) may still be notified.

In some embodiments, if intermode is not allowed for a block, but IBC and intramodes are allowed for it, the IBC flag indicates whether the block is coded in IBC mode. You may be notified to indicate. Alternatively, the prediction mode may not be notified further.

Example 13: Triangular mode signaling may depend on whether the width and / or height of the block satisfies certain conditions (eg, the conditions described in FIG. 5).

In some embodiments, the condition is that the luma block size is one of several specific sizes. For example, a particular size may include 4x16 and / and 16x4.

In some embodiments, when the above conditions are true, triangular mode cannot be allowed, and a flag indicating whether the current block is coded in triangular mode need not be notified and is false. Can be derived if there is.

Example 14: Signaling in the inter-predictive direction may depend on whether the width and / or height of the block satisfies a particular condition (eg, the condition set forth in FIG. 5).

In some embodiments, the condition is that the luma block size is one of several specific sizes. For example, a particular size may include 8x4 and / and 4x8 or / and 4x16 and / and 16x4.

In some embodiments, if the above conditions are true, the block may simply be one-sided, not flagged as to whether the current block is bi-predicted, and falsely. Can be derived if there is.

Example 15: The signaling of the SMVD (symmetric MVD) flag may depend on whether the width and / or height of the block satisfies certain conditions (eg, the conditions described in Example 5).

In some embodiments, the condition is that the luma block size is one of several specific sizes. In some embodiments, the condition is defined as having a sample with a block size no greater than 32. In some embodiments, the condition is defined as whether the block size is 4x8 or 8x4. In some embodiments, the condition is defined as whether the block size is 4x4, 4x8 or 8x4. In some embodiments, the particular size may include 8x4 and / and 4x8 or / and 4x16 or / and 16x4.

In some embodiments, instructions for the use of SMVD (eg, the SMVD flag) need not be notified and can be derived as false if certain conditions are true. For example, the block may be set to be one-sided predicted.

In some embodiments, instructions for the use of SMVD (eg, the SMVD flag) may still be informed if certain conditions apply, but only the motion information in Listing 0 or Listing 1 is utilized in the motion compensation process. Can be done.

Example 16: A motion vector or block vector used for IBC (such as a motion vector derived in regular merge mode, ATMVP mode, MMVD merge mode, MMVD skip mode, etc.) is the width and / or height of the block. May be modified depending on whether certain conditions are met.

In some embodiments, the condition is that the luma block is one of several specific sizes. For example, a particular size may include 8x4 and / and 4x8 or / and 4x16 and / and 16x4.

In some embodiments, if the above conditions are true, the motion vector or block vector of the block is inherited from adjacent blocks with derived motion information bidirectionally (eg, with some offsets). ), Then it may be changed to a one-way motion vector. Such a process is called the transformation process, and the final unidirectional motion vector is referred to as the "transformed unidirectional" motion vector. In some embodiments, the motion information of the reference picture list X (eg, X is 0 or 1) may be retained and the motion information of the list Y (Y is 1-X) is discarded. It's okay. In some embodiments, the motion information of the reference picture list X (eg, X is 0 or 1) and that of the list Y (Y is 1-X) are jointly new to list X. It may be used to derive motion candidate points. In one example, the motion vector of the new motion candidate may be the averaged motion vector of the two reference picture lists. As another example, the motion information in list Y may first be scaled to list X. The motion vector of the new motion candidate may then be the averaged motion vector of the two reference picture lists. In some embodiments, the motion vector in predictive direction X may not be used (eg, the motion vector in predictive direction X is changed to (0,0) and the reference index in predictive direction X is). -1), the prediction direction may be changed to 1-X (X = 0 or 1). In some embodiments, the transformed unidirectional motion vector may be used to update the HMVP look-up table. In some embodiments, the derived bidirectional motion information, eg, the bidirectional MV before being converted into a one-way MV, may be used to update the HMVP look-up table. In some embodiments, the transformed unidirectional motion vector may be stored and then used for motion prediction, TMVP, deblocking, etc. of the coded block. In some embodiments, the derived bidirectional motion information, eg, the bidirectional MV before being converted to a one-way MV, may be retained and then the motion prediction, TMVP, deblocking of the coded block. May be used for such. In some embodiments, the transformed unidirectional motion vector may be used for motion refinement. In some embodiments, the derived bidirectional motion information may be used for motion refinement and / or sample refinement, eg, by optical flow method. In some embodiments, the predictive blocks generated according to the derived bidirectional motion information may be refined first, after which only one predictive block may be the final predictor of one block and / or. Alternatively, it may be used to derive a reconstructed block.

In some embodiments, the (bi-predicted) motion vector may be converted to a one-way motion vector before being used as a basic merge candidate in MMVD, where certain conditions apply.

In some embodiments, the (bi-predicted) motion vector is inserted into the merge list if certain conditions are met (eg, the dimensions of the block satisfy the conditions specified in Example 5 above). It may be converted to a one-way motion vector before it is done.

In some embodiments, the transformed unidirectional motion vector may be from reference list 0 only. In some embodiments, the transformed unidirectional motion vector may be from reference list 0 or list 1 if the current slice / tile group / picture is bi-predicted. In some embodiments, the converted unidirectional motion vector from reference list 0 and list 1 is a merge list or / and an MMVD-based merge candidate list when the current slice / tile group / picture is bi-predicted. May be interleaved.

In some embodiments, the method of converting motion information into a one-way motion vector may depend on the reference picture. In some embodiments, the motion information in Listing 1 may be utilized when all reference pictures in one video data unit (eg, tile / tile group) are past pictures in display order. In some embodiments, in display order, list 0 where at least one of the reference pictures of one video data unit (eg, tile / tile group) is a past picture and at least one is a future picture. Movement information may be used. In some embodiments, the method of converting motion information into a one-way motion vector may rely on the low delay check flag.

In some embodiments, the conversion process may be called immediately before the motion compensation process. In some embodiments, the conversion process may be called immediately after the motion candidate list (eg, merge list) configuration process. In some embodiments, the conversion process may be called before calling the additional MVD process in the MMVD process. That is, the additional MVD process follows the design of one-sided prediction rather than bi-prediction. In some embodiments, the conversion process may be called before calling the sample refinement process in the PROF process. That is, the sample refinement process follows the design of one-sided prediction rather than bi-prediction. In some embodiments, the conversion process may be called before calling the BIO (also known as BDOF) process. That is, in some cases, BIO may be invalidated because it has been converted to one-sided prediction. In some embodiments, the conversion process may be called before calling the DMVR process. That is, in some cases DMVR may be invalidated because it has been converted to one-sided prediction.

Example 17: In some embodiments, the method of generating the motion candidate list may depend on the block dimensions, for example, as described in Example 5 above.

In some embodiments, for specific block dimensions, spatial blocks and / or time blocks and / or motion candidates derived from HMVP and / or other types of motion candidates are restricted to one-sided prediction. good.

In some embodiments, it is a bi-prediction if one motion candidate derived from a spatial block and / or a time block and / or HMVP and / or other types of motion candidates for a particular block dimension is bipredictive. First, it may be transformed to be one-sided when added to the candidate list.

Example 18: Whether shared merge lists are allowed may depend on the encoding mode.

In some embodiments, the shared merge list does not have to be allowed for blocks coded by regular merge mode and may be allowed for blocks coded by ICB mode.

In some embodiments, if one block split from the parent shared node is coded by regular merge mode, the HMVP table update may be disabled after encoding / decoding the block.

Example 19: In the above disclosed example, the block size / width / height of the luma block can also be changed to the block size / width / height of the chroma block such as Cb, Cr, or G / B / R.

<Reduction of line buffer for GBi mode>
Example 20: Whether a GBi weighted index can be inherited or predicted (including CABC context selection) from an adjacent block depends on the position of the current block.

In some embodiments, the GBi weighted index cannot be inherited or predicted from adjacent blocks that are not in the same coding tree unit (CTU, also known as maximum coding unit LCU) as the current block.

In some embodiments, the GBi weighted index cannot be inherited or predicted from adjacent blocks that are not on the same CTU line or CTU row as the current block.

In some embodiments, the GBi weighted index cannot be inherited or predicted from adjacent blocks that are not in the same MxN region as the current block. For example, M = N = 64. In this case, the tile / slice / picture is divided into a plurality of non-overlapping M × N regions.

In some embodiments, the GBi weighted index cannot be inherited or predicted from adjacent blocks that are not in the same MxN region line or MxN region row as the current block. For example, M = N = 64. CTU lines / rows and region lines / rows are shown in FIG.

In some embodiments, the upper left corner (or other position) of the current block is (x, y) and the upper left corner (or other position) of the adjacent block is (x', y'). , It cannot be inherited or predicted from adjacent blocks if the following conditions are met:
(1) x / M! = X'/ M. For example, M = 128 or 64.
(2) y / N! = Y'/ N. For example, N = 128 or 64.
(3) ((x / M! = X'/ M) && (y / N! = Y'/ N)). For example, M = N = 128 or M = N = 64.
(4) ((x / M! = X'/ M) || (y / N! = Y'/ N)). For example, M = N = 128 or M = N = 64.
(5) x >> M! = X'>> M. For example, M = 7 or 6.
(6) y >> N! = Y'>> N. For example, N = 7 or 6.
(7) ((x >> M! = X'>> M) && (y >> N! = Y'>> N)). For example, M = N = 7 or M = N = 6.
(8) ((x >> M! = X'>> M) || (y >> N! = Y'>> N)). For example, M = N = 7 or M = N = 6.

In some embodiments, the flag is signaled in the PPS or slice header or tile group header or tile to indicate whether GBi is applicable in the picture / slice / tile group / tile. In some embodiments, whether CBi is used and how GBi is used (eg, some candidate weights and weight values) are derived for pictures / slices / tile groups / tiles. It's okay. In some embodiments, the derivation may depend on information such as QP, time layer, POC distance, and so on.

FIG. 10 shows an example of a CTU (region) line. The shared CTU (region) is in one CUT (region) line and the non-shared CTU (region) is in the other CUT (region) line.

<Simplification of inter-intra prediction (IIP)>
Example 21: Coding of the intra-prediction mode in an IIP-coded block is performed independently of the intra-prediction mode of the IIP-coded adjacent block.

In some embodiments, only the intra-prediction mode of the intra-coded block can be used, for example, in coding the intra-prediction mode of the IIP-coded block during the MPM list construction process.

In some embodiments, the intra prediction mode in the IIP coded block is coded without mode prediction from any adjacent block.

Example 22: The intra-prediction mode of an IIP-coded block is lower than that of an intra-coded block when they are both used to code the intra-prediction mode of a new IIP-coded block. It may have a priority.

In some embodiments, both IIP-coded and intra-coded block intra-prediction modes are utilized when deriving the MPM of an IIP-coded block. However, intra-prediction modes from intra-coded adjacent blocks may be inserted into the MPM prior to those from IIP-coded adjacent blocks.

In some embodiments, intra-prediction modes from intra-coded adjacent blocks may be inserted into the MPM after those from IIP-coded adjacent blocks.

Example 23: The intra-prediction mode in an IIP-coded block can also be used to predict that of an intra-coded block.

In some embodiments, the intra-prediction mode in the IIP-coded block can be used to derive the MPM for the normal intra-coded block. In some embodiments, the intra-prediction mode in an IIP-coded block is more than the intra-prediction mode in an intra-coded block when they are used to derive MPMs for a normal intra-coded block. May have a low priority.

In some embodiments, the intra-prediction mode for an IIP-coded block is a normal intra-coded block or an IIP-coded block intra-prediction mode only if one or more of the following conditions are met: Can also be used to predict:
1. Two blocks are on the same CTU line.
2. Two blocks are in the same CTU.
3. Two blocks are in the same M × N region (eg, M = N = 64).
4. Two blocks are on the same M × N region line (eg, M = N = 64).

Example 24: In some embodiments, the MPM configuration process for IIP-coded blocks should be the same as that for regular intra-coded blocks.

In the same embodiment, six MPMs are used for the intercoded blocks by inter-intra prediction.

In some embodiments, only part of the MPM is used for IIP-coded blocks. In some embodiments, the first one is always used. Alternatively, in addition, neither the MPM flag nor the MPM index needs to be notified. In some embodiments, the first four MPMs may be utilized. Alternatively, it is not necessary to further notify the MPM flag, but the MPM index needs to be notified.

In some embodiments, each block may select one from the MPM list according to the intra prediction mode contained in the MPM list, eg, the smallest index compared to a given mode (eg, planar). Select the mode you have.

In some embodiments, each block may select a subset of modes from the MPM list and notify the mode index within that subset.

In some embodiments, the context used to code the intra-MPM mode is reused to code the intra-mode in the IIP-coded block. In some embodiments, the different contexts used to code the intra-MPM mode are used to code the intra-mode in the IIP-coded block.

Example 25: In some embodiments, for angle intra-prediction modes other than horizontal and vertical, equal weights are utilized for intra-prediction blocks and inter-prediction blocks generated for IIP-coded blocks.

Example 26: In some embodiments, zero weights may be applied in the IIP coding process for specific locations.

In some embodiments, zero weights may be applied to the intra-predictive blocks used in the IIP coding process.

In some embodiments, zero weights may be applied to the interpredictive blocks used in the IIP coding process.

Example 27: In some embodiments, the intra-prediction mode of the IIP-coded block can only be selected as one of the MPMs, whatever the size of the current block.

In some embodiments, the MPM flag is not notified and is presumed to be 1 no matter what the size of the current block.

Example 28: For IIP-coded blocks, the Luma Prediction Chroma Mode (LM) mode is used instead of the Derived Mode (DM) mode to make intra-prediction for the chroma component.

In some embodiments, both DM and LM may be permitted.

In some embodiments, multiple intra-prediction modes may be allowed for the chroma component.

In some embodiments, whether multiple modes should be allowed for the chroma component may depend on the color format. In one example, for the 4: 4: 4 color format, the allowed chroma intra prediction mode may be the same as for the luma component.

Example 29: Inter-intra prediction cannot be allowed in one or more specific cases, such as:
A. w == T1 || h == T1, for example, T = 4.
B. w> T1 || h_T1, for example, T1 = 64.
C. (W == T1 && h == T2) || (w == T2 && h == T1), for example, T1 = 4, T2 = 16.

Example 30: Inter-intra prediction cannot be allowed for blocks that use bi-prediction.

In some embodiments, if the selected merge candidate for an IIP-coded block uses bi-prediction, it is converted to a single-predictive merge candidate. In some embodiments, only the predictions from reference list 0 are retained and the merge candidates are treated as one-sided predictions that refer to reference list 0. In some embodiments, only the predictions from reference list 1 are retained and the merge candidates are treated as one-sided predictions that refer to reference list 1.

In some embodiments, the restriction is that the selected merge candidate should be a one-sided predictive merge candidate. Alternatively, the notified merge index of the IIP-coded block indicates the index of one-predictive merge candidates (ie, bi-predictive merge candidates are not counted).

In some embodiments, the merge candidate list construction process used in the triangular prediction mode may be utilized to derive a motion candidate list for an IIP-coded block.

Example 31: Some coding tools may not be allowed when inter-intra prediction is applied.

In some embodiments, bi-directional optical flow (BIO) does not apply to bi-prediction.

In some embodiments, Overlapped Block Motion Compensation (OBMC) does not apply.

In some embodiments, the motion vector derivation / refinement process on the decoder side is not allowed.

Example 32: The intra-prediction process used in inter-intra-prediction may be different from that used in normal intra-coded blocks.

In some embodiments, adjacent samples may be filtered in various ways. In some embodiments, adjacent samples are not filtered prior to constructing the intra prediction used in the inter-intra prediction.

In some embodiments, the position-dependent intra-prediction sample filtering process is not configured for the intra-prediction used in inter-intra-prediction. In some embodiments, multi-line intra prediction is not allowed in inter-intra prediction. In some embodiments, wide-angle intra-prediction is not allowed in inter-intra-prediction.

Example 33: It is assumed that the intra and inter prediction values in the intra and inter composite prediction are Pintra and PInter, and the weighting factors are w_intra and w_inter, respectively. The predicted value at the position (x, y) is (Pintra (x, y) x w_intra (x, y) + Pinter (x, y) x w_inter (x, y) + offset (x, y)) >> N. It is calculated, and at this time, w_inter (x, y) + w_inter (x, y) = 2 ^N and offset (x, y) = 2 ^(N-1) . In one example, N = 3.

Example 34: In some embodiments, the MPM flags notified in the normal intracoded block and in the IIP coded block should share the same arithmetic coding context.

Example 35: In some embodiments, the MPM is not required to code the intra-prediction mode in the IIP-coded block (block width and height are assumed to be w and h).

In some embodiments, the four modes {planar, DC, vertical, horizontal} are binarized to 00, 01, 10 and 11 (00-planar, 01-DC, 10-vertical, 11-horizontal). Any mapping rule such as can be used).

In some embodiments, the four modes {planar, DC, vertical, horizontal} are binarized to 0, 10, 110 and 111 (0-planar, 10-DC, 110-vertical, 111-horizontal). Can be by any mapping rule such as).

In some embodiments, the four modes {planar, DC, vertical, horizontal} are binarized to 1,01,001 and 000 (1-planar, 01-DC, 001-vertical, 000-horizontal). Can be by any mapping rule such as).

In some embodiments, only three modes {planer, DC, vertical} can be used when W> N × H (N is an integer such as 2) can be used. The three modes are binarized to 1, 01 and 11 (can be according to any mapping rule such as 1-planar, 01-DC, 11-vertical).

In some embodiments, only three modes {planer, DC, vertical} can be used when W> N × H (N is an integer such as 2) can be used. The three modes are binarized to 0, 10 and 00 (can be according to any mapping rule such as 0-planar, 10-DC, 00-vertical).

In some embodiments, only three modes {planer, DC, horizontal} can be used when H> N × W (N is an integer such as 2) can be used. The three modes are binarized to 1, 01 and 11 (can be according to any mapping rule such as 1-planar, 01-DC, 11-horizontal).

In some embodiments, only three modes {planer, DC, horizontal} can be used when H> N × W (N is an integer such as 2) can be used. The three modes are binarized to 0, 10 and 00 (can be according to any mapping rule such as 0-planar, 10-DC, 00-horizontal).

Example 36: In some embodiments, only DC and planar modes are used in IP coded blocks. In some embodiments, one flag is signaled to indicate whether a DC or planar is used.

Example 37: In some embodiments, the IIP is configured differently for different color components.

In some embodiments, inter-intra prediction is not made for chroma components (eg, Cb and Cr).

In some embodiments, the intra-prediction mode of the chroma component is different from that of the luma component in the IIP-coded block. In some embodiments, DC mode is always used for chroma. In some embodiments, the planar mode is always used for chroma. In some embodiments, the LM mode is always used for chroma.

In some embodiments, how IIP should be performed for different color components may depend on the color format (eg 4: 2: 0 or 4: 4: 4).

In some embodiments, how IIP should be performed for different color components may depend on the block size. For example, inter-intra prediction is not made for chroma components (eg, Cb and Cr) when the width or height of the current block is 4 or less.

<MV prediction problem>
In the following discussion, the precision used for the MV saved for spatial motion prediction is represented as P1 and the precision used for the MV saved for temporal motion prediction is represented as P2.

Example 38: P1 and P2 may be the same, or they may be different.

In some embodiments, P1 is 1/16 luma pixels and P2 is 1/4 luma pixels. In some embodiments, P1 is 1/16 luma pixels and P2 is 1/8 luma pixels. In some embodiments, P1 is a 1/8 luma pixel and P2 is a 1/4 luma pixel. In some embodiments, P1 is a 1/8 luma pixel and P2 is a 1/8 luma pixel. In some embodiments, P2 is 1/16 luma pixels and P1 is 1/4 luma pixels. In some embodiments, P2 is 1/16 luma pixels and P1 is 1/8 luma pixels. In some embodiments, P2 is a 1/8 luma pixel and P1 is a 1/4 luma pixel.

Example 39: P1 and P2 do not have to be fixed. In some embodiments, P1 / P2 may be different for different standard profiles / levels / tiers. In some embodiments, P1 / P2 may be different for each picture in a different time layer. In some embodiments, P1 / P2 may be different for different width / height pictures. In some embodiments, P1 / P2 may be notified from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU.

Example 40: For MV (MVx, MVy), the accuracy of MVx and MVy may be different and are expressed as Px and Py.

In some embodiments, Px / Py may be different for different standard profiles / levels / tiers. Px / Py may be different for each picture in a different time layer. In some embodiments, Px may be different for each picture of different width. In some embodiments, Py may be different for each picture of different height. In some embodiments, Px / Py may be notified from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU.

Example 41: Before placing the MV (MVx, MVy) in storage for time motion prediction, it should be changed to accurate accuracy.

In some embodiments, MVx = Shift (MVx, P1-P2), MVy = Shift (MVy, P1-P2) when P1> = P2. In some embodiments, MVx = SignShift (MVx, P1-P2), MVy = SignShfit (MVy, P1-P2) when P1> = P2. In some embodiments, when P1 <P2, MVx = MVx << (P2-P1), MVy = MVy << (P2-P1).

Example 42: It is assumed that the accuracy of MV (MVx, MVy) is Px and Pz, and MVx or MVy is stored by an integer having N bits. The range of MV (MVx, MVy) is MinX <= MVx <= MaxX and MinY <= MVy <= MaxY.

In some embodiments, MinX may or may not be equal to MinY. In some embodiments, MaxX may be equal to MaxY, or it may not be equal to MaxY. In some embodiments, {MinX, MaxX} may depend on Px. In some embodiments, {MinY, MaxY} may depend on Py. In some embodiments, {MinX, MaxX, MinY, MaxY} may depend on N. In some embodiments, {MinX, MaxX, MinY, MaxY} may differ for MVs stored for spatial motion prediction and MVs stored for temporal motion prediction. In some embodiments, {MinX, MaxX, MinY, MaxY} may be different for different standard profiles / levels / tiers. In some embodiments, {MinX, MaxX, MinY, MaxY} may be different for each picture in a different time layer. In some embodiments, {MinX, MaxX, MinY, MaxY} may be different for different width / height pictures. In some embodiments, {MinX, MaxX, MinY, MaxY} may be notified from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU / CU. In some embodiments, {MinX, MaxX} may be different for different width pictures. In some embodiments, {MinY, MaxY} may be different for pictures of different heights. In some embodiments, the MVx is clipped to [MinX, MaxX] before being placed in storage for spatial motion prediction. In some embodiments, the MVx is clipped to [MinX, MaxX] before being placed in storage for time motion prediction. In some embodiments, the MVy is clipped to [MinY, MaxY] before being placed in storage for spatial motion prediction. In some embodiments, the MVy is clipped to [MinY, MaxY] before being placed in storage for time motion prediction.

<Reduction of line buffer for affine merge mode>
Example 43: The affine model (derived CPMV or affine parameter) inherited from the adjacent block by the affine merge candidate is always a 6-parameter affine model.

In some embodiments, the affine model is still inherited as the 6-parameter affine model when the adjacent blocks are coded by the 4-parameter affine model.

In some embodiments, whether a 4-parameter affine model from an adjacent block is inherited as a 6-parameter affine model or a 4-parameter affine model may depend on the position of the current block. In some embodiments, a 4-parameter affine model from an adjacent block is inherited as a 6-parameter affine model if the adjacent block is not in the same coding tree unit (CTU, also known as maximum coding unit LCU) as the current block. Is done. In some embodiments, the 4-parameter affine model from the adjacent block is taken over as the 6-parameter affine model if the adjacent block is not on the same CTU line or CTU row as the current block. In some embodiments, the 4-parameter affine model from the adjacent block is taken over as the 6-parameter affine model if the adjacent block is not in the same M × N region as the current block. For example, M = N = 64. In this case, the tile / slice / picture is divided into a plurality of non-overlapping M × N regions. In some embodiments, a 4-parameter affine model from an adjacent block is taken over as a 6-parameter affine model if the adjacent block is not on the same MxN region line or MxN region row as the current block. For example, M = N = 64. CTU lines / rows and region lines / rows are shown in FIG.

In some embodiments, the upper left corner (or other position) of the current block is (x, y) and the upper left corner (or other position) of the adjacent block is (x', y'). , The 4-parameter affine model from the adjacent block is inherited as the 6-parameter affine model if the adjacent block satisfies one or more of the following conditions:
(A) x / M! = X'/ M. For example, M = 128 or 64.
(B) y / N! = Y'/ N. For example, N = 128 or 64.
(C) ((x / M! = X'/ M) && (y / N! = Y'/ N)). For example, M = N = 128 or M = N = 64.
(D) ((x / M! = X'/ M) || (y / N! = Y'/ N)). For example, M = N = 128 or M = N = 64.
(E) x >> M! = X'>> M. For example, M = 7 or 6.
(F) y >> N! = Y'>> N. For example, N = 7 or 6.
(G) ((x >> M! = X'>> M) && (y >> N! = Y'>> N)). For example, M = N = 7 or M = N = 6.
(H) ((x >> M! = X'>> M) || (y >> N! = Y'>> N)). For example, M = N = 7 or M = N = 6.

[5. Embodiment]
The following description provides an example of how the disclosed techniques can be implemented within the syntax structure of current VVC standards. New additions are shown in bold (or underlined) and deletions are shown in italics.

<Embodiment # 1 (disables 4x4 inter-prediction and disables bi-prediction for 4x8, 8x4, 4x16 and 16x4 blocks)>

7.3.6.6 Coding unit syntax

7.4.7.6 Coding unit semantics Pred_mode_flag equal to 0 specifies that the current coding unit is coded in interpredicted mode. The equality of pred_mode_flag to 1 specifies that the current coding unit is coded in intra-predictive mode. The variables CuPredMode [x] [y] are derived as follows in the case of x = x0 ... x0 + cbWith-1 and y = y0 ... y0 + cbHeight-1:
-If pred_mode_flag is equal to 0, CuPredMode [x] [y] is set equally to MODE_INTER.
-If not (pred_mode_flag is equal to 1), CuPredMode [x] [y] is set equally to MODE_INTRA.

In the absence of pred_mode_flag, it is presumed to be equal to 1 when decoding an I tile group, or when decoding a coding unit where cbWith is equal to 4 and cbHeight is equal to 4, and the P or B tile group. Is estimated to be equal to 0 when decoding.

The equality of pred_mode_ibc_flag to 1 specifies that the current coding unit is coded in IBC prediction mode. The equality of pred_mode_ibc_flag to 0 specifies that the current coding unit is not coded in IBC prediction mode.

In the absence of pred_mode_ibc_flag, it is equal to the value of sps_ibc_enable_flag when decoding an I tile group, or when decoding a coding unit coded in skip mode, where cbWith is equal to 4 and cbHeight is equal to 4. Is presumed to be equal to 0 when decoding a P or B tile group.

When pred_mode_ibc_flag is equal to 1, the variables CuPredMode [x] [y] are set equally to MODE_IBC when x = x0 ... x0 + cbWids-1 and y = y0 ... y0 + cbHeight-1.

inter_pred_idc [x0] [y0] specifies whether List 0, List 1, or biprediction is used for the current coding unit according to Table 7-9. The array indexes x0, y0 specify the position (x0, y0) of the upper left luma sample of the coding block under consideration with respect to the upper left luma sample of the picture.

If inter_pred_idc [x0] [y0] does not exist, it is presumed to be equal to PRED_L0.

8.5.2.1 Overview The inputs to this process are:
-The luma position (xCb, yCb) of the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture,
-Variable cbWith, which specifies the width of the current coding block in the luma sample,
-Variable cbHeight that specifies the height of the current coding block in the luma sample
Is.

The output of this process is:
-Luma motion vector at 1/16 fraction sample accuracy mvL0 [0] [0] and mvL1 [0] [0],
-Reference indexes refIdxL0 and refIdxL1,
-Prediction list usage flags predFlagL0 [0] [0] and predFlagL1 [0] [0],
-Bi-predictive weight index gbiIdx
Is.

It is assumed that X is 0 or 1, and the variable LX is RefPicList [X] of the current picture.

For the derivation of the variables mvL0 [0] [0] and mvL1 [0] [0], refIdxL0 and refIdxL1, predFlagL0 [0] [0] and predFlagL1 [0] [0]:

-When merge_flag [xCb] [yCb] is equal to 1, the process of deriving the luma motion vector for the merge mode specified in Section 8.5.2.2 is the luma position (xCb, yCb), variable. Input of cbWidth and cbHeight, and luma motion vector mvL0 [0] [0], mvL1 [0] [0], reference index refIdxL0, refIdxL1, prediction list usage flag predFlagL0 [0] [0], predFlagL1 [0] [0] ], And the output that is the bipredictive weight index gbiIdx.

-If not, the following applies:

-In the variables predFlagLX [0] [0], mvLX [0] [0] and refIdxLX, in PRED_LX and in the syntax elements ref_idx_lX and mvdLX, if X is replaced by either 0 or 1, the following ordering: The applied steps apply:

1. 1. The variables refIdxLX and predFlagLX [0] [0] are derived as follows:
-When inter_pred_idc [xCb] [yCb] is equal to PRED_LX or PRED_BI,
refIdxLX = ref_idx_lX [xCb] [yCb] (8-266)
predFlagLX [0] [0] = 1 (8-267)
-Otherwise, the variables refIdxLX and predFlagLX [0] [0] are
refIdxLX = 1 (8-268)
predFlagLX [0] [0] = 0 (8-269)
Specified by.

2. 2. The variable mvdLX is derived as follows:
mvdLX [0] = MvdLX [xCb] [yCb] [0] (8-270)
mvdLX [1] = mvdLX [xCb] [yCb] [1] (8-271)

3. 3. When predFlagLX [0] [0] is equal to 1, the derivation process of the luma motion vector prediction in section 8.5.2.8 is the luma coding block position (xCb, yCb), the coding block width cbWids as an input. , Coding block height cbHeight, and variable refIdxLX, as well as output that is mvpLX.

4. When predFlagLX [0] [0] is equal to 1, the luma motion vector mvLX [0] [0] is derived as follows:
uLX [0] = (mvpLX [0] + mvdLX [0] +2 ¹⁸ )% 2 ₁₈ (8-272)
mvLX [0] [0] [0] = (uLX [0]> = 2 ¹⁷ )? (ULX [0] -218): ^uLX [0] (8-273)
uLX [1] = (mvpLX [1] + mvdLX [1] +2 ¹⁸ )% 2 ₁₈ (8-274)
mvLX [0] [0] [1] = (uLX [1]> = 2 ¹⁷ )? (ULX [1] -218): ^uLX [1] (8-275)

NOTE 1-The values obtained as a result of the above mvLX [0] [0] [0] and mvLX [0] [0] [1] are always in the range of ^{217 or more and 2 17 -1} or less.

-The bi-predictive weight index gbiIdx is set equally to gbi_idx [xCb] [yCb.

If all of the following conditions are true, refIdxL1 is set equal to -1, predFlagL1 is set equal to 0, and gbiIdx is set equal to 0:
-PredFlagL0 [0] [0] is equal to 1.
-PredFlagL1 [0] [0] is equal to 1.
- (CbWidth + cbHeight == 8) || (cbWith + cbHeight == 12) || (cbWith + cbHeight == 20)
(The conditions "cbWith is equal to 4" and "cbHeight is equal to 4" have been removed.)

The history-based motion vector predictor list update process specified in Section 8.5.2.16 includes the luma motion vectors mvL0 [0] [0] and mvL1 [0] [0], reference indexes refIdxL0 and refIdxL1. , The prediction list utilization flags predFlagL0 [0] [0] and predFlagL1 [0] [0], and the bipredictive weight index gbiIdx.

9.5.3.8 Binarization process for inter_pred_idc Inputs to this process are the request for binarization of the syntax element inter_pred_idc, the width of the current luma coding block cbWids and the height of the current luma coding block. It is cbHeight. The output of this process is the binarization of the syntax elements. The binarization of the syntax element inter_pred_idc is clearly described in Table 9-9.

9.5.4.2.1 Overview

<Embodiment # 2 (Invalidation of 4 × 4 inter-prediction)>

7.3.6.6 Coding unit syntax

7.4.7.6 Coding unit semantics Pred_mode_flag equal to 0 specifies that the current coding unit is coded in interpredicted mode. The equality of pred_mode_flag to 1 specifies that the current coding unit is coded in intra-predictive mode. The variables CuPredMode [x] [y] are derived as follows in the case of x = x0 ... x0 + cbWith-1 and y = y0 ... y0 + cbHeight-1:
-If pred_mode_flag is equal to 0, CuPredMode [x] [y] is set equally to MODE_INTER.
-If not (pred_mode_flag is equal to 1), CuPredMode [x] [y] is set equally to MODE_INTRA.

In the absence of pred_mode_flag, it is presumed to be equal to 1 when decoding an I tile group, or when decoding a coding unit where cbWith is equal to 4 and cbHeight is equal to 4, and the P or B tile group. Is estimated to be equal to 0 when decoding.

The equality of pred_mode_ibc_flag to 1 specifies that the current coding unit is coded in IBC prediction mode. The equality of pred_mode_ibc_flag to 0 specifies that the current coding unit is not coded in IBC prediction mode.

In the absence of pred_mode_ibc_flag, it is equal to the value of sps_ibc_enable_flag when decoding an I tile group, or when decoding a coding unit coded in skip mode, where cbWith is equal to 4 and cbHeight is equal to 4. Is presumed to be equal to 0 when decoding a P or B tile group.

When pred_mode_ibc_flag is equal to 1, the variables CuPredMode [x] [y] are set equally to MODE_IBC when x = x0 ... x0 + cbWids-1 and y = y0 ... y0 + cbHeight-1.

<Embodiment # 3 (Invalidation of dual prediction for 4x8, 8x4, 4x16 and 16x4 blocks)>

7.4.7.6 Coding unit semantics inter_pred_idc [x0] [y0] specifies whether List 0, List 1, or biprediction is used for the current coding unit according to Table 7-9. The array indexes x0, y0 specify the position (x0, y0) of the upper left luma sample of the coding block under consideration with respect to the upper left luma sample of the picture.

If inter_pred_idc [x0] [y0] does not exist, it is presumed to be equal to PRED_L0.

8.5.2.1 Overview The inputs to this process are:
-The luma position (xCb, yCb) of the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture,
-Variable cbWith, which specifies the width of the current coding block in the luma sample,
-Variable cbHeight that specifies the height of the current coding block in the luma sample
Is.

The output of this process is:
-Luma motion vector at 1/16 fraction sample accuracy mvL0 [0] [0] and mvL1 [0] [0],
-Reference indexes refIdxL0 and refIdxL1,
-Prediction list usage flags predFlagL0 [0] [0] and predFlagL1 [0] [0],
-Bi-predictive weight index gbiIdx
Is.

It is assumed that X is 0 or 1, and the variable LX is RefPicList [X] of the current picture.

For the derivation of the variables mvL0 [0] [0] and mvL1 [0] [0], refIdxL0 and refIdxL1, predFlagL0 [0] [0] and predFlagL1 [0] [0]:

-When merge_flag [xCb] [yCb] is equal to 1, the process of deriving the luma motion vector for the merge mode specified in Section 8.5.2.2 is the luma position (xCb, yCb), variable. Input of cbWidth and cbHeight, and luma motion vector mvL0 [0] [0], mvL1 [0] [0], reference index refIdxL0, refIdxL1, prediction list usage flag predFlagL0 [0] [0], predFlagL1 [0] [0] ], And the output that is the bipredictive weight index gbiIdx.

-If not, the following applies:

-In the variables predFlagLX [0] [0], mvLX [0] [0] and refIdxLX, in PRED_LX and in the syntax elements ref_idx_lX and mvdLX, if X is replaced by either 0 or 1, the following ordering: The applied steps apply:

5. The variables refIdxLX and predFlagLX [0] [0] are derived as follows:
-When inter_pred_idc [xCb] [yCb] is equal to PRED_LX or PRED_BI,
refIdxLX = ref_idx_lX [xCb] [yCb] (8-266)
predFlagLX [0] [0] = 1 (8-267)
-Otherwise, the variables refIdxLX and predFlagLX [0] [0] are
refIdxLX = 1 (8-268)
predFlagLX [0] [0] = 0 (8-269)
Specified by.

6. The variable mvdLX is derived as follows:
mvdLX [0] = MvdLX [xCb] [yCb] [0] (8-270)
mvdLX [1] = mvdLX [xCb] [yCb] [1] (8-271)

3. 3. When predFlagLX [0] [0] is equal to 1, the derivation process of the luma motion vector prediction in section 8.5.2.8 is the luma coding block position (xCb, yCb), the coding block width cbWids as an input. , Coding block height cbHeight, and variable refIdxLX, as well as output that is mvpLX.

8. When predFlagLX [0] [0] is equal to 1, the luma motion vector mvLX [0] [0] is derived as follows:
uLX [0] = (mvpLX [0] + mvdLX [0] +2 ¹⁸ )% 2 ₁₈ (8-272)
mvLX [0] [0] [0] = (uLX [0]> = 2 ¹⁷ )? (ULX [0] -218): ^uLX [0] (8-273)
uLX [1] = (mvpLX [1] + mvdLX [1] +2 ¹⁸ )% 2 ₁₈ (8-274)
mvLX [0] [0] [1] = (uLX [1]> = 2 ¹⁷ )? (ULX [1] -218): ^uLX [1] (8-275)

NOTE 1-The values obtained as a result of the above mvLX [0] [0] [0] and mvLX [0] [0] [1] are always in the range of ^{217 or more and 2 17 -1} or less.

-The bi-predictive weight index gbiIdx is set equally to gbi_idx [xCb] [yCb.

If all of the following conditions are true, refIdxL1 is set equal to -1, predFlagL1 is set equal to 0, and gbiIdx is set equal to 0:
-PredFlagL0 [0] [0] is equal to 1.
-PredFlagL1 [0] [0] is equal to 1.
- (CbWidth + cbHeight == 8) || (cbWith + cbHeight == 12) || (cbWith + cbHeight == 20)
(The conditions "cbWith is equal to 4" and "cbHeight is equal to 4" have been removed.)

The history-based motion vector predictor list update process specified in Section 8.5.2.16 includes the luma motion vectors mvL0 [0] [0] and mvL1 [0] [0], reference indexes refIdxL0 and refIdxL1. , The prediction list utilization flags predFlagL0 [0] [0] and predFlagL1 [0] [0], and the bipredictive weight index gbiIdx.

9.5.3.8 Binarization process for inter_pred_idc Inputs to this process are the request for binarization of the syntax element inter_pred_idc, the width of the current luma coding block cbWids and the height of the current luma coding block. It is cbHeight. The output of this process is the binarization of the syntax elements. The binarization of the syntax element inter_pred_idc is clearly described in Table 9-9.

9.5.4.2.1 Overview

<Embodiment # 4 (disables 4x4 inter-prediction and disables bi-prediction for 4x8 and 8x4 blocks)>

7.3.6.6 Coding unit syntax

7.4.7.6 Coding unit semantics Pred_mode_flag equal to 0 specifies that the current coding unit is coded in interpredicted mode. The equality of pred_mode_flag to 1 specifies that the current coding unit is coded in intra-predictive mode. The variables CuPredMode [x] [y] are derived as follows in the case of x = x0 ... x0 + cbWith-1 and y = y0 ... y0 + cbHeight-1:
-If pred_mode_flag is equal to 0, CuPredMode [x] [y] is set equally to MODE_INTER.
-If not (pred_mode_flag is equal to 1), CuPredMode [x] [y] is set equally to MODE_INTRA.

In the absence of pred_mode_flag, it is presumed to be equal to 1 when decoding an I tile group, or when decoding a coding unit where cbWith is equal to 4 and cbHeight is equal to 4, and the P or B tile group. Is estimated to be equal to 0 when decoding.

The equality of pred_mode_ibc_flag to 1 specifies that the current coding unit is coded in IBC prediction mode. The equality of pred_mode_ibc_flag to 0 specifies that the current coding unit is not coded in IBC prediction mode.

In the absence of pred_mode_ibc_flag, it is equal to the value of sps_ibc_enable_flag when decoding an I tile group, or when decoding a coding unit coded in skip mode, where cbWith is equal to 4 and cbHeight is equal to 4. Is presumed to be equal to 0 when decoding a P or B tile group.

When pred_mode_ibc_flag is equal to 1, the variables CuPredMode [x] [y] are set equally to MODE_IBC when x = x0 ... x0 + cbWids-1 and y = y0 ... y0 + cbHeight-1.

inter_pred_idc [x0] [y0] specifies whether List 0, List 1, or biprediction is used for the current coding unit according to Table 7-9. The array indexes x0, y0 specify the position (x0, y0) of the upper left luma sample of the coding block under consideration with respect to the upper left luma sample of the picture.

If inter_pred_idc [x0] [y0] does not exist, it is presumed to be equal to PRED_L0.

8.5.2.1 Overview The inputs to this process are:
-The luma position (xCb, yCb) of the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture,
-Variable cbWith, which specifies the width of the current coding block in the luma sample,
-Variable cbHeight that specifies the height of the current coding block in the luma sample
Is.

The output of this process is:
-Luma motion vector at 1/16 fraction sample accuracy mvL0 [0] [0] and mvL1 [0] [0],
-Reference indexes refIdxL0 and refIdxL1,
-Prediction list usage flags predFlagL0 [0] [0] and predFlagL1 [0] [0],
-Bi-predictive weight index gbiIdx
Is.

It is assumed that X is 0 or 1, and the variable LX is RefPicList [X] of the current picture.

For the derivation of the variables mvL0 [0] [0] and mvL1 [0] [0], refIdxL0 and refIdxL1, predFlagL0 [0] [0] and predFlagL1 [0] [0]:

-When merge_flag [xCb] [yCb] is equal to 1, the process of deriving the luma motion vector for the merge mode specified in Section 8.5.2.2 is the luma position (xCb, yCb), variable. Input of cbWidth and cbHeight, and luma motion vector mvL0 [0] [0], mvL1 [0] [0], reference index refIdxL0, refIdxL1, prediction list usage flag predFlagL0 [0] [0], predFlagL1 [0] [0] ], And the output that is the bipredictive weight index gbiIdx.

-If not, the following applies:

-In the variables predFlagLX [0] [0], mvLX [0] [0] and refIdxLX, in PRED_LX and in the syntax elements ref_idx_lX and mvdLX, if X is replaced by either 0 or 1, the following ordering: The applied steps apply:

1. 1. The variables refIdxLX and predFlagLX [0] [0] are derived as follows:
-When inter_pred_idc [xCb] [yCb] is equal to PRED_LX or PRED_BI,
refIdxLX = ref_idx_lX [xCb] [yCb] (8-266)
predFlagLX [0] [0] = 1 (8-267)
-Otherwise, the variables refIdxLX and predFlagLX [0] [0] are
refIdxLX = 1 (8-268)
predFlagLX [0] [0] = 0 (8-269)
Specified by.

2. 2. The variable mvdLX is derived as follows:
mvdLX [0] = MvdLX [xCb] [yCb] [0] (8-270)
mvdLX [1] = mvdLX [xCb] [yCb] [1] (8-271)

3. 3. When predFlagLX [0] [0] is equal to 1, the derivation process of the luma motion vector prediction in section 8.5.2.8 is the luma coding block position (xCb, yCb), the coding block width cbWids as an input. , Coding block height cbHeight, and variable refIdxLX, as well as output that is mvpLX.

4. When predFlagLX [0] [0] is equal to 1, the luma motion vector mvLX [0] [0] is derived as follows:
uLX [0] = (mvpLX [0] + mvdLX [0] +2 ¹⁸ )% 2 ₁₈ (8-272)
mvLX [0] [0] [0] = (uLX [0]> = 2 ¹⁷ )? (ULX [0] -218): ^uLX [0] (8-273)
uLX [1] = (mvpLX [1] + mvdLX [1] +2 ¹⁸ )% 2 ₁₈ (8-274)
mvLX [0] [0] [1] = (uLX [1]> = 2 ¹⁷ )? (ULX [1] -218): ^uLX [1] (8-275)

NOTE 1-The values obtained as a result of the above mvLX [0] [0] [0] and mvLX [0] [0] [1] are always in the range of ^{217 or more and 2 17 -1} or less.

-The bi-predictive weight index gbiIdx is set equally to gbi_idx [xCb] [yCb.

If all of the following conditions are true, refIdxL1 is set equal to -1, predFlagL1 is set equal to 0, and gbiIdx is set equal to 0:
-PredFlagL0 [0] [0] is equal to 1.
-PredFlagL1 [0] [0] is equal to 1.
- (CbWidth + cbHeight == 8) || (cbWith + cbHeight == 12)
(The conditions "cbWith is equal to 4" and "cbHeight is equal to 4" have been removed.)

The history-based motion vector predictor list update process specified in Section 8.5.2.16 includes the luma motion vectors mvL0 [0] [0] and mvL1 [0] [0], reference indexes refIdxL0 and refIdxL1. , The prediction list utilization flags predFlagL0 [0] [0] and predFlagL1 [0] [0], and the bipredictive weight index gbiIdx.

9.5.3.8 Binarization process for inter_pred_idc Inputs to this process are the request for binarization of the syntax element inter_pred_idc, the width of the current luma coding block cbWids and the height of the current luma coding block. It is cbHeight. The output of this process is the binarization of the syntax elements. The binarization of the syntax element inter_pred_idc is clearly described in Table 9-9.

9.5.4.2.1 Overview

<5.5 Embodiment # 5 (disables 4x4 inter-prediction, disables bi-prediction for 4x8, 8x4 blocks, and disables shared merge list for regular merge mode)>

7.3.6.6 Coding unit syntax

7.4.7.6 Coding unit semantics Pred_mode_flag equal to 0 specifies that the current coding unit is coded in interpredicted mode. The equality of pred_mode_flag to 1 specifies that the current coding unit is coded in intra-predictive mode. The variables CuPredMode [x] [y] are derived as follows in the case of x = x0 ... x0 + cbWith-1 and y = y0 ... y0 + cbHeight-1:
-If pred_mode_flag is equal to 0, CuPredMode [x] [y] is set equally to MODE_INTER.
-If not (pred_mode_flag is equal to 1), CuPredMode [x] [y] is set equally to MODE_INTRA.

In the absence of pred_mode_flag, it is presumed to be equal to 1 when decoding an I tile group, or when decoding a coding unit where cbWith is equal to 4 and cbHeight is equal to 4, and the P or B tile group. Is estimated to be equal to 0 when decoding.

The equality of pred_mode_ibc_flag to 1 specifies that the current coding unit is coded in IBC prediction mode. The equality of pred_mode_ibc_flag to 0 specifies that the current coding unit is not coded in IBC prediction mode.

In the absence of pred_mode_ibc_flag, it is equal to the value of sps_ibc_enable_flag when decoding an I tile group, or when decoding a coding unit coded in skip mode, where cbWith is equal to 4 and cbHeight is equal to 4. Is presumed to be equal to 0 when decoding a P or B tile group.

When pred_mode_ibc_flag is equal to 1, the variables CuPredMode [x] [y] are set equally to MODE_IBC when x = x0 ... x0 + cbWids-1 and y = y0 ... y0 + cbHeight-1.

inter_pred_idc [x0] [y0] specifies whether List 0, List 1, or biprediction is used for the current coding unit according to Table 7-9. The array indexes x0, y0 specify the position (x0, y0) of the upper left luma sample of the coding block under consideration with respect to the upper left luma sample of the picture.

If inter_pred_idc [x0] [y0] does not exist, it is presumed to be equal to PRED_L0.

8.5.2.1 Overview The inputs to this process are:
-The luma position (xCb, yCb) of the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture,
-Variable cbWith, which specifies the width of the current coding block in the luma sample,
-Variable cbHeight that specifies the height of the current coding block in the luma sample
Is.

The output of this process is:
-Luma motion vector at 1/16 fraction sample accuracy mvL0 [0] [0] and mvL1 [0] [0],
-Reference indexes refIdxL0 and refIdxL1,
-Prediction list usage flags predFlagL0 [0] [0] and predFlagL1 [0] [0],
-Bi-predictive weight index gbiIdx
Is.

It is assumed that X is 0 or 1, and the variable LX is RefPicList [X] of the current picture.

For the derivation of the variables mvL0 [0] [0] and mvL1 [0] [0], refIdxL0 and refIdxL1, predFlagL0 [0] [0] and predFlagL1 [0] [0]:

-When merge_flag [xCb] [yCb] is equal to 1, the process of deriving the luma motion vector for the merge mode specified in Section 8.5.2.2 is the luma position (xCb, yCb), variable. Input of cbWidth and cbHeight, and luma motion vector mvL0 [0] [0], mvL1 [0] [0], reference index refIdxL0, refIdxL1, prediction list usage flag predFlagL0 [0] [0], predFlagL1 [0] [0] ], And the output that is the bipredictive weight index gbiIdx.

-If not, the following applies:

-In the variables predFlagLX [0] [0], mvLX [0] [0] and refIdxLX, in PRED_LX and in the syntax elements ref_idx_lX and mvdLX, if X is replaced by either 0 or 1, the following ordering: The applied steps apply:

5. The variables refIdxLX and predFlagLX [0] [0] are derived as follows:
-When inter_pred_idc [xCb] [yCb] is equal to PRED_LX or PRED_BI,
refIdxLX = ref_idx_lX [xCb] [yCb] (8-266)
predFlagLX [0] [0] = 1 (8-267)
-Otherwise, the variables refIdxLX and predFlagLX [0] [0] are
refIdxLX = 1 (8-268)
predFlagLX [0] [0] = 0 (8-269)
Specified by.

6. The variable mvdLX is derived as follows:
mvdLX [0] = MvdLX [xCb] [yCb] [0] (8-270)
mvdLX [1] = mvdLX [xCb] [yCb] [1] (8-271)

7. When predFlagLX [0] [0] is equal to 1, the derivation process of the luma motion vector prediction in section 8.5.2.8 is the luma coding block position (xCb, yCb), the coding block width cbWids as an input. , Coding block height cbHeight, and variable refIdxLX, as well as output that is mvpLX.

8. When predFlagLX [0] [0] is equal to 1, the luma motion vector mvLX [0] [0] is derived as follows:
uLX [0] = (mvpLX [0] + mvdLX [0] +2 ¹⁸ )% 2 ₁₈ (8-272)
mvLX [0] [0] [0] = (uLX [0]> = 2 ¹⁷ )? (ULX [0] -218): ^uLX [0] (8-273)
uLX [1] = (mvpLX [1] + mvdLX [1] +2 ¹⁸ )% 2 ₁₈ (8-274)
mvLX [0] [0] [1] = (uLX [1]> = 2 ¹⁷ )? (ULX [1] -218): ^uLX [1] (8-275)

NOTE 1-The values obtained as a result of the above mvLX [0] [0] [0] and mvLX [0] [0] [1] are always in the range of ^{217 or more and 2 17 -1} or less.

-The bi-predictive weight index gbiIdx is set equally to gbi_idx [xCb] [yCb.

If all of the following conditions are true, refIdxL1 is set equal to -1, predFlagL1 is set equal to 0, and gbiIdx is set equal to 0:
-PredFlagL0 [0] [0] is equal to 1.
-PredFlagL1 [0] [0] is equal to 1.
- (CbWidth + cbHeight == 8) || (cbWith + cbHeight == 12)
(The conditions "cbWith is equal to 4" and "cbHeight is equal to 4" have been removed.)

The history-based motion vector predictor list update process specified in Section 8.5.2.16 includes the luma motion vectors mvL0 [0] [0] and mvL1 [0] [0], reference indexes refIdxL0 and refIdxL1. , The prediction list utilization flags predFlagL0 [0] [0] and predFlagL1 [0] [0], and the bipredictive weight index gbiIdx.

8.5.2.2 Ruma motion vector derivation process for merge mode This process is only called if merge_flag [xCb] [yCb] is equal to 1. (XCb, yCb) identifies the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture.

The input to this process is:
-The luma position (xCb, yCb) of the upper left sample of the current luma coding block with respect to the upper left luma sample of the current picture,
-Variable cbWith, which specifies the width of the current coding block in the luma sample,
-Variable cbHeight that specifies the height of the current coding block in the luma sample
Is.

The output of this process is:
-Luma motion vector at 1/16 fraction sample accuracy mvL0 [0] [0] and mvL1 [0] [0],
-Reference indexes refIdxL0 and refIdxL1,
-Prediction list usage flags predFlagL0 [0] [0] and predFlagL1 [0] [0],
-Bi-predictive weight index gbiIdx
Is.

The bipredictive weight index gbiIdx is set equal to 0.

The variables xSmr, ySmr, smrWith, smrHeight, and emrNumHmbpCand are derived as follows:

8.5.2.6 History-based process for deriving merge candidates The input to this process is:
-Merge Candidate List mergeCandList,
-Variable isInSmr, which indicates whether the current coding unit is in the shared merge candidate area.
-Number of available merge candidates in the list numberCurrMergeCand
Is.

The output of this process is:
-Changed merge candidate list mergeCandList,
-Number of merge candidates in the list after change numCurrMergeCand
Is.

The variables isPrunedA ₁ and isPrunedB ₁ are both set equally to FALSE.

The array smrHmvpCandList and the variable smrNumHmvpCand are derived as follows:

For each candidate in the smrHmvpCandList [hMvpIdx] with the index hMVpIdx = 1 ... smrNumHmvpCand, the following ordered steps are repeated until the numCurrMergeCand becomes equal to (MaxNumMergeCand-1):

1. 1. The variable sameMotion is derived as follows:
• For any merge candidate N where N is A ₁ or B ₁ , both sameMotion and isPrunedN are set equally to TRUE if all of the following conditions are true:
-HMvpIdx is 2 or less.
-Candidate smrHmvpCandList [smrNumHmvpCand-hMvpIdx] is equal to merge candidate N.
-IsPrunedN is equal to FALSE.
If not, the sameMotion is set equally to FALSE.

2. 2. If the sameMotion is equal to FALSE, the candidate smrHmvpCandList [smrNumHmbpCand-hMvpIdx] is added to the merge candidate list as follows:
mergeCandList [numCurrMergeCand++] =
smrHmbpCandList [smrNumHmvpCand-hMbpIdx] (8-355)

9.5.3.8 Binarization process for inter_pred_idc Inputs to this process are the request for binarization of the syntax element inter_pred_idc, the width of the current luma coding block cbWids and the height of the current luma coding block. It is cbHeight. The output of this process is the binarization of the syntax elements. The binarization of the syntax element inter_pred_idc is clearly described in Table 9-9.

9.5.4.2.1 Overview

FIG. 11 is a block diagram of the video processing device 1100. Device 1100 may be used to implement one or more of the methods described herein. The device 1100 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and the like. The device 1100 may include one or more processors 1102, one or more memories 1104, and video processing hardware 1106. Processor 1102 may be configured to implement one or more of the methods described herein. Memory 1104 may be used to store data and codes used to implement the methods and techniques described herein. Video processing hardware 1106 may be used in hardware circuits to implement some of the techniques described herein.

FIG. 12 is a flowchart of an exemplary method 1200 for video processing. Method 1200 uses the step (1202) of determining a size limit between the representative motion vector of the current video block to be fin-coded and the motion vector of the subblocks of the current video block, and the size limit. Includes a step (1204) of performing a conversion between the pixel value of the current video block or subblock and the bitstream representation.

As used herein, 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 of a video from a pixel representation to a corresponding bitstream representation, and vice versa. The bitstream representation of the current video block may correspond to bits that are spread or co-located in different locations within the bitstream, for example, as defined by syntax. For example, the macroblock may also be encoded with the bits in the header and other fields in the bitstream with respect to the transformed and coded error residues.

As is clear, the disclosed techniques are useful for implementing embodiments in which the implementation complexity of video processing is reduced by reducing memory or line buffer size requirements. Some of the techniques currently disclosed may be described using the following bullet points.

1. 1. It ’s a video processing method.
A step of determining a size limit between the representative motion vector of the current video block to be affine-coded and the motion vector of the subblock of the current video block.
A method having a step of performing a conversion between a bitstream representation and pixel values of the current video block or subblock by using the size limit.

2. 2. The step of performing the transformation comprises generating the bitstream representation from the pixel values.
The method described in Clause 1.

3. 3. The step of performing the transformation comprises generating the pixel value from the bitstream representation.
The method described in Clause 1.

4. The size limit sets the value of the motion vector (MVx, MVy) of the subblock according to MVx> = MV'x-DH0 and MVx <= MV'x + DH1 and MVy> = MV'y-DV0 and MVy <= MV'y + DV1. MV'= (MV'x, MV'y), including constraints,
MV'represents the representative motion vector, and DH0, DH1, DV0 and DV1 represent positive numbers.
The method according to any one of Clauses 1 to 3.

5. The size limit is as follows:
i. DH0 equals DH1 or DV0 equals DV1
ii. DH0 equals DV0 or DH1 equals DV1
iii. DH0 and DH1 are different, or DV0 and DV1 are different,
iv. DH0, DH1, DV0 and DV1 are bits at the video parameter set level or sequence parameter set level or picture parameter set level or slice header level or tile group header level or tile level or coding tree unit level or coding unit level or prediction unit level. Notified in stream representation,
v. DH0, DH1, DV0 and DV1 are functions of the mode of video processing.
vi. DH0, DH1, DV0 and DV1 depend on the width and height of the current video block.
vii. DH0, DH1, DV0 and DV1 depend on whether the current video block is coded using single or bi-prediction.
viii. DH0, DH1, DV0 and DV1 depend on the position of the subblock.
Including at least one of
The method described in Clause 4.

6. The representative motion vector corresponds to the control point motion vector of the current video block.
The method according to any one of Clauses 1 to 5.

7. The representative motion vector corresponds to the motion vector of the corner subblock of the current video block.
The method according to any one of Clauses 1 to 5.

8. The accuracy used for the motion vector of the subblock and the representative motion vector corresponds to the motion vector signaling accuracy in the bitstream representation.
The method according to any one of Clauses 1 to 7.

9. The precision used for the motion vector of the subblock and the representative motion vector corresponds to the storage precision for storing the motion vector.
The method according to any one of Clauses 1 to 7.

10. It ’s a video processing method.
For the current video block to be affine-coded, it is a step to determine one or more subblocks of the current video block, where each subblock is M × N, assuming that M and N are multiples of 2 or 4. With the above-mentioned determination step having a pixel size,
The step of adjusting the motion vector of the subblock to the size limit,
A method having a step of performing a conversion between a bitstream representation of the current video block and a pixel value, conditionally based on a trigger, by using the size limit.

11. The step of performing the transformation comprises generating the bitstream representation from the pixel values.
The method according to Clause 10.

12. The step of performing the transformation comprises generating the pixel value from the bitstream representation.
The method according to Clause 10.

13. The size limit limits the maximum difference between the integer parts of the subblock motion vector of the current video block to be K pixels or less, where K is an integer.
The method according to any one of Clauses 10 to 12.

14. The method applies only if the current video block is coded using bi-prediction.
The method according to any one of clauses 10 to 13.

15. The method applies only if the current video block is coded using one-sided prediction.
The method according to any one of clauses 10 to 13.

16. The value of M, N, or K is a function of the single-predictive or bi-predictive mode of the current video block.
The method according to any one of clauses 10 to 13.

17. The value of M, N, or K is a function of the height or width of the current video block.
The method according to any one of clauses 10 to 13.

18. The trigger is included in the bitstream representation at the video parameter set level or sequence parameter set level or picture parameter set level or slice header level or tile group header level or tile level or coding tree unit level or coding unit level or prediction unit level. ,
The method according to any one of clauses 10 to 17.

19. The trigger conveys a value of M, N, or K.
The method according to Clause 18.

20. The one or more subblocks of the current video block are calculated based on the type of affine coding used for the current video block.
The method according to any one of Clauses 10 to 19.

21. Two different methods are used to calculate subblocks of one-sided and two-sided affine prediction modes.
The method described in Clause 20.

22. If the current video block is a bipredicted affine block, the width or height of the subblocks from different reference lists will be different.
The method according to Clause 21.

23. The one or more subblocks correspond to the luma component.
The method according to any one of Clauses 20 to 22.

24. The width and height of one of the one or more subblocks uses the motion vector difference between the motion vector value of the current video block and that one of the one or more subblocks. Will be decided,
The method according to any one of clauses 10 to 23.

25. The calculated step is based on the pixel accuracy conveyed in the bitstream representation.
The method according to any one of clauses 20 to 23.

26. It ’s a video processing method.
Steps to determine that the current video block meets the size requirement,
A method having a step of performing a conversion between a bitstream representation of the current video block and a pixel value by excluding the bi-predictive encoding mode for the current video block based on the determination.

27. It ’s a video processing method.
Steps to determine that the current video block meets the size requirement,
Based on the determination, it has a step of performing a conversion between the bitstream representation of the current video block and the pixel values.
The inter-prediction mode is transmitted in the bitstream representation according to the size condition.
Method.

28. It ’s a video processing method.
Steps to determine that the current video block meets the size requirement,
Based on the determination, it has the steps of performing a conversion between the bitstream representation of the current video block and the pixel values.
The generation of the merge candidate list during the conversion depends on the size condition.
Method.

29. It ’s a video processing method.
Steps to determine that the child coding unit of the current video block meets the size requirement,
Based on the determination, it has a step of performing a conversion between the bitstream representation of the current video block and the pixel values.
The coding tree partitioning process used to generate the child coding unit depends on the size condition.
Method.

30. Assuming w is the width and h is the height, the size condition is as follows: (a) w is equal to T1 and h is equal to T2, or h is equal to T1 and w is equal to T2.
(B) w is equal to T1 and h is not greater than T2, or h is equal to T1 and w is not greater than T2.
(C) w is not greater than T1 and h is not greater than T2, or h is not greater than T1 and w is not greater than T2.
One of them,
The method according to any one of Clauses 26 to 29.

31. T1 = 8 and T2 = 8, or T1 = 8 and T2 = 4, or T1 = 4 and T2 = 4, or T1 = 4 and T2 = 16.
The method according to Clause 30.

32. The conversion comprises generating the bitstream representation from the pixel values of the current video block, or generating the pixel values of the current video block from the bitstream representation.
The method according to any one of Clauses 26 to 29.

33. It ’s a video processing method.
With the step of determining the weight index of the generalized bi-prediction (GBi) process for the current video block based on the position of the current video block,
A method having a step of performing a conversion between the current video block and its bitstream representation using the weight index to implement the GBi process.

34. The conversion comprises generating the bitstream representation from the pixel values of the current video block, or generating the pixel values of the current video block from the bitstream representation.
The method according to Clause 33.

35. The determining step is to inherit or predict other weight indexes of adjacent blocks for the current video block in the first position, and for the current video block in the second position, said adjacent. Including calculating the GBi without inheriting from the block,
The method according to any of clauses 33 or 34.

36. The second location has the current video block located in a different coding tree unit than the adjacent block.
The method according to Clause 35.

37. The second position corresponds to the current video block being on a different coding tree unit line or different coding tree unit line than the adjacent block.
The method according to Clause 35.

38. It ’s a video processing method.
Steps to determine that the current video block is coded as an intra-interpredictive (IIP) coding block,
A method comprising performing a conversion between the current video block and its bitstream representation using a simplification rule that determines the intra-predictive mode or most probable mode (MPM) of the current video block.

39. The conversion comprises generating the bitstream representation from the pixel values of the current video block, or generating the pixel values of the current video block from the bitstream representation.
The method according to Clause 38.

40. The simplification rules stipulate that the intra-predictive coding mode of the current video block to be intra-inter-predictive (IIP) coded to be independent of the other intra-predictive coding modes of the adjacent video block.
The method according to any one of clauses 38 to 39.

41. The intra-predictive coding mode is represented in the bitstream representation using coding independent of that of the adjacent block.
The method according to any one of clauses 38 to 39.

42. The simplification rule provides that the choice of favoring the coding mode of an intra-coded block takes precedence over that of an intra-predictive-coded block.
The method according to any one of clauses 38 to 40.

43. The simplification rule provides that the MPM is determined by inserting an intra-predictive mode from an intra-coded adjacent block before inserting an intra-predictive mode from an IIP-coded adjacent block.
The method according to Clause 38.

44. The simplification rule stipulates that the same configuration process used for other normal intracoded blocks is used to determine the MPM.
The method according to Clause 38.

45. It ’s a video processing method.
The steps that determine that the current video block meets the simplification criteria,
The conversion between the current video block and the bitstream representation either by disabling the use of the inter-intra prediction mode for the conversion, or by disabling the additional coding tools used for the conversion. A method that has steps to perform by.

46. The conversion comprises generating the bitstream representation from the pixel values of the current video block, or generating the pixel values of the current video block from the bitstream representation.
The method according to Clause 45.

47. The simplification criteria include that the width or height of the current video block is equal to T1 assuming that T1 is an integer.
The method according to any one of clauses 45 to 46.

48. The simplification criteria include that the width or height of the current video block is greater than T1 assuming that T1 is an integer.
The method according to any one of clauses 45 to 46.

49. The simplification criteria include that the width or height width of the current video block is equal to T1 and the height of the current video block is equal to T2.
The method according to any one of clauses 45 to 46.

50. The simplification criteria stipulate that the current video block uses bipredictive mode.
The method according to any one of clauses 45 to 46.

51. The additional coding tools include bidirectional optical flow (BIO) coding.
The method according to any one of clauses 45 to 46.

52. The additional coding tools include an overlap block motion compensation mode.
The method according to any one of clauses 45 to 46.

53. It ’s a video processing method.
It has steps to perform a conversion between the current video block and the bitstream representation of the current video block using a motion vector based encoding process.
(A) Precision P1 is used to store spatial motion prediction results, precision P2 is used to store time motion prediction results during the conversion process, and P1 and P2 are fractions or
(B) Precision Px is used to store the x motion vector, precision Py is used to store the y motion vector, and Px and Py are fractions.
Method.

54. P1, P2, Px and Py are different numbers,
The method according to Clause 53.

55. P1 is 1/16 Luma pixel and P2 is 1/4 Luma pixel, or
P1 is 1/16 Luma pixel and P2 is 1/8 Luma pixel, or
P1 is 1/8 Luma pixel and P2 is 1/4 Luma pixel, or
P1 is 1/8 Luma pixel and P2 is 1/8 Luma pixel, or
P2 is 1/16 Luma pixel and P1 is 1/4 Luma pixel, or
P2 is 1/16 Luma pixel and P1 is 1/8 Luma pixel, or
P2 is a 1/8 luma pixel and P1 is a 1/4 luma pixel.
The method according to Clause 54.

56. P1 and P2 are different for different pictures in different time layers contained in the bitstream representation.
The method according to clauses 53 to 54.

57. The calculated motion vector is processed through an accuracy correction process prior to storage as the time motion prediction.
The method according to clauses 53 to 54.

58. The preservation includes storing the x motion vector and the y motion vector as N-bit integers, the range of values of the x motion vector is [MinX, Max], and the range of values of the y motion vector is. [MinY, MaxY], and their range is
a. minX equals MinY,
b. MaxX equals MaxY,
c. {MinX, MaxX} depends on Px,
d. {MinY, MaxY} depends on Py,
e. {MinX, MaxX, MinY, MaxY} depends on N,
f. {MinX, MaxX, MinY, MaxY} is different for the saved MV for spatial motion prediction and the other MVs saved for temporal motion prediction.
g. {MinX, MaxX, MinY, MaxY} is different for each picture in a different time layer,
h. {MinX, MaxX, MinY, MaxY} is different for each picture with a different width or height.
i. {MinX, MaxX} is different for each picture with a different width,
j. {MinY, MaxY} is different for each picture with different heights,
k. MVx is clipped to [MinX, MaxX] before saving for spatial motion prediction.
l. MVx is clipped to [MinX, MaxX] before saving for time motion prediction.
m. MVy is clipped to [MinY, MaxY] before saving for spatial motion prediction.
n. MVy is clipped to [MinY, MaxY] before saving for time motion prediction.
Satisfy one or more of
The method according to clauses 53 to 54.

59. It ’s a video processing method.
Assuming that W1, W2, H1, H2, and PW and PH are integers, (W2 + N-1-PW) × (H2 + N-1-PH) blocks are fetched, the fetched blocks are pixel padded, and the pixels. The small subblock of W1 × H1 size within the large W2 × H2 size subblock of the current video block by performing a boundary pixel iteration on the padded block and getting the pixel value of the small subblock. Steps to interpolate and
A method comprising the steps of performing a conversion between the current video block and a bitstream representation of the current video block using the interpolated pixel values of the smaller subblock.

60. The conversion comprises generating the current video block from the bitstream representation, or generating the bitstream representation from the current subblock.
The method according to Clause 59.

61. W2 = H2 = 8, W1 = H1 = 4 and PW = PH = 0.
The method according to any one of clauses 59 to 60.

62. It ’s a video processing method.
During conversion of the current video block of W × H dimension and the bitstream representation of the current video block, (W + N-1-PW) × (H + N-1-PH) reference pixels are fetched and motion compensation operation is performed. A step of performing the motion compensation operation by padding a reference pixel larger than the fetched reference pixel in the process.
It has a step of performing a conversion between the current video block and a bitstream representation of the current video block using the result of the motion compensation operation.
W, H, N, PW and PH are integers,
Method.

63. The conversion comprises generating the current video block from the bitstream representation, or generating the bitstream representation from the current subblock.
The method according to Clause 62.

64. The padding involves repeating the left or right boundary of the fetched pixel.
The method according to any one of clauses 62 to 63.

65. The padding involves repeating the top or bottom boundaries of the fetched pixel.
The method according to any one of clauses 62 to 63.

66. The padding involves setting a pixel value to a constant.
The method according to any one of clauses 62 to 63.

67. The rule stipulates that the same arithmetic coding context used for other intracoded blocks will be used during the transformation.
The method according to Clause 38.

68. The conversion of the current video block excludes the use of the MPM of the current video block.
The method according to Clause 38.

69. The simplification rules stipulate that only DC and planar modes be used for the bitstream representation of the current video block, which is the IIP-coded block.
The method according to Clause 38.

70. The simplification rules define different intra-prediction modes for the luma and chroma components.
The method according to Clause 38.

71. A subset of the MPM is used for the current video block that is IIP coded.
The method according to Clause 44.

72. The simplification rule indicates that the MPM is selected based on the intra prediction mode included in the MPM list.
The method according to Clause 38.

73. The simplification rule indicates that a subset of MPMs should be selected from the MPM list and that it informs the mode index associated with the subset.
The method according to Clause 38.

74. The context used to code the intra MPM mode is used to code the intra mode of the current video block that is IIP coded.
The method according to Clause 38.

75. Equal weights are used for the intra-predictive and inter-predictive blocks generated for the current video block, which is the IIP-coded block.
The method according to Clause 44.

76. The zero weight is used for the position in the IIP coding process for the current video block,
The method according to Clause 44.

77. The zero weight applies to the intra-prediction block used in the IIP coding process.
The method described in Clause 76.

78. The zero weight applies to the interpredictive blocks used in the IIP coding process.
The method described in Clause 76.

79. It ’s a video processing method.
A step that determines that bi-original or one-sided prediction of the current video block is not allowed based on the size of the current video block.
A method having a step of performing a conversion between a bitstream representation of the current video block and a pixel value by disabling the bi-prediction or one-sided prediction mode based on the determination. For example, disallowed modes are not used to encode or decode the current video block. The conversion operation may represent either video coding or compression, or video decoding or decompression.

80. The current video block is 4x8 and the determining step comprises determining that bi-prediction is not allowed.
The method described in Clause 79. Another example is given in Example 5.

81. The current video block is 4x8 or 8x4, and the determining step comprises determining that bi-prediction is not allowed.
The method described in Clause 79.

82. The current video block is 4 × N, where N is an integer less than or equal to 16, and the determination step comprises determining that bi-prediction is not allowed.
The method described in Clause 79.

83. The size of the current video block corresponds to the size of the color component or luma component of the current video block.
The method according to any one of Clauses 26 to 29 or 79 to 82.

84. Disabling the bi-prediction or prediction mode applies to all three components of the current video block.
The method described in Clause 83.

85. Disabling the bi-prediction or prediction mode applies only to the color components whose size is used as the size of the current video block.
The method described in Clause 83.

86. The transformation is performed by disabling the use of bi-predicted and even bi-predicted merge candidates, and then assigning only one motion vector from a single reference list to the current video block. Be done,
The method according to any one of clauses 79 to 85.

87. The current video block is 4x4 and the determining step comprises determining that both bi-prediction and one-sided prediction are not allowed.
The method described in Clause 79.

88. The current video block is coded as an intrablock,
The method according to Clause 87.

89. The current video block is limited to using integer pixel motion vectors,
The method according to Clause 87.

Further examples and embodiments of clauses 78-89 are described in Example 5.

90. It ’s a video processing method.
Steps to determine the video coding conditions for the video block based on the size of the current video block,
A method comprising a step of performing a conversion between the current video block and a bitstream representation of the current video block based on the video coding condition.

91. The video coding condition defines the selective signaling of the skip flag or the intrablock coding flag in the bitstream representation.
The method according to Clause 90.

92. The video coding condition determines the selective signaling of the predictive mode for the current video block.
The method according to clause 90 or 91.

93. The video coding condition determines the selective signaling of the triangular mode coding of the current video block.
The method according to any one of clauses 90 to 92.

94. The video coding condition defines selective signaling in the interpredictive direction for the current video block.
The method according to any one of clauses 90 to 93.

95. The video coding condition stipulates that the motion vector or block vector used for the intra-block copy of the current video block is selectively modified.
The method according to any one of clauses 90 to 94.

96. The video coding condition depends on the height of the current video block in pixels.
The method according to any one of clauses 90 to 95.

97. The video coding condition depends on the width of the current video block in pixels.
The method according to any one of clauses 90 to 96.

98. The video coding condition depends on whether the current video block has a square shape.
The method according to any one of clauses 90 to 95.

Further examples of Clauses 90-98 are provided in Examples 11-16 cited in "4. Examples of Embodiments" herein.

99. A video encoder device having a processor configured to perform the method according to one or more of clauses 1-98.

100. A video decoder device having a processor configured to perform the method according to one or more of clauses 1-98.

101. A computer-readable medium that stores code that, when executed by a processor, causes the processor to perform the method described in any one or more of clauses 1-98.

FIG. 16 is a block diagram illustrating an exemplary video processing system 1600 in which the various techniques disclosed herein can be implemented. Various implementations may include some or all of the components of system 1600. The system 1600 may include an input unit 1602 for receiving video content. Video content may be received in raw or uncompressed format, eg, 8 or 10 bit multi-component pixel values, or may be in compressed or encoded format. .. The input unit 1602 may correspond to a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

The system 1600 may include a coding component 1604 that may implement the various coding or encoding methods described herein. The coding component 1604 may reduce the average bit rate of the video from the input section 1602 to the output section of the coding component 1604 so as to generate a coded representation of the video. Therefore, coding techniques are sometimes referred to as video compression or video transcoding techniques. The output of coding component 1604 may be stored or transmitted via connected communication, as represented by component 1606. The stored or communicated bitstream (or coded) representation of the video received at input 1602 may be used by component 1608 to generate a displayable video sent to the pixel values or display interface 1610. The process of producing a user-viewable video from a bitstream is sometimes referred to as video decompression. Further, while certain video processing actions are called "coding" actions or tools, such coding tools or actions are used in encoders and the corresponding decoding tools or actions that swap the results of coding are performed by the decoder. It will be understood that it will be.

Examples of peripheral bus interfaces or display interfaces may include universal serial bus (USB) or high definition multimedia interfaces (HDMI®) or Displayport®. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interface, and the like. The techniques described herein may be embodied in various electronic devices such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

FIG. 17 is a flowchart representation of Method 1700 for video processing according to the present disclosure. Method 1700, in operation 1702, uses an affine coding tool to convert between the current block of video and a bitstream representation of the video, the first motion vector of the subblock of the current block, and the current. It includes a step of determining that the second motion vector, which is the representative motion vector of the block, is subject to size constraints. Method 1700 also includes the step of performing the transformation based on the determination in operation 1704.

In some embodiments, the first motion vector of the subblock is represented as (MVx, MVy) and the second motion vector is represented as (MV'x, MV'y). The size constraint indicates that MVx> = MV'x-DH0, MVx <= MV'x + DH1, MVy> = MV'y-DV0, and MVy <= MV'y + DV1, and DH0, DH1, DV0 and DV1. It is a positive number. In some embodiments, DH0 = DH1. In some embodiments, DH0 ≠ DH1. In some embodiments, DV0 = DV1. In some embodiments, DV0 ≠ DV1. In some embodiments, DH0 = DV0. In some embodiments, DH0 ≠ HV0. In some embodiments, DH1 = DV1. In some embodiments, DH1 ≠ DV1.

In some embodiments, at least one of DH0, DH1, DV0 and DV1 is a video parameter set level, a sequence parameter set level, a picture parameter set level, a slice header, a tile group header, a tile level, a coding tree unit. Notified in bitstream representation at level, coding unit level, or predictive unit level. In some embodiments, DH0, DH1, DV0 and DV1 are different for different profiles, levels, or tiers of conversion. In some embodiments, DH0, DH1, DV0 and DV1 are based on the width or height of the current block. In some embodiments, DH0, DH1, DV0 and DV1 are based on the prediction mode of the current block and the prediction mode is one-way prediction mode or two-way prediction mode. In some embodiments, DH0, DH1, DV0 and DV1 are based on the position of the subblock within the current block.

In some embodiments, the second motion vector has the control point motion vector of the current block. In some embodiments, the second motion vector has the motion vector of the second subblock of the current block. In some embodiments, the second subblock has a central subblock of the current block. In some embodiments, the second subblock has a corner subblock of the current block. In some embodiments, the second motion vector has a motion vector derived for a position inside or outside the current block, the position being coded using the same affine model as the current block. In some embodiments, the position has the center position of the current block.

In some embodiments, the first motion vector is adjusted to satisfy the size constraint. In some embodiments, the bitstream is not valid if the first motion vector is unable to satisfy the size constraint with respect to the second motion vector. In some embodiments, the first motion vector and the second motion vector are represented according to the motion vector signaling accuracy in the bitstream representation. In some embodiments, the first motion vector and the second motion vector are represented according to the storage accuracy for storing the motion vector. In some embodiments, the first motion vector and the second motion vector are represented according to a motion vector signaling accuracy or an accuracy different from the storage accuracy for storing the motion vector.

FIG. 18 is a flowchart representation of the video processing method 1800 according to the present disclosure. Method 1800, in operation 1802, comprises the step of determining an affine model with six parameters for the conversion between the current block of video and the bitstream representation of video. The affine model is inherited from the affine coding information of the adjacent block of the current block. Method 1800 includes a step of performing a transformation based on its affine model in operation 1804.

In some embodiments, adjacent blocks are coded using a second affine model with six parameters. The affine model is the same as the second affine model. In some embodiments, adjacent blocks are coded using a third affine model with four parameters. In some embodiments, the affine model is determined based on the current block position. In some embodiments, the affine model is determined according to a third affine model when the adjacent block is not in the same coding tree unit (CTU) as the current block. In some embodiments, the affine model is determined according to the third affine model when the adjacent block is not on the same CTU line or the same CTU row as the current block.

In some embodiments, the tile, slice, or picture is divided into multiple non-overlapping areas. In some embodiments, the affine model is determined according to a third affine model when adjacent blocks are not in the same region as the current block. In some embodiments, the affine model is determined according to a third affine model when adjacent blocks are not on the same region line or row as the current block. In some embodiments, each region has a size of 64 x 64. In some embodiments, the upper left corner of the current block is represented as (x, y), the upper left corner of the adjacent block is represented as (x', y'), and the affine model is x, y. , X'and y'are satisfied according to the third affine model. In some embodiments, the condition indicates that x / M ≠ x'/ M, where M is a positive integer. In some embodiments, M is 128 or 64. In some embodiments, the condition indicates that y / N ≠ y'/ N, where N is a positive integer. In some embodiments, N is 128 or 64. In some embodiments, the condition indicates that x / M ≠ x'/ M and y / N ≠ y'/ N, where M and N are positive integers. In some embodiments, M = N = 128 or M = N = 64. In some embodiments, the condition indicates that x >> M ≠ x'>> M, where M is a positive integer. In some embodiments, M is 6 or 7. In some embodiments, the condition indicates that y >> N ≠ y'>> N, where N is a positive integer. In some embodiments, N is 6 or 7. In some embodiments, the condition indicates that x >> M ≠ x'>> M and y >> N ≠ y'>> N, where M and N are positive integers. In some embodiments, M = N = 6 or M = N = 7.

FIG. 19 is a flowchart representation of the video processing method 1900 according to the present disclosure. Method 1900 has a width W and a height H to determine in operation 1902 whether a bi-predictive coding technique is applicable to a block of video and a bitstream representation of the video. W and H are positive integers, including the step of determining based on the size of the block. Method 1900 includes the step of performing the transformation according to the determination in operation 1904.

In some embodiments, the bi-predictive coding technique is not applicable when W = T1 and H = T2, where T1 and T2 are positive integers. In some embodiments, the bi-predictive coding technique is not applicable when W = T2 and H = T1, where T1 and T2 are positive integers. In some embodiments, the bi-predictive coding technique is not applicable when W = T1 and H≤T2, where T1 and T2 are positive integers. In some embodiments, the bi-predictive coding technique is not applicable when W≤T2 and H = T1, where T1 and T2 are positive integers. In some embodiments, T1 = 4 and T2 = 16. In some embodiments, the bi-predictive coding technique is not applicable for W ≦ T1 and H ≦ T2, where T1 and T2 are positive integers. In some embodiments, T1 = T2 = 8. In some embodiments, T1 = 8 and T2 = 4. In some embodiments, T1 = T2 = 4. In some embodiments, T1 = 4 and T2 = 8.

In some embodiments, an indicator indicating information about the bi-predictive coding technique is notified in a bitstream where the bi-predictive coding technique is applicable. In some embodiments, an indicator showing information about a bi-predictive coding technique for a block is removed from the bitstream if the bi-predictive coding technique is not applicable to the block. In some embodiments, the bi-predictive coding technique is not applicable when the block size is one of 4x8 or 8x4. In some embodiments, the bi-predictive coding technique is not applicable when the block size is 4 × N or N × 4, where N is a positive integer and N ≦ 16. In some embodiments, the size of the block corresponds to the first color component of the block and whether the bi-predictive coding technique is applicable is determined for the first color component of the block and the remaining color components. Will be done. In some embodiments, the block size corresponds to the first color component of the block, and the applicability of the bi-predictive coding technique is determined only for the first color component. In some embodiments, the first color component comprises a luma component.

In some embodiments, the method is the first when it is determined that the selected merge candidate is coded using the bi-predictive coding technique if the bi-predictive coding technique is not applicable to the current block. It further has a step of assigning a single motion vector from one reference list or a second reference list. In some embodiments, the method further comprises a step of determining that if the bi-predictive coding technique is not applicable to the current block, then the triangular predictive mode is not applicable to that block. In some embodiments, the applicability of the bi-predictive coding technique is associated with the predictive direction, the predictive direction is further associated with the one-sided predictive coding technique, and the predictive direction is a bit based on the size of the block. Notified in the stream. In some embodiments, information about one-sided predictive coding techniques is communicated in the bitstream when (1) W × H <64 or (2) W × H = 64, where W is not equal to H. In some embodiments, information about a one-way or two-way predictive coding technique is notified in a bitstream if (1) W × H> 64 or (2) W × H = 64, where W is H. be equivalent to.

In some embodiments, the limitation indicates that neither bi-predictive coding techniques nor single-predictive coding techniques are applicable to blocks when the block size is 4x4. In some embodiments, the limitation is applicable when the block is affine coded. In some embodiments, the limitation is applicable when the block is not affine coded. In embodiments, the restrictions are applicable when the block is intracoded. In some embodiments, the limitation is not applicable if the motion vector of the block has integer precision.

In some embodiments, notifying that the block is generated based on the division of the parent block is skipped in the bitstream. The parent block is (1) 8x8 for quadtree split, (2) 8x4 or 4x8 for binary split, or (3) 4x16 or 16x4 for ternary split. Has the size of. In some embodiments, the indicator that the motion vector has integer precision is set to 1 in the bitstream. In some embodiments, the motion vector of the block is rounded to integer precision.

In some embodiments, the bi-predictive coding technique is applicable to blocks. The reference block has a size of (W + N-1-PW) × (H + N-1-PH), and the boundary pixel of the reference block has a size of (W + N-1) × (H + N-1) for interpolation operation. Repeatedly to generate a second block with, where N represents an interpolating filter tap and N, PW and PH are integers. In some embodiments, PH = 0 and at least left or right bound pixels are repeated to produce a second block. In some embodiments, PW = 0 and at least the top or bottom bound pixels are repeated to produce a second block. In some embodiments, PW> 0 and PH> 0, and the second block is by repeating at least left or right boundary pixels, followed by at least upper or lower boundary pixels. , Generated. In some embodiments, PW> 0 and PH> 0, and the second block is by repeating at least the pixels on the upper or lower boundary, followed by repeating at least the pixels on the left or right boundary. , Generated. In some embodiments, the left bound pixel is repeated M1 times and the right bound pixel is repeated (PW-M1) times. In some embodiments, the pixels on the upper boundary are repeated M2 times and the pixels on the lower boundary are repeated (PH-M2) times. In some embodiments, how the bounding pixels of the reference pixels are repeated apply to some or all reference blocks for conversion. In some embodiments, the PW and PH are different for different components of the block.

In some embodiments, the merge candidate list construction process is performed based on the size of the block. In some embodiments, the merge candidate is a one-sided predictive coding technique where (1) the merge candidate is coded using a bi-predictive coding technique and (2) the bi-prediction is not applicable to the block according to the size of the block. It is regarded as a one-sided prediction candidate that refers to the first reference list. In some embodiments, the first reference list has reference list 0 or reference list 1 of a piecewise predictive coding technique. In some embodiments, merge candidates are considered unavailable if (1) the merge candidate is coded using a bi-predictive coding technique and (2) the bi-prediction is not applicable to the block according to the size of the block. Is done. In some embodiments, unavailable merge candidates are removed from the merge candidate list in the merge candidate list construction process. In some embodiments, the merge candidate list construction process for triangular prediction mode is called when bi-prediction is not applicable to the block according to the size of the block.

FIG. 20 is a flowchart representation of the video processing method 2000 according to the present disclosure. Method 2000 determines in operation 2002 whether the coding tree splitting process is applicable to the block for the conversion between the video block and the video bitstream representation, according to the coding tree splitting process, child coding of the block. Includes steps to determine based on the size of the subblock that is the unit. The subblock has a width W and a height H, where W and H are positive integers. Method 2000 also includes the step of performing the transformation according to the determination in operation 2004.

In some embodiments, the coding tree splitting process is not applicable when W = T1 and H = T2, where T1 and T2 are positive integers. In some embodiments, the coding tree splitting process is not applicable when W = T2 and H = T1, where T1 and T2 are positive integers. In some embodiments, the coding tree splitting process is not applicable when W = T1 and H≤T2, where T1 and T2 are positive integers. In some embodiments, the coding tree splitting process is not applicable when W≤T2 and H = T1, where T1 and T2 are positive integers. In some embodiments, T = 4 and T2 = 16. In some embodiments, the coding tree splitting process is not applicable when W ≦ T1 and H ≦ T2, where T1 and T2 are positive integers. In some embodiments, T1 = T2 = 8. In some embodiments, T1 = 8 and T2 = 4. In some embodiments, T1 = T2 = 4. In some embodiments, T1 = 4. In some embodiments, T2 = 4. In some embodiments, the signaling of the coding tree splitting process is removed from the bitstream if the coding tree splitting process is not applicable to the current block.

FIG. 21 is a flowchart representation of the video processing method 2100 according to the present disclosure. In operation 2102, whether the index of the coding unit level weighted bi-prediction (BCW) coding mode is derived for the conversion between the current block of video and the bitstream representation of the video. Includes steps to determine based on the rules regarding the position of the block. In BCW coding mode, a weight set containing multiple weights is used to generate the bipredicted value of the current block. Method 2100 also includes the step of performing the conversion according to the determination in operation 2104.

In some embodiments, the bipredicted value of the current block is generated as a non-average weighted sum of the two motion vectors when at least one weight in the weight set is applied. In some embodiments, the rule stipulates that if the current block and adjacent blocks are located in different coding tree units or maximum coding units, the index will not be derived according to the adjacent blocks. In some embodiments, the rule stipulates that if the current block and adjacent blocks are located on different lines or rows within the coding tree unit, the index will not be derived according to the adjacent blocks. In some embodiments, the rule is that if the current block and adjacent blocks are located in different non-overlapping areas of the video tiles, slices, or pictures, the index will not be derived according to the adjacent blocks. stipulate. In some embodiments, the rule stipulates that if the current block and adjacent blocks are located on different rows of non-overlapping areas of video tiles, slices, or pictures, the index will not be derived according to the adjacent blocks. .. In some embodiments, each region has a size of 64 x 64.

In some embodiments, the top angle of the current block is represented as (x, y) and the top angle of the adjacent block is represented as (x', y'). The rule stipulates that if (x, y) and (x', y') satisfy the condition, the index is not derived according to the adjacent block. In some embodiments, the condition indicates that x / M ≠ x'/ M, where M is a positive integer. In some embodiments, M is 128 or 64. In some embodiments, the condition indicates that y / N ≠ y'/ N, where N is a positive integer. In some embodiments, N is 128 or 64. In some embodiments, the condition indicates that (x / M ≠ x'/ M) and (y / N ≠ y'/ N), where M and N are positive integers. In some embodiments, M = N = 128 or M = N = 64. In some embodiments, the condition indicates that x >> M ≠ x'>> M, where M is a positive integer. In some embodiments, M is 6 or 7. In some embodiments, the condition indicates that y >> N ≠ y'>> N, where N is a positive integer. In some embodiments, N is 6 or 7. In some embodiments, the condition indicates that (x >> M ≠ x'>> M) and (y >> N ≠ y'>> N), where M and N are positive integers. .. In some embodiments, M = N = 6 or M = N = 7.

In some embodiments, whether the BCW coding mode is applicable to a picture, slice, tile group, or tile is notified in the picture parameter set, slice header, tile group header, or tile in the bitstream, respectively. The tile. In some embodiments, whether the BCW coding mode is applicable to a picture, slice, tile group, or tile is derived based on the information associated with the picture, slice, tile group, or tile. In some embodiments, the information has at least a quantization parameter (QP), a time layer, or a picture order count (POC) distance.

FIG. 22 is a flowchart representation of the video processing method 2200 according to the present disclosure. Method 2200, in operation 2202, for the conversion between the current block of video and the bitstream representation of the video, coded using the Combined Inter and Intra Prediction (CIIP) coding technique. Includes a step to determine the intra-prediction mode of the current block independently of the intra-prediction mode of the adjacent block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. Method 2200 also includes the step of performing the transformation based on the determination in operation 2204.

In some embodiments, the intra-prediction mode of the current block is determined without reference to the intra-prediction mode of any adjacent block. In some embodiments, adjacent blocks are coded using CIIP coding techniques. In some embodiments, the intra-prediction of the current block is determined based on the intra-prediction mode of the second adjacent block, which is coded using the intra-prediction coding technique. In some embodiments, whether or not the intra prediction mode of the current block should be determined according to the second intra prediction mode is the relationship between the current block as the first block and the second adjacent block as the second block. Based on whether the conditions that determine are satisfied. In some embodiments, the decision is part of the most probable mode (MPM) configuration process of the current block for deriving a list of MPM modes.

FIG. 23 is a flowchart representation of the video processing method 2300 according to the present disclosure. Method 2300 is the first adjacent block for conversion between the current block of video and the bitstream representation of the video coded using inter- and intra-composite prediction (CIIP) coding techniques in operation 2302. It includes a step of determining the intra prediction mode of the current block according to the intra prediction mode and the second intra prediction mode of the second adjacent block. The first adjacent block is coded using the intra-predictive coding technique and the second adjacent block is coded using the CIIP coding technique. The first intra prediction mode is given a different priority than the second intra prediction mode. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. Method 2300 also includes the step of performing the transformation based on the determination in operation 2304.

In some embodiments, the determining step is part of the most probable mode (MPM) configuration process of the current block for deriving a list of MPM modes. In some embodiments, the first intra prediction mode precedes the second intra prediction mode in the MPM candidate list. In some embodiments, the first intra-prediction mode is located after the second intra-prediction mode in the MPM candidate list. In some embodiments, the coding of the intra-predictive mode bypasses the most probable mode (MPM) configuration process of the current block. In some embodiments, the method also comprises the step of determining the intra-prediction mode of a subsequent block according to the intra-prediction mode of the current block. Here, the subsequent block is coded using the intra-predictive coding technique, and the current block is coded using the CIIP coding technique. In some embodiments, the determining step is part of the most probable mode (MPM) configuration process of the subsequent block. In some embodiments, in the MPM configuration process of a subsequent block, the intra-prediction mode of the current block gives a lower priority than the intra-prediction mode of other adjacent blocks coded using the intra-prediction coding technique. Be done. In some embodiments, whether the intra-prediction mode of a subsequent block should be determined according to the intra-prediction mode of the current block is between the subsequent block as the first block and the current block as the second block. It is based on whether the conditions that determine the relationship are satisfied. In some embodiments, the conditions are: (1) the first and second blocks are located on the same line of the coding tree unit, (2) the first and second blocks are located on the same CTU. Have at least one of (3) the first and second blocks are located in the same area, or (4) the first and second blocks are in the same line of the area. In some embodiments, the width of the region is the same as the height of the region. In some embodiments, the region has a size of 64 x 64.

In some embodiments, only a subset of the list of most probable modes (MPMs) for conventional intracoding techniques is used for the current block. In some embodiments, the subset has a single MPM mode within the list of MPM modes for conventional intracoding techniques. In some embodiments, the single MPM mode is the first MPM mode in the list. In some embodiments, the index indicating a single MPM mode is omitted in the bitstream. In some embodiments, the subset has the first four MPM modes in the list of MPM modes. In some embodiments, the index indicating the MPM mode within the subset is communicated in the bitstream. In some embodiments, the coding context for coding the intracoded block is reused for coding the current block. In some embodiments, the first MPM flag for the intracoded block and the second MPM flag for the current block share the same coding context in the bitstream. In some embodiments, the intra prediction mode of the current block is selected from the list of MPM modes regardless of the size of the current block. In some embodiments, the MPM configuration process is defaulted to being valid, and the flag indicating the MPM configuration process is omitted in the bitstream. In some embodiments, the MPM list construction process is unnecessary for the current block.

In some embodiments, a luma-predicted chroma mode is used to process the chroma component of the current block. In some embodiments, a derivation mode is used to process the chroma component of the current block. In some embodiments, multiple intra-prediction modes are used to process the chroma component of the current block. In some embodiments, multiple intra-prediction modes are used based on the color format of the chroma component. In some embodiments, when the color format is 4: 4: 4, the multiple intra-prediction modes are the same as the intra-prediction modes for the luma component of the current block. In some embodiments, each of the four intra-prediction modes is coded with one or more bits, the four intra-prediction modes including a planar mode, a DC mode, a vertical mode, and a horizontal mode. In some embodiments, the four intra prediction modes are coded using 00, 01, 10 and 11. In some embodiments, the four intra prediction modes are 0,
It is coded using 10, 110, 111. In some embodiments, the four intra prediction modes are coded using 1,01,001,000. In some embodiments, only a subset of the four intra-prediction modes are available for use if the width W and height H of the current block satisfy the conditions. In some embodiments, the subset has a planar mode, a DC mode, and a vertical mode when W> N × N, where N is an integer. In some embodiments, the planar mode, DC mode, and vertical mode are coded using 1, 01, and 11. In some embodiments, the planar mode, DC mode, and vertical mode are coded using 0, 10, and 00. In some embodiments, the subset has a planar mode, a DC mode, and a horizontal mode when H> N × W, where N is an integer. In some embodiments, the planar mode, DC mode, and horizontal mode are coded using 1, 01, and 11. In some embodiments, the planar mode, DC mode, and horizontal mode are coded using 0, 10, and 00. In some embodiments, N = 2. In some embodiments, only DC mode and planar mode are used for the current block. In some embodiments, an indicator indicating DC mode or planar mode is signaled in the bitstream.

FIG. 24 is a flowchart representation of the video processing method 2400 according to the present disclosure. Method 2400 is operation 2402, is the inter- and intra-complex prediction (CIIP) process applicable to the color components of the current block for the conversion between the current block of video and the bitstream representation of the video? Includes a step to determine whether or not based on the size of the current block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. Method 2400 also includes the step of performing the transformation based on the determination in operation 2404.

In some embodiments, the color component has a chroma component and the CIIP process is not performed on the chroma component if the current block width is less than 4. In some embodiments, the color component has a chroma component and the CIIP process is not performed on the chroma component if the height of the current block is less than 4. In some embodiments, the intra prediction mode for the chroma component of the current block is different from the intra prediction mode for the luma component of the current block. In some embodiments, the chroma component uses one of a DC mode, a planar mode, or a luma predictive chroma mode. In some embodiments, the intra prediction mode for the chroma component is determined based on the color format of the chroma component. In some embodiments, the color format has 4: 2: 0 or 4: 4: 4.

FIG. 25 is a flowchart representation of the video processing method 2500 according to the present disclosure. Method 2500, in operation 2502, should inter- and intra-composite prediction (CIIP) coding techniques be applied to the current block for the conversion between the current block of video and the bitstream representation of the video? Includes steps to determine whether or not based on the characteristics of the current block. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. Method 2500 also includes the step of performing the transformation based on the determination in operation 2504.

In some embodiments, the property has that the size of the current block is width W and height H, where W and H are integers, and the inter-intra-predictive coding technique is conditional on block size. If satisfied, it will be disabled for the current block. In some embodiments, the condition indicates that W is equal to T1 and T1 is an integer. In some embodiments, the condition indicates that H is equal to T1 and T1 is an integer. In some embodiments, T1 = 4. In some embodiments, T1 = 2. In some embodiments, the condition indicates that W is greater than T1 or H is greater than T1, where T1 is an integer. In some embodiments, T1 = 64 or 128. In some embodiments, the condition indicates that W is equal to T1 and H is equal to T2, where T1 and T2 are integers. In some embodiments, the condition indicates that W is equal to T2 and H is equal to T1, where T1 and T2 are integers. In some embodiments, T1 = 4 and T2 = 16.

In some embodiments, the property has a coding technique applied to the current block, and the CIIP coding technique is disabled for the current block if the coding technique meets the conditions. .. In some embodiments, the condition indicates that the coding technique is a bi-predictive coding technique. In some embodiments, the bi-predictive-coded merge candidate is converted into a single-predictive-coded merge candidate to allow the inter-intra-predictive coding technique to be applied to the current block. In some embodiments, the transformed merge candidates are associated with reference list 0 of the one-sided predictive coding technique. In some embodiments, the transformed merge candidates are associated with reference list 1 of the one-sided predictive coding technique. In some embodiments, only one-sided predictive-coded merge candidates for blocks are selected for conversion. In some embodiments, the bi-predictive coded merge candidates are discarded to determine the merge index that indicates the merge candidate in the bitstream representation. In some embodiments, the inter-intra-predictive coding technique is applied to the current block as determined. In some embodiments, the merge candidate list construction process for the triangular prediction mode is used to derive a motion candidate list for the current block.

FIG. 26 is a flowchart representation of the video processing method 2600 according to the present disclosure. Method 2600 currently determines in operation 2602 whether the coding tool should be disabled for the current block due to the conversion between the current block of video and the bitstream representation of the video. It involves determining based on whether the block is coded by the Inter and Intra Composite Prediction (CIIP) coding technique. The CIIP coding technique uses intermediate inter-predicted values and intermediate intra-predicted values to derive the final predicted values for the current block. The coding tool has at least one of bidirectional optical flow (BDOF), overlap block motion compensation (OBMC), or decoder-side motion vector refinement process (DMVR). Method 2500 also includes the step of performing the transformation based on the determination in operation 2504.

In some embodiments, the intra-prediction process for the current block is different from the intra-prediction process for the second block, which is coded using the intra-prediction coding technique. In some embodiments, the intra-prediction process for the current block skips filtering of adjacent samples. In some embodiments, the intra-prediction process for the current block disables position-dependent intra-prediction sample filtering. In some embodiments, the intra-prediction process for the current block disables the multi-line intra-prediction process. In some embodiments, the intra-prediction process for the current block disables the wide-angle intra-prediction process.

FIG. 27 is a flowchart representation of the video processing method 2700 according to the present disclosure. Method 2700 is operation 2702, the first prediction P1 used for the motion vector for spatial motion prediction for the conversion between the video block and the video bitstream representation, and the temporal motion prediction. Includes a step to determine the second prediction P2 used for the motion vector. P1 and / or P2 are fractions, and P1 and P2 are different from each other. Method 2700 also includes the step of performing the transformation based on the determination in operation 2704.

In some embodiments, the first precision is 1/16 luma pixels and the second precision is 1/4 luma pixels. In some embodiments, the first precision is 1/16 luma pixels and the second precision is 1/8 luma pixels. In some embodiments, the first precision is 1/8 luma pixels and the second precision is 1/4 luma pixels. In some embodiments, the first precision is 1/16 luma pixels and the second precision is 1/4 luma pixels. In some embodiments, the first precision is 1/16 luma pixels and the second precision is 1/8 luma pixels. In some embodiments, the first precision is 1/8 luma pixels and the second precision is 1/4 luma pixels. In some embodiments, at least one of the first or second accuracy is lower than 1/16 luma pixels.

In some embodiments, at least one of the first or second accuracy is variable. In some embodiments, the first or second accuracy is variable according to the profile, level, or tier of the video. In some embodiments, the first or second precision is variable according to the time layer of the picture in the video. In some embodiments, the first or second precision is variable depending on the size of the picture in the video.

In some embodiments, at least one of the first or second precision is a video parameter set, sequence parameter set, picture parameter set, slice header, tile group header, tile, coding tree unit, or in bitstream representation. Notified by the coding unit. In some embodiments, the motion vector is represented as (MVx, MVy), the accuracy of the motion vector is represented as (Px, Py), Px is associated with MVx, and Py is associated with MVy. In some embodiments, Px and Py are variable according to the profile, level, or tier of the video. In some embodiments, Px and Py are variable according to the time layer of the picture in the video. In some embodiments, Px and Py are variable according to the width of the picture in the video. In some embodiments, Px and Py are signaled by a video parameter set, a sequence parameter set, a picture parameter set, a slice header, a tile group header, a tile, a coding tree unit, or a coding unit in a bitstream representation. In some embodiments, the decoded motion vector is represented as (MVx, MVy) and the motion vector is adjusted according to the second system before the motion vector is stored as a time motion predicted motion vector. .. In some embodiments, the time motion prediction motion vector is adjusted to be (Shift (Mvx, P1-P2), Shift (MVy, P1-P2)), where P1 and P2 are integers and P1 ≧ P2. And Shift represents a right-shift operation on an unsigned number. In some embodiments, the time motion prediction motion vector is adjusted to be (SignShift (MVx, P1-P2), SignShift (MVy, P1-P2)), where P1 and P2 are integers and P ≧ P2. And SignShfit represents a right-shift operation on a signed number. In some embodiments, the time motion prediction motion vector is adjusted to be (MVx << (P1-P2), MVy << (P1-P2)), P1 and P2 are integers, and P1 ≧ P2. And << represents a left-shift operation on a signed or unsigned number.

FIG. 28 is a flowchart representation of the video processing method 2800 according to the present disclosure. Method 2800 includes a step of determining a motion vector (Mvx, MVy) by prediction (Px, Py) for conversion between a block of video and a bitstream representation of video in operation 2802. Px is associated with MVx and Py is associated with MVy. MVx and MVy are represented using N bits, MinX ≦ MVx ≦ MaxX and MinY ≦ MVy ≦ MaxY, and MinX, MaxX, MinY, and MaxY are real numbers. Method 2800 also includes the step of performing the transformation based on the determination in operation 2804.

In some embodiments, MinX = MinY. In some embodiments, MinX ≠ MinY. In some embodiments, MaxX = MaxY, in some embodiments, MaxX ≠ MaxY.

In some embodiments, at least one of MinX or MaxX is based on Px. In some embodiments, the motion vector has a precision expressed as (Px, Py) and at least one of MinY or MaxY is based on Py. In some embodiments, at least one of MinX, MaxX, MinY, or MaxY is based on N. In some embodiments, at least one of the MinX, MaxX, MinY, or MaxY for the spatial motion predictive motion vector is with the corresponding MinX, MaxX, MinY, or MaxY for the temporal motion predictive motion vector. Is different. In some embodiments, at least one of MinX, MaxX, MinY, or MaxY is variable according to the profile, level, or tier of the video. In some embodiments, at least one of MinX, MaxX, MinY, or MaxY is variable according to the time layer of the picture in the video. In some embodiments, at least one of MinX, MaxX, MinY, or MaxY is variable depending on the size of the picture in the video. In some embodiments, at least one of MinX, MaxX, MinY, or MaxY is a video parameter set, sequence parameter set, picture parameter set, slice header, tile group header, tile, coding tree in bitstream representation. Notified by the unit or coding unit. In some embodiments, the MVx is clipped to [MinY, MaxX] before being used for spatial or temporal motion prediction. In some embodiments, the MVy is clipped to [MinY, MaxY] before being used for spatial or temporal motion prediction.

FIG. 29 is a flowchart representation of the video processing method 2900 according to the present disclosure. Method 2900, in operation 2902, determines whether the shared merge list is applicable to the current block for the conversion between the current block of video and the bitstream representation of the video, in the coding mode of the current block. Includes steps to determine according to. Method 2900 also includes the step of performing the transformation based on the determination in operation 2904.

In some embodiments, the shared merge list is not applicable if the current block is coded using regular merge mode. In some embodiments, the shared merge list is applicable when the current block is coded using the Intra Block Copy (IBC) mode. In some embodiments, the method presents a table of motion candidates based on past conversions of video and bitstream representations, and a step of performing the conversion, prior to the step of performing the conversion. The current block is coded using regular merge mode, with a further step to disable the update of the motion candidate table if the block is a child of the parent block to which the shared merge list is applicable. To.

FIG. 30 is a flowchart representation of the video processing method 3000 according to the present disclosure. Method 3000 is a dimension for motion compensation during conversion (W + N-1) × for conversion between the current block of video having a size of W × H and a bitstream representation of the video in operation 3002. A step of determining the second block of (H + N-1) is included. The second block is determined based on the reference block of dimensions (W + N-1-PW) × (H + N-1-PH). N represents the filter size, and W, H, N, PW and PH are non-negative integers. Both PW and PH are not equal to zero. Method 3000 also includes the step of performing the transformation based on the determination in operation 3004.

In some embodiments, the pixels in the second block located outside the reference block are determined by repeating one or more boundaries of the reference block. In some embodiments, PH = 0 and at least the left or right boundary of the reference block is repeated to generate a second block. In some embodiments, PW = 0 and at least the upper or lower boundary of the reference block is repeated to generate the second block. In some embodiments, PW> 0 and PH> 0, the second block repeats at least the left or right boundary of the reference block, followed by at least the upper or lower boundary of the reference block. Generated. In some embodiments, PW> 0 and PH> 0, the second block repeats at least the upper or lower boundary of the reference block, followed by at least the left or right boundary of the reference block. Generated.

In some embodiments, the left boundary of the reference block is repeated M1 times, the right boundary of the reference block is repeated (PW-M1) times, and M is a positive integer. In some embodiments, the upper boundary of the reference block is repeated M2 times, the lower boundary of the reference block is repeated (PH-M2) times, and M2 is a positive integer. In some embodiments, at least one of PW or PH is different for each different color component of the current block, the color component comprising at least a luma component or one or more chroma components. In some embodiments, at least one of PW or PH is variable according to the size or shape of the current block. In some embodiments, at least one of the PWs or PHs is variable according to the coding characteristics of the current block, the coding characteristics including single-predictive coding or bi-predictive coding.

In some embodiments, the pixels in the second block located outside the reference block are set to a single value. In some embodiments, the single value is 1 << (BD-1), where BD is the bit depth of the pixel sample in the reference block. In some embodiments, the BD is 8 or 10. In some embodiments, the single value is derived based on a pixel sample of the reference block. In some embodiments, a single value is notified by a video parameter set, sequence parameter set, picture parameter set, slice header, tile group header, tile, coding tree unit row, coding tree unit, coding unit, or prediction unit. Will be done. In some embodiments, the padding of pixels in a second block located outside the reference block is disabled if the current block is affine coded.

FIG. 31 is a flowchart representation of the video processing method 3100 according to the present disclosure. Method 3100 is a dimension for motion compensation during conversion (W + N-1) × for conversion between the current block of video having a size of W × H and a bitstream representation of the video in operation 3102. A step of determining the second block of (H + N-1) is included. W and H are non-negative integers and N is a non-negative integer based on the filter size. During the transformation, the refined motion vector is determined based on a multipoint search according to the motion vector refinement action against the original motion vector, and the pixel length boundaries of the reference block are determined by repeating one or more non-boundary pixels. It is determined. Method 3100 also includes the step of performing the transformation based on the determination in operation 3104.

In some embodiments, processing the current block comprises filtering the current block in a motion vector refinement operation. In some embodiments, whether the reference block is applicable to the processing of the current block is determined based on the dimensions of the current block. In some embodiments, interpolating the current block comprises interpolating a plurality of subblocks of the current block based on a second block. Each subblock has a size of W1 × H1, and W1 and H1 are non-negative integers. In some embodiments, W1 = H1 = 4, W = H = 8, PW = PH = 0. In some embodiments, the second block is determined as a whole based on the integer part of at least one motion vector of the plurality of subblocks. In some embodiments, the reference block is the integer part of the motion vector of the upper left subblock of the current block if the maximum difference between the integer parts of the motion vectors of all the plurality of subblocks is less than or equal to 1 pixel. Each of the right and bottom boundaries of the reference block is determined based on, and is repeated once to acquire the second block. In some embodiments, the reference block is an integer of the motion vector of the lower right subblock of the current block if the maximum difference between the integer parts of the motion vectors of all the plurality of subblocks is less than or equal to 1 pixel. Each of the left and upper boundaries of the reference block is determined on the basis of, and is repeated once to acquire the second block. In some embodiments, the second block is determined as a whole based on one modified motion vector of a plurality of subblocks.

In some embodiments, if the maximum difference between the integer parts of the motion vectors of all the plurality of subblocks is 2 pixels or less, the motion vector of the upper left subblock of the current block is the modified motion vector. Is modified by adding one integer pixel distance to each component to obtain. The reference block is determined based on its modified motion vector, and each of the left, right, upper, and lower boundaries of the reference block is repeated once to obtain a second block.

In some embodiments, if the maximum difference between the integer parts of the motion vectors of all the plurality of subblocks is 2 pixels or less, the motion vector of the lower right subblock of the current block is the modified motion. It is modified by subtracting one integer pixel distance from each component to get the vector. The reference block is determined based on its modified motion vector, and each of the left, right, upper, and lower boundaries of the reference block is repeated once to obtain a second block.

FIG. 32 is a flowchart representation of the video processing method 3200 according to the present disclosure. Method 3200, in operation 3202, determines the predicted value at a position within the block for conversion between a block of video coded using the Inter-Intra Composite Prediction (CIIP) coding technique and a bitstream representation of the video. , Includes a step to determine based on the weighted sum of the inter-predicted and intra-predicted values at that position. The weighted sum is based on adding an offset to the initial sum obtained based on the inter-predicted and intra-predicted values, and the offset is added before the right shift operation performed to determine the weighted sum. Method 3200 also includes the step of performing the transformation based on the determination in operation 3204.

In some embodiments, the position within the block is represented by (x, y) and the interpredicted value at position (x, y) is represented by Pinter (x, y), at position (x, y). The intra-predicted value of is expressed as Pintra (x, y), the inter-predicted weight at the position (x, y) is expressed as w_inter (x, y), and the intra-predicted weight at the position (x, y) is w_intra. It is expressed as (x, y). The predicted value at the position (x, y) is (Pintra (x, y) x w_intra (x, y) + Pinter (x, y) x w_inter (x, y) + offset (x, y)) >> N. It is decided to be. Here, w_intra (x, y) + w_inter (x, y) = 2 ^N and offset (x, y) = 2 ^(N-1) , and N is a positive integer. In some embodiments, N = 2.

In some embodiments, the weighted sum is determined with equal weights for the inter-predicted and intra-predicted values at the location. In some embodiments, zero weights are used according to position within the block to determine the weighted sum. In some embodiments, the zero weight is applied to the inter-predicted value. In some embodiments, the zero weight is applied to the intra-predicted value.

FIG. 33 is a flowchart representation of the video processing method 3300 according to the present disclosure. Method 3300, in operation 3302, is partially present based on whether the conditions related to the size of the current block are satisfied for the conversion between the current block of video and the bitstream representation of the video. Includes steps to determine how the coding information for a block of is represented in a bitstream representation. Method 3300 also includes the step of performing the transformation based on the determination in operation 3304.

In some embodiments, the coding information is signaled in a bitstream representation if the conditions are met. In some embodiments, coding information is omitted in the bitstream representation if the conditions are met. In some embodiments, the Intra Block Copy (IBC) coding tool or the interpredictive coding tool is disabled for the current block if the conditions are met. In some embodiments, coding information is omitted in the bitstream representation when the IBC coding tool and the interpredictive coding tool are disabled. In some embodiments, the coding information is signaled in a bitstream representation when the IBC coding tool is enabled and the interpredictive coding tool is disabled.

In some embodiments, the coding information has an operating mode associated with an IBC coding tool and / or an interpredictive coding tool, and the operating mode has at least a normal mode or a skip mode. In some embodiments, the coding information has an indicator indicating the use of a predictive mode associated with the coding tool. In some embodiments, the coding tool is not used when the coding information is omitted in the bitstream representation. In some embodiments, coding tools are used when coding information is omitted in a bitstream representation. In some embodiments, the coding tool comprises an intra-block copy (IBC) coding tool or an inter-predictive coding tool.

In some embodiments, when an indicator is omitted in a bitstream, one or more indicators indicating one or more other coding tools are signaled in the bitstream representation. In some embodiments, the other coding tool has at least an intra coding tool or a palette coding tool. In some embodiments, the indicators distinguish between intermode and intramode, and one or more indicators include a first indicator indicating IBC mode and a second indicator indicating palette mode, which are interstitial. Signaled in the bitstream when the predictive coding tool is disabled and the IBC coding tool is enabled.

In some embodiments, the coding information has a third indicator for a skip mode, which is an interskip mode or an IBC skip mode. In some embodiments, the third indicator for skip mode is signaled when the interpredictive coding tool is disabled, but the IBC coding tool is enabled. In some embodiments, the predictive mode is when the interpredictive coding tool is disabled and the IBC coding tool is enabled, even though the indicator indicating the use of the IBC mode is omitted in the bitstream representation. , IBC mode is determined, and skip mode is applicable to the current block.

In some embodiments, the coding information has a triangular mode. In some embodiments, the coding information has an inter-prediction direction. In some embodiments, the coding information is omitted in the bitstream representation when the current block is coded using a one-sided predictive coding tool. In some embodiments, the coding information includes an indicator indicating the use of the Symmetric Motion Vector Difference (SMVD) method. In some embodiments, if the condition is satisfied, the current block is set to be one-sided predicted despite the indicator indicating the use of the SMVD method in the bitstream representation. In some embodiments, only List 0 or List 1 associated with the one-sided predictive coding tool is used in the motion compensation process when the indicator indicating the use of the SMVD method is removed from the bitstream.

In some embodiments, the condition indicates that the width of the current block is T1 and the height of the current block is T2, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is T2 and the height of the current block is T1, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is T1 and the height of the current block is T2 or less, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is T2 and the height of the current block is T1 or less, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is less than or equal to T1 and the height of the current block is less than or equal to T2, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is greater than or equal to T1 and the height of the current block is greater than or equal to T2, where T1 and T2 are positive integers. In some embodiments, the condition indicates that the width of the current block is greater than or equal to T1 or the height of the current block is greater than or equal to T2, where T1 and T2 are positive integers. In some embodiments, T1 = 4 and T2 = 16. In some embodiments, T1 = T2 = 8. In some embodiments, T1 = 8 and T2 = 4. In some embodiments, T1 = T2 = 4. In some embodiments, T1 = T2 = 32. In some embodiments, T1 = T2 = 64. In some embodiments, T1 = T2 = 128.

In some embodiments, the condition indicates that the current block has a size of 4x8, 8x4, 4x16, or 16x4. In some embodiments, the condition indicates that the current block has a size of 4x8, 8x4. In some embodiments, the condition indicates that the size of the current block is 4 × N or N × 4, where N is a positive integer and N ≦ 16. In some embodiments, the condition indicates that the size of the current block is 8 × N or N × 8, where N is a positive integer and N ≦ 16. In some embodiments, the condition indicates that the current block contains N or less samples of color components. In some embodiments, N = 16. In some embodiments, N = 32.

In some embodiments, the condition indicates that the color component of the current block has a width equal to the height. In some embodiments, the condition indicates that the color component of the current block has a size of 4x8, 8x4, 4x4, 4x16, or 16x4. In some embodiments, the color component has a luma component or one or more chroma components. In some embodiments, the inter-prediction tool is disabled if the condition indicates that the current block has a width of 4 and a height of 4. In some embodiments, the IBC prediction tool is disabled if the condition indicates that the current block has a width of 4 and a height of 4.

In some embodiments, the list 0 associated with the one-sided predictive coding tool is that (1) the current block has a width of 4 and a height of 8, or (2) the current block is 8. Used in motion compensation processes when having a width and a height of 4. The bi-predictive coding tool is disabled in the motion compensation process.

FIG. 34 is a flowchart representation of the video processing method 3400 according to the present disclosure. Method 3400 includes, in operation 3402, a step of determining a modified motion vector set for the conversion between the current block of video and the bitstream representation of video. Method 3400 comprises performing a transformation in motion 3404 based on the modified motion vector set. If the current block satisfies the condition, the modified motion vector set is a modified version of the motion vector set associated with the current block.

In some embodiments, the motion vector set is a regular merge coring technique, a subblock Temporal Motion Vector Prediction coding technique (sbTMVP), or a motion vector difference. Derived using one of the Merge with Motion Vector Difference (MMVD) coding techniques. In some embodiments, the motion vector set has a block vector used in an intra-block copy (IBC) coding technique. In some embodiments, the condition specifies that the size of the luma component of the current block is the same as the predefined size. In some embodiments, the predefined size has at least one of 8x4 or 4x8.

In some embodiments, changing the motion vector set means that the motion information of the current block refers to the first motion vector in the first reference picture list with respect to the first prediction direction. Converts a motion vector set to a unidirectional motion vector when it is determined to be bidirectional with a second motion vector that references a second reference picture in the second reference picture list with respect to the second prediction direction. Have that. In some embodiments, the motion information of the current block is derived based on the motion information of the adjacent blocks. In some embodiments, the method comprises discarding information in one of the first predictive directions or the second predictive direction. In some embodiments, discarding information involves changing the motion vector in the discarded predictive direction to (0,0). In some embodiments, discarding information involves changing the reference index in the discarded predictive direction to -1. In some embodiments, discarding information has the effect of changing the discarded predictive direction to the other predictive direction.

In some embodiments, the method further comprises deriving new motion candidates based on the information for the first predictive direction and the information for the second predictive direction. In some embodiments, deriving a new motion candidate determines the motion vector of the new motion candidate based on the average of the first motion vector in the first prediction direction and the second motion vector in the second prediction direction. Have to do. In some embodiments, deriving a new motion candidate is to determine the scaled motion vector by scaling the first motion vector in the first predictive direction according to the information for the second predictive direction. It has to determine a motion vector of a new motion candidate based on the average of the scaled motion vector and the second motion vector in the second prediction direction.

In some embodiments, the first reference picture list is List 0 and the second reference picture list is List 1. In some embodiments, the first reference picture list is list 1 and the second reference picture list is list 0. In some embodiments, the method comprises updating a table of motion candidates determined based on past transformations with the transformed motion vector. In some embodiments, the table comprises a Motion Vector Prediction (HMVP) table.

In some embodiments, the method updates a table of motion candidates determined based on past transformations with information for the first and second predictive directions before changing the motion vector set. Have to do. In some embodiments, the transformed motion vector is used for motion compensation motion for the current block. In some embodiments, the transformed motion vector is used to predict the motion vector of the following block. In some embodiments, the transformed motion vector is used for the deblocking process for the current block.

In some embodiments, the information for the first and second prediction directions before changing the motion vector set is used for the motion compensation operation for the current block. In some embodiments, the information prior to changing the motion vector set is used to predict the motion vector of subsequent blocks. In some embodiments, the information for the first and second predictive directions before changing the motion vector set is used for the deblocking process for the current block.

In some embodiments, the transformed motion vector is used for a motion refinement motion for the current block. In some embodiments, the information for the first and second predictive directions before changing the motion vector set is used for the refinement operation for the current block. In some embodiments, the refinement motion includes at least a bi-directional optical flow (BDOF) motion or an optical flow that includes a Prediction Refined with Optical Flow (PROF) motion. Has coding behavior.

In some embodiments, the method is to generate an intermediate prediction block based on information for a first prediction direction and information for a second prediction direction, to refine the intermediate prediction block, and to intermediate. Includes determining the final predictive block based on one of the predictive blocks.

FIG. 35 is a flowchart representation of the video processing method 3500 according to the present disclosure. Method 3500 determines a unidirectional motion vector from a bidirectional motion vector in operation 3502 when the block dimensional conditions are met for the conversion between the current block of video and the bitstream representation of the video. Including steps. The one-way motion vector is then used as a merge candidate for the transformation. Method 3500 also includes the step of performing the transformation based on the determination in operation 3504.

In some embodiments, the transformed unidirectional motion vector is used as a basic merge candidate in motion vector diff merge (MMVD) coding techniques. In some embodiments, the transformed unidirectional motion vector is then inserted into the merge list. In some embodiments, the unidirectional motion vector is transformed based on one predictive direction of the bidirectional motion vector. In some embodiments, the one-way motion vector is transformed based on only one predictive direction, which single predictive direction is associated with reference picture list 0. In some embodiments, the only prediction direction for the first candidate in the candidate list is associated with reference picture list 0 if the video data unit in which the current block is located is bi-predicted. And the only prediction direction for the second candidate in the candidate list is related to the reference picture list 1. The candidate list has a merge candidate list or an MMVD basic candidate list.

In some embodiments, the video data unit has a current slice, tile group, or picture of the video. In some embodiments, the unidirectional motion vector is determined based on the reference picture list 1 when all the reference pictures in the video data unit are past pictures according to the display order. In some embodiments, the unidirectional motion vector displays at least the first reference picture of the reference pictures of the video data unit as a past picture and at least the second reference picture of the reference pictures of the video data unit. If it is a future picture according to the order, it is determined based on the reference picture list 0. In some embodiments, unidirectional motion vectors determined based on different reference picture lists are interleaved in the merge list.

In some embodiments, the one-way motion vector is determined based on a low delay check indicator. In some embodiments, the unidirectional motion vector is determined during the transformation prior to the motion compensation process. In some embodiments, the one-way motion vector is determined after the motion candidate list construction process during the transformation. In some embodiments, the unidirectional motion vector is determined prior to adding the motion vector differences in the merge (MMVD) coding process with motion vector differences. In some embodiments, the one-way motion vector is determined prior to the sample refinement process. In some embodiments, the unidirectional motion vector is determined prior to the bidirectional optical flow (BDOF) process. In some embodiments, the BDOF process is subsequently disabled based on the decision to use a one-way motion vector.

In some embodiments, the unidirectional motion vector is determined prior to the Prediction Refinement with Optical Flow (PROF) process. In some embodiments, the unidirectional motion vector is determined prior to the Decoder-side Motion Vector Refinement (DMVR) process. In some embodiments, the DMVR process is subsequently disabled based on a one-way motion vector.

In some embodiments, the block dimension condition indicates that the width of the current block is T1 and the height of the current block is T2, where T1 and T2 are positive integers. In some embodiments, the block dimension condition indicates that the width of the current block is T2 and the height of the current block is T1, where T1 and T2 are positive integers. In some embodiments, the block dimension condition indicates that the width of the current block is T1 and the height of the current block is T2 or less, where T1 and T2 are positive integers. In some embodiments, the block dimension condition is that the width of the current block is T2, the height of the current block is T1 or less, and T1 and T2 are positive integers.

FIG. 36 is a flowchart representation of the video processing method 3600 according to the present disclosure. Method 3600 is operation 3602, where the motion candidate of the current block is a one-way prediction candidate based on the dimensions of the current block for the conversion between the current block of the video and the bitstream representation of the video. Includes steps to determine to be restricted. Method 3600 includes the step of performing the transformation based on the determination in operation 3604.

In some embodiments, all motion candidates of the current block are restricted to one-way prediction candidates if the dimensions of the current block satisfy the condition. In some embodiments, bidirectional motion candidates are transformed to be unidirectional predictive candidates if the dimensions of the current block satisfy the condition. In some embodiments, the dimensions of the current block indicate that the width of the current block is T1 and the height of the current block is T2, where T1 and T2 are positive integers. In some embodiments, the block dimensions condition indicates that the width of the current block is T2 and the height of the current block is T1, where T1 and T2 are positive integers. In some embodiments, the dimensions of the current block indicate that the width of the current block is T1 and the height of the current block is T2 or less, where T1 and T2 are positive integers. In some embodiments, the dimensions of the current block indicate that the width of the current block is T2 and the height of the current block is T1 or less, where T1 and T2 are positive integers. In some embodiments, T1 is equal to 4 and T2 is equal to 8. In some embodiments, T1 is equal to 4 and T2 is equal to 4. In some embodiments, T1 is equal to 8 and T2 is equal to 8.

In some embodiments, the step of performing the conversion in the above manner comprises generating a bitstream representation based on the current block of video. In some embodiments, the step of performing the conversion in the above manner comprises generating the current block of video from a bitstream representation.

As used herein, 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 conversion from a pixel representation of a video to a corresponding bitstream representation and vice versa. The bitstream representation of the current video block may correspond to bits that are either co-located or spread in different locations within the bitstream, as defined by the syntax, for example. For example, the macroblock may be encoded with respect to the transformed and coded error residues, as well as with the bits in the header and other fields in the bitstream. Furthermore, during the conversion, the decoder may parse the bitstream, knowing the possibility of the presence or absence of some fields, based on the determination, as described in the solution above. Similarly, the encoder may generate a bitstream representation by determining whether a particular syntax field should be included and, accordingly, including or excluding the syntax field from the coded representation. ..

The disclosed and other solutions, examples, embodiments, modules and functional operations described herein are in digital electronic circuits, or the structures disclosed herein and their structural equivalents. It can be implemented in computer software, firmware, or hardware, including, or in one or more combinations thereof. The disclosed and other embodiments are one or more computer program instructions encoded on a computer-readable medium for execution by or for control of one or more computer program products, eg, data processing equipment. It can be implemented as a module of. The computer-readable medium can be a machine-readable storage device, a machine-readable storage carrier, a memory device, a composition that provides a machine-readable propagation signal, or a combination thereof. The term "data processor" includes, by way of example, any device, device, and machine that processes data, including programmable processors, computers, or multiple processors or computers. In addition to the hardware, the device constitutes code that creates an execution environment for the computer program in question, such as processor firmware, protocol stack, database management system, operating system, or a combination of one or more of them. Can contain code to do. Propagation signals are artificially generated signals, such as machine-generated electrical, optical, or electromagnetic signals, generated to encode information for transmission to a suitable receiver device. Will be done.

A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, which can be written as a stand-alone program or as a compute. It can be deployed in any format, including as modules, components, subroutines, or other units suitable for use in the environment. Computer programs do not necessarily correspond to files in the file system. A program is a single file dedicated to the program in question, or multiple collaborative files (eg, a file that stores one or more modules, subprograms, or parts of code) and other programs. Alternatively, it can be stored in a portion of a file that holds the data (eg, one or more scripts stored in a markup language document). Computer programs can be deployed on one computer, in one location, or distributed across multiple locations and run on multiple computers interconnected by communication networks. ..

The processes and logic flows described in this document can be run by one or more programmable processors that run one or more computer programs to perform functions by acting on input data to produce output. Is. Processes and logic flows can also be run by dedicated logic circuits, such as field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs), and the device can be implemented as such. Is.

Suitable processors for running computer programs include, for example, both general purpose microprocessors and dedicated microprocessors, as well as one or more processors of any type of digital computer. Generally, the processor will read instructions and data from read-only memory and / or random access memory. An essential element of a computer is a processor that executes instructions and one or more memory devices that store instructions and data. In general, a computer also includes or includes one or more mass storage devices for storing data, such as magnetic, optical magnetic disks, or optical discs, or data from one or more mass storage devices. It will be operably combined for reception and / or transfer of data to it. However, the computer does not have to have such a device. Computer-readable media suitable for storing computer program instructions and data include, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; optical magnetic disks; It also includes all types of non-volatile memory, media and memory devices, including CDROMs and DVD-ROM discs. Processors and memory can be enhanced or incorporated into dedicated logic circuits.

The present specification contains a number of details, but they are not limited to the scope of any object or may be claimed, but rather may be specific to a particular embodiment of a particular technique. Should be interpreted as an explanation for. The particular features described herein in relation to separate embodiments can also be implemented in combination with a single embodiment. Conversely, the various features described in relation to a single embodiment can also be implemented separately in multiple embodiments or in some suitable subcombination. Further, the features are previously described as operating in a particular combination, and even though they may be initially claimed as such, one or more features from the claimed combination are: In some cases, it is removable from the combination and the claimed combination may be directed to a sub-combination or a variant of the sub-combination.

Similarly, the movements are represented in the drawings in a particular order, which is in that particular order or sequential order in which such movements are shown in order to achieve the desired result. It should not be understood that it requires that it be performed or that all the actions represented are performed. Moreover, it should not be understood that the separation of various system components in the embodiments described herein requires such separation in all embodiments.

Only a few practices and examples have been described, and other practices, enhancements and modifications may be based on those described and exemplified in this patent document.

[Cross-reference of related applications]
Under applicable patent law and / or rules under the Paris Convention, the present application is in International Patent Application No. PCT / CN2019 / 077179, dated March 20, 2019, filed March 6, 2019. Priority and benefits to International Patent Application No. PCT / CN2019 / 0789939 filed and International Patent Application No. PCT / CN2019 / 07939 filed on March 24, 2019 will be claimed in a timely manner. For all purposes under US law, the entire disclosure of the above application is incorporated by reference as part of the disclosure of this application.

[Cross-reference of related applications]
This application is an international patent filed on March 6, 2020, claiming priority and its benefits to International Patent Application No. PCT / CN2019 / 077179 filed on March 6, 2019. This is the domestic transition of Application No. PCT / CN2020 / 078108. The entire disclosure of the above application is incorporated by reference as part of the disclosure of this application.

Claims (54)

It ’s a video processing method.
Coding information for the current block, in part, based on whether the conditions related to the size of the current block are met for the conversion between the current block of the video and the bitstream representation of the video. Steps to determine the mode in which is represented in the bitstream representation,
A method having a step of performing the transformation based on the determination. The coding information is signaled in the bitstream representation if the conditions are satisfied.
The method according to claim 1. The coding information is omitted in the bitstream representation if the conditions are satisfied.
The method according to claim 1. If the above conditions are met, at least one of the intra-block copy (IBC) coding tools or the inter-predictive coding tools will be disabled for the current block.
The method according to any one of claims 1 to 3. The coding information is omitted in the bitstream representation if the IBC coding tool and the interpredictive coding tool are disabled.
The method according to claim 4. The coding information is signaled in the bitstream representation when the IBC coding tool is enabled and the interpredictive coding tool is disabled.
The method according to claim 4. The coding information has an operation mode associated with an IBC coding tool and / or an interpredictive coding tool, the operation mode having at least a normal mode or a skip mode.
The method according to any one of claims 1 to 6. The coding information has an indicator indicating the use of the predictive mode associated with the coding tool.
The method according to any one of claims 1 to 7. The coding tool is not used when the coding information is omitted in the bitstream representation.
The method according to claim 8. The coding tool is used when the coding information is omitted in the bitstream representation.
The method according to claim 8. The coding tool has an intra-block copy (IBC) coding tool or an inter-predictive coding tool.
The method according to any one of claims 8 to 10. When the indicator is omitted in the bitstream representation, one or more indicators indicating one or more other coding tools are signaled in the bitstream representation.
The method according to any one of claims 8 to 11. The other one or more coding tools have at least an intra coding tool or a palette coding tool.
The method according to claim 12. The indicator distinguishes between an intermode and an intramode, and the one or more indicators include a first indicator indicating an IBC mode and a second indicator indicating a palette mode, which the interpredicting coding tool provides. Signaled in the bitstream representation when disabled and the IBC coding tool enabled.
The method according to claim 12. The coding information has a third indicator for skip mode, which is interskip mode or IBC skip mode.
The method according to any one of claims 1 to 14. The third indicator for the skip mode is signaled when the interpredictive coding tool is disabled but the IBC coding tool is enabled.
The method according to claim 15. The predictive mode is the IBC mode when the interpredictive coding tool is disabled and the IBC coding tool is enabled, even though the indicator indicating the use of the IBC mode is omitted in the bitstream representation. The skip mode is applicable to the current block.
The method according to claim 15 or 16. The coding information has a triangular mode.
The method according to any one of claims 1 to 17. The coding information has an inter-prediction direction.
The method according to any one of claims 1 to 18. The coding information is omitted in the bitstream representation when the current block is coded using a one-sided predictive coding tool.
19. The method of claim 19. The coding information includes an indicator indicating the use of the symmetric mode vector difference (SMVD) method.
The method according to any one of claims 1 to 20. If the conditions are met, the current block is set to be one-sided predicted despite the indicator indicating the use of the SMVD method in the bitstream representation.
21. The method of claim 21. Only List 0 or List 1 associated with the one-sided predictive coding tool is used in the motion compensation process when the indicator indicating the use of the SMVD method is excluded from the bitstream representation.
22. The method of claim 22. The condition indicates that the width of the current block is T1 and the height of the current block is T2, where T1 and T2 are positive integers.
The method according to any one of claims 1 to 23. The condition indicates that the width of the current block is T2, the height of the current block is T1, and T1 and T2 are positive integers. Any one of claims 1 to 23. The method described in. The condition indicates that the width of the current block is T1 and the height of the current block is T2 or less, and T1 and T2 are any one of claims 1 to 23, which are positive integers. The method described in the section. The condition indicates that the width of the current block is T2, the height of the current block is T1 or less, and T1 and T2 are any one of claims 1 to 23, which are positive integers. The method described in the section. The condition indicates that the width of the current block is T1 or less, the height of the current block is T2 or less, and T1 and T2 are positive integers.
The method according to any one of claims 1 to 23. The condition indicates that the width of the current block is T1 or greater, the height of the current block is T2 or greater, and T1 and T2 are positive integers.
The method according to any one of claims 1 to 23. The condition indicates that the width of the current block is T1 or greater, or the height of the current block is T2 or greater, where T1 and T2 are positive integers.
The method according to any one of claims 1 to 23. T1 = 4 and T2 = 16,
The method according to any one of claims 24 to 30. T1 = T2 = 8,
The method according to any one of claims 24 to 30. T1 = 8 and T2 = 4,
The method according to any one of claims 24 to 30. T1 = T2 = 4,
The method according to any one of claims 24 to 30. T1 = T2 = 32,
The method according to any one of claims 24 to 30. T1 = T2 = 64,
The method according to any one of claims 24 to 30. T1 = T2 = 128,
The method according to any one of claims 24 to 30. The condition indicates that the current block has a size of 4x8, 8x4, 4x16, or 16x4.
The method according to any one of claims 1 to 37. The conditions indicate that the current block has a size of 4x8, 8x4.
The method according to any one of claims 1 to 37. The condition indicates that the size of the current block is 4 × N or N × 4, where N is a positive integer and N ≦ 16.
The method according to any one of claims 1 to 37. The condition indicates that the size of the current block is 8 × N or N × 8, where N is a positive integer and N ≦ 16.
The method according to any one of claims 1 to 37. The condition indicates that the color component of the current block contains N or less samples.
The method according to any one of claims 1 to 37. N = 16,
42. The method of claim 42. N = 32,
42. The method of claim 42. The condition indicates that the color component of the current block has a width equal to the height.
The method according to any one of claims 1 to 44. The condition indicates that the color component of the current block has a size of 4x8, 8x4, 4x4, 4x16, or 16x4.
The method according to any one of claims 1 to 44. The color component has a luma component or one or more chroma components.
The method according to any one of claims 42 to 46. The inter-prediction tool is disabled if the conditions indicate that the current block has a width of 4 and a height of 4.
The method according to any one of claims 1 to 47. The IBC prediction tool is disabled if the conditions indicate that the current block has a width of 4 and a height of 4.
The method according to any one of claims 1 to 48. Listing 0 related to the one-sided predictive coding tool shows that (1) the current block has a width of 4 and a height of 8 or (2) the current block has a width of 8 and a height of 4. If used in the motion compensation process, the bi-predictive coding tool will be disabled in the motion compensation process, if any.
The method according to any one of claims 1 to 49. The step of performing the conversion comprises generating the bitstream representation based on the current block of the video.
The method according to any one or more of claims 1 to 50. The step of performing the conversion comprises generating the current block of the video from the bitstream representation.
The method according to any one or more of claims 1 to 50. A video processing device having a processor configured to perform the method according to any one of claims 1 to 52. A computer-readable medium that stores code that, when executed by a processor, causes the processor to implement the method of any one of claims 1-52.

Images