bv list construction process for ica blocks in merge estimation region

Abstract

A BV list construction process for IBC blocks under merge estimation regions is described. An example method of video processing includes, for a conversion between a current video block of a video and a bitstream of the video, determining one or more block vector (BV) candidates for the current video block based on a merge estimation region (MER) covering the current video block, adding the one or more BV candidates to a BV list associated with the current video block, and performing the conversion based on the BV list.

Description

[0001] Cross-references to related applications

[0002] This application is filed in accordance with the applicable Patent Law and / or the Paris Convention to promptly claim priority and benefits to International Patent Application No. PCT / CN2020 / 074485, filed on February 7, 2020; International Patent Application No. PCT / CN2020 / 082125, filed on March 30, 2020; and International Patent Application No. PCT / CN2020 / 084298, filed on April 10, 2020. The entire disclosure of International Patent Application Nos. PCT / CN2020 / 074485, PCT / CN2020 / 082125, and PCT / CN2020 / 084298 is incorporated herein by reference as part of the disclosure of this application.

[0003] Technology is approaching

[0004] This patent document relates to image and video encoding and decoding. Background Technology

[0005] Digital video accounts for the largest share of bandwidth usage on the Internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video is expected to continue to grow. Summary of the Invention

[0006] This document discloses techniques that can be used by video encoders and decoders for video processing, using block vector (BV) lists for intra-frame block encoding and decoding in video processing.

[0007] In one example aspect, a video processing method is disclosed. The method includes: for a video region, a conversion between video blocks and a codec representation of the video; maintaining a list of block vector (BV) candidates based on a selection rule that selectively specifies included candidates based on merge estimated regions (MERs) of the video blocks; and performing the conversion based on the list of BV candidates.

[0008] In another example, a video processing method is disclosed. The method includes: determining a conversion between video blocks and the video's codec representation; and processing a candidate list based on block vector history, which follows the rule that the list is not updated if the video block is in a merge estimation region (MER) in the first case, or if the list has already been updated once within the MER in the second case.

[0009] In another example, a video processing method is disclosed. The method includes: a transformation between video blocks and a codec representation of the video; maintaining a list of motion candidates; selectively adding candidates of neighboring blocks from the merge estimated region (MER) of the video blocks to the list based on rules; and performing the transformation based on the list of motion candidates.

[0010] In another example, a video processing method is disclosed. This method includes: a transformation between video blocks and a codec representation of the video; maintaining a list of motion candidates, the size of which depends on whether the video blocks are below the merge estimation region (MER) according to a size rule; and performing the transformation based on the list of motion candidates.

[0011] In another example, a video processing method is disclosed. This method includes: determining the position of a video block relative to a corresponding merge estimation region, and performing a conversion between the video block and the video's codec representation by selecting a motion list construction process based on rules dependent on that position.

[0012] In another example, a video processing method is disclosed. The method includes: determining the characteristics of a merge estimation region for a video block, and performing a conversion between the video block and the codec representation of the video, wherein the tree partitioning pattern used during the conversion depends on the characteristics according to a rule.

[0013] In another example, a video processing method is disclosed. The method includes: for a conversion between a current video block and a bitstream of the video, determining one or more block vector (BV) candidates for the current video block based on a merge estimation region (MER) covering the current video block; adding the one or more BV candidates to a BV list associated with the current video block; and performing a conversion based on the BV list.

[0014] In another example, a video processing method is disclosed. The method includes: for a conversion between a current video block and a bitstream of the video, during a motion candidate list construction process, determining one or more motion candidates for the current video block based on a merge estimation region (MER) covering the current video block; during the motion candidate list construction process, adding one or more motion candidates to a motion candidate list associated with the current video block; and performing a conversion based on the motion candidate list.

[0015] In another example, a video processing method is disclosed. The method includes: for a conversion between a current video block and a bitstream of the video, determining one or more canonical constraints on a binary tree (BT) and / or ternary tree (TT) partition based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps with the MER; and performing the conversion based on the one or more canonical constraints.

[0016] In another example, a method for storing a bitstream of video is disclosed. The method includes: for the conversion between a current video block and a bitstream of video, during a motion candidate list construction process, determining one or more motion candidates for the current video block based on a merge estimation region (MER) covering the current video block; during the motion candidate list construction process, adding one or more motion candidates to a motion candidate list associated with the current video block; generating a bitstream from the current video block based on the motion candidate list; and storing the bitstream in a non-transitory computer-readable recording medium.

[0017] In yet another example, a video encoder apparatus is disclosed. The video encoder includes a processor configured to implement the methods described above.

[0018] In yet another example, a video decoder apparatus is disclosed. The video decoder includes a processor configured to implement the methods described above.

[0019] In yet another example, a computer-readable medium on which code is stored is disclosed. This code embodies one of the methods described herein in the form of processor-executable code.

[0020] These and other features are described throughout this document. Attached Figure Description

[0021] Figure 1 The derivation process for constructing the merge candidate list is shown.

[0022] Figure 2 The location of the spatial merge candidate is displayed.

[0023] Figure 3 Candidate pairs are shown that are considered for redundancy checks for spatial merge candidates.

[0024] Figure 4 An example encoding / decoding of the color palette is shown, with example locations of the second PU divided into N×2N and 2N×N segments.

[0025] Figure 5 A diagram illustrating the scaling of motion vectors for temporal merge candidates.

[0026] Figure 6 An example of the candidate positions for temporal merge candidates C0 and C1 is shown.

[0027] Figure 7 An example of combining bidirectional prediction merge candidates is shown.

[0028] Figure 8 An example of the derivation process for motion vector prediction candidates is shown.

[0029] Figure 9 A diagram illustrating the scaling of motion vectors for candidates of spatial motion vectors.

[0030] Figures 10A-10B A simplified affine model is shown; a 4-parameter affine model ( Figure 10A ) and 6-parameter affine model ( Figure 10B ).

[0031] Figure 11 An example of an affine MVF for each sub-block is shown.

[0032] Figure 12 Examples of candidate positions for the affine merge pattern are shown.

[0033] Figure 13 An example of the modified merge list construction process is shown.

[0034] Figure 14 An example of inter-frame prediction based on triangle segmentation is shown.

[0035] Figure 15 An example of applying the first weighting factor group to CU is shown.

[0036] Figure 16 An example of motion vector storage is shown.

[0037] Figure 17 An example of the UMVE search process is shown.

[0038] Figure 18 An example of a UMVE search point is shown.

[0039] Figure 19 An example of MVD(0,1) mirrored between list 0 and list 1 in DMVR is shown.

[0040] Figure 20 An example of an MV that can be examined in a single iteration is shown.

[0041] Figure 21 A diagram illustrating intra-frame block copying.

[0042] Figure 22 This is a diagram of MER.

[0043] Figure 23 This is a diagram of the neighboring blocks in the MER spatial domain.

[0044] Figure 24 This shows an example of a neighboring block in the MER airspace at a fixed location.

[0045] Figure 25 This shows an example of a MER spatial neighboring block at an adaptive location within a block.

[0046] Figure 26 Examples of MER spatial neighboring blocks at adaptive positions in different blocks are shown.

[0047] Figure 27 This is a block diagram of an example video processing system.

[0048] Figure 28 This is a block diagram of a video processing device.

[0049] Figure 29 A flowchart of an example method for video processing.

[0050] Figure 30 This is a block diagram illustrating a video encoding / decoding system according to some embodiments of the present disclosure.

[0051] Figure 31 This is a block diagram illustrating an encoder according to some embodiments of the present disclosure.

[0052] Figure 32 This is a block diagram illustrating a decoder according to some embodiments of the present disclosure.

[0053] Figure 33 Examples of different block locations within a MER are shown.

[0054] Figure 34 A flowchart of an example method for video processing.

[0055] Figure 35 A flowchart of an example method for video processing.

[0056] Figure 36 A flowchart of an example method for video processing.

[0057] Figure 37 A flowchart of an example method for video processing. Detailed Implementation

[0058] The use of chapter headings in this document is for ease of understanding and does not limit the applicability of the techniques and embodiments disclosed in each chapter to that chapter only. Furthermore, the use of H.266 terminology in some descriptions is merely for ease of understanding and not to limit the scope of the disclosed techniques. Therefore, the techniques described herein are also applicable to other video codec protocols and designs.

[0059] 1. Summary

[0060] This document relates to video codec technologies. Specifically, it covers inter-frame coding and intra-block copy (IBC) coding, where a reference (or predicted) block is obtained from samples in the current frame. It can be applied to existing video codec standards, such as HEVC, or the finalized standard (Multi-Functional Video Codec). It can also be applied to future video codec standards or codecs.

[0061] 2. Preliminary Discussion

[0062] Video codec standards have primarily evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T developed the H.261 and H.263 standards, while ISO / IEC developed the MPEG-1 and MPEG-4 Visual standards. The two organizations jointly developed the H.262 / MPEG-2 video standard, the H.264 / MPEG-4 Advanced Video Coding (AVC) standard, and the H.265 / HEVC standard. Starting with H.262, video codec standards are based on a hybrid video codec architecture, utilizing temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, the Joint Video Exploration Team (JVET) was jointly established by VCEG and MPEG in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Expert Team (JVET) was established between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) to work on the VVC standard, with the goal of reducing the bit rate by 50% compared to HEVC.

[0063] 2.1 Inter-frame prediction in HEVC / H.265

[0064] For inter-frame encoding / decoding, a coding unit (CU) can be encoded / decoded using one prediction unit (PU) or two PUs, depending on the segmentation mode. Each inter-frame prediction PU has motion parameters for one or two lists of reference images. The motion parameters include motion vectors and reference image indices. The use of one of the two lists of reference images can also be notified using inter_pred_idc signaling. The motion vectors can be explicitly encoded / decoded as increments relative to the predictors.

[0065] When a CU encodes and decodes using skip mode, a PU is associated with the CU, and there are no significant residual coefficients, no encoding / decoding motion vector increments, or no reference picture indexes. A Merge mode is specified, which obtains the motion parameters of the current PU from neighboring PUs, including spatial and temporal candidates. The Merge mode can be applied to any inter-frame prediction PU, not just skip mode. An alternative to the Merge mode is explicit transmission of motion parameters, where the motion vector (more precisely, the motion vector difference (MVD) compared to the motion vector predictor) is explicitly signaled for each PU, along with the corresponding reference picture index and the usage of the reference picture list for each PU. Such a mode is referred to in this disclosure as Advanced Motion Vector Prediction (AMVP).

[0066] When a signaling notification indicates that one of two lists of reference images should be used, a PU is generated from a block of samples. This is called 'one-way prediction'. One-way prediction is available for both P-strips and B-strips.

[0067] When signaling indicates that a list of reference images should be used, two blocks of samples are generated for PU (Programmable Components). This is called 'bidirectional prediction'. Bidirectional prediction is only available for B-strips.

[0068] The following text provides details about the inter-frame prediction modes specified in HEVC. The description will begin with merge mode.

[0069] 2.2.1 List of Reference Images

[0070] In HEVC, the term inter-frame prediction is used to refer to predictions derived from data elements (e.g., sample values ​​or motion vectors) of a reference image rather than the currently decoded image. As in H.264 / AVC, images can be predicted from multiple reference images. The reference images used for inter-frame prediction are organized into one or more reference image lists. A reference index identifies which of the reference images in the list should be used to create the prediction signaling.

[0071] A single list of reference images (list 0) is used for the P-strip, and two lists of reference images (list 0 and list 1) are used for the B-strip. It should be noted that, in terms of capture / display order, the reference images included in lists 0 and 1 can be images from the past and future.

[0072] 2.1.2 Merge Mode

[0073] 2.1.2.1 Derivation of Merge Pattern Candidates

[0074] When predicting a PU using the merge mode, the indexes pointing to entries in the merge candidate list are parsed from the bitstream and used to retrieve motion information. The construction of this list is specified in the HEVC standard and can be generalized according to a sequence of the following steps:

[0075] Step 1: Initial Candidate Derivation

[0076] Step 1.1: Spatial Candidate Derivation

[0077] Step 1.2: Redundancy check of airspace candidates

[0078] Step 1.3: Time-domain candidate derivation

[0079] Step 2: Adding candidate insertions

[0080] Step 2.1: Creation of bidirectional prediction candidates

[0081] Step 2.2: Insertion of zero-motion candidates

[0082] These steps are still ongoing. Figure 1 The diagram illustrates the process. For spatial merge candidate derivation, up to four merge candidates are selected from candidates located in five distinct positions. For temporal merge candidate derivation, up to one merge candidate is selected from two candidates. Since a constant number of candidates is assumed for each PU at the decoder, additional candidates are generated when the number of candidates obtained from step 1 is less than the maximum number of merge candidates (MaxNumMergeCand) signaled in the stripe header. Because the number of candidates is constant, the index of the best merge candidate is encoded using truncated unigram binarization (TU). If the CU size is equal to 8, all PUs of the current CU share a single merge candidate list, which is identical to the merge candidate list of a 2N×2N prediction unit.

[0083] The operations associated with the foregoing steps are described in detail below.

[0084] 2.1.2.2 Derivation of Airspace Candidates

[0085] In the derivation of spatial merge candidates, in the location of Figure 2 At most four merge candidates are selected from the candidates at the positions depicted. The derivation order is left (A1), top (B1), top right (B0), bottom left (A0), and top left (B2). Position B2 is considered only if any PU at positions A1, B1, B0, or A0 is unavailable (e.g., because it belongs to another stripe or slice) or if it is intra-frame encoding / decoding. After adding a candidate at position A1, the addition of other candidates undergoes a redundancy check, which ensures that candidates with the same motion information are excluded from the list, thus improving encoding / decoding efficiency. To reduce computational complexity, not all possible candidate pairs are considered in the redundancy check mentioned above. Conversely, only those with... Figure 3 Pairs linked by arrows are considered, and a candidate is added to the list only if the corresponding candidate used for redundancy checking does not have the same motion information. Another source of duplicate motion information is a "second PU" associated with a segmentation other than 2Nx2N. As an example, Figure 4 The second prediction units (PUs) are described for N×2N and 2N×N scenarios, respectively. When the current PU is segmented into N×2N, the candidate at position A1 is not considered in the list construction. In fact, adding this candidate would result in two prediction units having the same motion information, which is redundant for an encoding / decoding unit with only one PU. Similarly, when the current PU is segmented into 2N×N, position B1 is not considered.

[0086] 2.1.2.3 Time-domain candidate derivation

[0087] In this step, only one candidate is added to the list. Specifically, when deriving this temporal merge candidate, the scaling motion vector is derived based on the co-located PU in the co-located image. The scaling motion vector of the temporal merge candidate is as follows: Figure 5 As shown by the dashed lines, the motion vectors from the co-located PU are scaled using the POC distances (tb and td), where tb is defined as the POC difference between the current image and its reference image, and td is defined as the POC difference between the co-located image and its reference image. The reference image index for the temporal merge candidate is set to zero. The actual implementation of the scaling process is described in the HEVC specification. For B-strips, two motion vectors are obtained and combined to perform bidirectional prediction of merge candidates, one for reference image list 0 and the other for reference image list 1.

[0088] Figure 5 A diagram illustrating the scaling of motion vectors for temporal merge candidates.

[0089] 2.1.2.4 Co-located images and co-located PUs

[0090] When TMVP is enabled (i.e., slice_temporal_mvp_enabled_flag equals 1), the variable ColPic representing the co-bit image is deduced as follows:

[0091] – If the current stripe is a B stripe and the collocated_from_l0_flag of the signaling notification is equal to 0, then ColPic is set to equal to RefPicList1[collocated_ref_idx].

[0092] Otherwise (slice_type equals B and collocated_from_l0_flag equals 1, or slice_type equals P), ColPic is set to equal RefPicList0[collocated_ref_idx].

[0093] The collocated_ref_idx and collocated_from_l0_flag are two syntax elements that can be signaled in the stripe header.

[0094] In the co-occurrence PU(Y) of the reference frame, the position of the temporal candidate is selected between candidate C0 and C1, such as... Figure 6 As shown in the diagram. If the PU at position C0 is unavailable, is intra-coded, or is outside the current codec tree unit (CTU, also known as LCU, maximum codec unit) row, then position C1 is used. Otherwise, position C0 is used in the derivation of the temporal merge candidate.

[0095] The relevant syntax elements are described below:

[0096] 7.3.6.1 General Striped Segment Header Syntax

[0097]

[0098] 2.1.2.5 Derivation of the MV of TMVP Candidates

[0099] More specifically, the following steps are performed to derive TMVP candidates:

[0100] 1) Set the reference image list X = 0, and the target reference image is the reference image in list X with an index equal to 0 (i.e., curr_ref). Call the derivation process of the co-positional motion vector to obtain the MV of list X pointing to curr_ref.

[0101] 2) If the current strip is a B strip, then set the reference image list X = 1, and the target reference image is the reference image with an index equal to 0 in list X (i.e., curr_ref). Call the derivation process of the co-position motion vector to obtain the MV of list X pointing to curr_ref.

[0102] The following subsection 2.1.2.5.1 describes the derivation of the co-positional motion vector.

[0103] 2.1.2.5.1 Derivation of the co-positional motion vector

[0104] For co-occurring blocks, intra-frame or inter-frame coding / decoding can be performed using either one-way or two-way prediction. If it is intra-frame coded / decoded, the TMVP candidate is set to unavailable.

[0105] If it is a one-way prediction from list A, then the motion vector of list A is scaled to the target reference image list X.

[0106] If it is a bidirectional prediction and the list of target reference images is X, then the motion vectors of list A are scaled to the list of target reference images X, and A is determined according to the following rules:

[0107] – If there is no reference image with a larger POC value compared to the current image, then A is set to equal X.

[0108] Otherwise, A is set to equal collocated_from_l0_flag.

[0109] The relevant draft working document in JCTVC-W1005-v4 is described as follows:

[0110] 8.5.3.2.9 Derivation of the co-positional motion vector

[0111] The input to this process is:

[0112] – The variable currPb specifies the current prediction block.

[0113] – The variable colPb specifies the co-position prediction block within the co-position image specified by ColPic.

[0114] – Luminance position (xColPb, yColPb), relative to the top-left luminance sample of the co-position image specified by ColPic, and the top-left sample of the co-position luminance prediction block specified by colPb.

[0115] – Refer to the index refIdxLX, where X is 0 or 1.

[0116] The output of this process is:

[0117] – Motion vector prediction mvLXCol,

[0118] –Availability flag: availableFlagLXCol.

[0119] The variable currPic specifies the current image.

[0120] The arrays predFlagL0Col[x][y], mvL0Col[x][y], and refIdxL0Col[x][y] are set to be equal to the co-bit images PredFlagL0[x][y], MvL0[x][y], and RefIdxL0[x][y] specified by ColPic, respectively, and the arrays predFlagL1Col[x][y], mvL1Col[x][y], and refIdxL1Col[x][y] are set to be equal to the co-bit images PredFlagL1[x][y], MvL1[x][y], and RefIdxL1[x][y] specified by ColPic, respectively.

[0121] The derivation of variables mvLXCol and availableFlagLXCol is as follows:

[0122] – If colPb is encoded and decoded in intra-prediction mode, then both components of mvLXCol are set to 0, and availableFlagLXCol is set to 0.

[0123] Otherwise, the motion vector mvCol, the reference index refIdxCol, and the reference list identifier listCol are derived as follows:

[0124] – If predFlagL0Col[xColPb][yColPb] equals 0, then mvCol, refIdxCol, and listCol are set to equal to mvL1Col[xColPb][yColPb], refIdxL1Col[xColPb][yColPb], and L1, respectively.

[0125] Otherwise, if predFlagL0Col[xColPb][yColPb] equals 1 and predFlagL1Col[xColPb][yColPb] equals 0, then mvCol, refIdxCol, and listCol are set to equal mvL0Col[xColPb][yColPb], refIdxL0Col[xColPb][yColPb], and L0, respectively.

[0126] Otherwise (predFlagL0Col[xColPb][yColPb] equals 1 and predFlagL1Col[xColPb][yColPb] equals 1), perform the following allocation:

[0127] – If NoBackwardPredFlag equals 1, then mvCol, refIdxCol, and listCol are set to mvLXCol[xColPb][yColPb], refIdxLXCol[xColPb][yColPb], and LX, respectively.

[0128] Otherwise, mvCol, refIdxCol, and listCol are set to equal mvLNCol[xColPb][yColPb], refIdxLNCol[xColPb][yColPb], and LN, respectively, where N is the value of collocated_from_l0_flag.

[0129] Furthermore, the derivation of mvLXCol and availableFlagLXCol is as follows:

[0130] – If LongTermRefPic(currPic, currPb, refIdxLX, LX) is not equal to LongTermRefPic(ColPic, colPb, refIdxCol, listCol), then both components of mvLXCol are set to 0 and availableFlagLXCol is set to 0.

[0131] Otherwise, the variable availableFlagLXCol is set to 1, refPicListCol[refIdxCol] is set to the image with reference index refIdxCol in the list of reference images listCol containing the band of the predicted block colPb in the co-occurring image specified by ColPic, and the following applies:

[0132] colPocDiff=DiffPicOrderCnt(ColPic,refPicListCol[refIdxCol]) (2-1)

[0133] currPocDiff=DiffPicOrderCnt(currPic,RefPicListX[refIdxLX]) (2-2)

[0134] – If RefPicListX[refIdxLX] is a long-term reference image, or colPocDiff equals currPocDiff, then mvLXCol is derived as follows:

[0135] mvLXCol=mvCol (2-3)

[0136] Otherwise, mvLXCol is derived as a scaled version of the motion vector mvCol as follows:

[0137] tx=(16384+(Abs(td)>>1)) / td (2-4)

[0138] distScaleFactor=Clip3(-4096,4095,(tb*tx+32)>>6) (2-5)

[0139] mvLXCol=Clip3(-32768,32767,Sign(distScaleFactor*mvCol)*((Abs(distScaleFactor*mvCol)+127)>>8)) (2-6)

[0140] The derivation of td and tb is as follows:

[0141] td=Clip3(-128,127,colPocDiff) (2-7)

[0142] tb=Clip3(-128,127,currPocDiff) (2-8)

[0143] The definition of NoBackwardPredFlag is:

[0144] The variable NoBackwardPredFlag is derived as follows:

[0145] – If DiffPicOrderCnt(aPic, CurrPic) is less than or equal to 0 for each image aPic in RefPicList0 or RefPicList1 of the current strip, then NoBackwardPredFlag is set to 1.

[0146] Otherwise, NoBackwardPredFlag is set to 0.

[0147] 2.1.2.6 Additional Candidate Insertion

[0148] In addition to spatial and temporal merge candidates, two additional types of merge candidates exist: combined bidirectional prediction merge candidates and zero merge candidates. Combined bidirectional prediction merge candidates are generated by utilizing spatial and temporal merge candidates. Combined bidirectional prediction merge candidates are only used for B-strips. Combined bidirectional prediction candidates are generated by combining the motion parameters of the first reference image list of the initial candidate with the motion parameters of the second reference image list of another candidate. If the two tuples provide different motion hypotheses, they will form a new bidirectional prediction candidate. As an example, Figure 7 The case where two candidates (with mvL0 and refIdxL0, or mvL1 and refIdxL1) in the original list (left side) are used to create combined bidirectional prediction merge candidates that are added to the final list (right side). There are many rules regarding the combinations considered to generate these additional merge candidates, defined in [1].

[0149] Figure 7 An example of combining bidirectional prediction merge candidates is shown.

[0150] Zero-motion candidates are inserted to populate the remaining entries in the merge candidate list, thus reaching the MaxNumMergeCand capacity. These candidates have zero spatial shifts and a reference image index that starts at zero and increases each time a new zero-motion candidate is added to the list. Finally, no redundancy checks are performed on these candidates.

[0151] 2.1.3 AMVP

[0152] AMVP utilizes the spatial-temporal association of motion vectors with neighboring PUs, which is used for the explicit transmission of motion parameters. For each list of reference images, a candidate list of motion vectors is constructed as follows: first, the availability of neighboring PU locations in the left and top temporal domains is checked, redundant candidates are removed, and zero vectors are added to make the candidate list a constant length. The encoder can then select the best predictor from the candidate list and transmit the corresponding index indicating the selected candidate. Similar to merge index signaling, a truncated unary code is used to encode the index of the best motion vector candidate. In this case, the maximum value encoded is 2 (see...). Figure 8 The following sections provide details of the derivation process for the motion vector prediction candidates.

[0153] 2.1.3.1 Derivation of AMVP Candidates

[0154] Figure 8 The derivation process of motion vector prediction candidates is summarized.

[0155] In motion vector prediction, two types of motion vector candidates are considered: spatial motion vector candidates and temporal motion vector candidates. The derivation of spatial motion vector candidates is based on, for example... Figure 2 The motion vectors of each PU located in five different positions are shown, and two motion vector candidates are finally derived.

[0156] For temporal motion vector candidate derivation, one motion vector candidate is selected from two candidates derived based on two different co-located positions. After generating a first list of space-time candidates, duplicate motion vector candidates in the list are removed. If the number of potential candidates is greater than two, motion vector candidates with a reference image index greater than 1 in the associated reference image list are removed from the list. If the number of space-time motion vector candidates is less than two, an additional zero motion vector candidate is added to the list.

[0157] 2.1.3.2 Candidate Spatial Motion Vectors

[0158] In the derivation of the spatial motion vector candidates, at most two candidates are considered from five potential candidates, which are derived from the five candidates located at... Figure 2 The positions shown are derived from the PU, and these positions are the same as those merged into the motion vector. The derivation order for the left side of the current PU is defined as A0, A1, and scaled A0, scaled A1. The derivation order for the upper side of the current PU is defined as B0, B1, B2, scaled B0, scaled B1, scaled B2. Therefore, there are four cases that can be used as motion vector candidates for each side, two of which do not require spatial scaling, and two of which do. The four different cases are summarized below.

[0159] • No spatial scaling

[0160] –(1) A list of identical reference images, and the same reference image index (same POC)

[0161] –(2) Different lists of reference images, but with the same reference image (same POC)

[0162] • Spatial scaling

[0163] –(3) Same list of reference images, but different reference images (different POCs)

[0164] –(4) A list of different reference images, and different reference images (different POCs)

[0165] First, check for the case without spatial scaling, then check for spatial scaling. Spatial scaling is considered when the Proof of Concept (POC) between the reference image of a neighboring PU and the reference image of the current PU is different, regardless of the list of reference images. If all PUs of the left candidate are unavailable or intra-frame encoded / decoded, scaling of the upper motion vector is allowed to aid in the parallel derivation of the left and upper motion vectors. Otherwise, spatial scaling is not allowed for the upper motion vector.

[0166] During spatial scaling, the motion vectors of neighboring PUs are scaled in a manner similar to temporal scaling, such as... Figure 9 As shown. The main difference is that the current PU's list of reference images and indices are given as input; the actual scaling process is the same as the scaling process for temporal scaling.

[0167] 2.1.3.3 Candidate Motion Vectors in the Time Domain

[0168] Apart from the derivation of the reference image index, the entire process of deriving the temporal merge candidate and the process of deriving the spatial motion vector candidate are described in (see...). Figure 6 (Same as above.) The reference image index is signaled to the decoder.

[0169] 2.2 Inter-frame prediction methods in VVC

[0170] Several new codec tools exist for improving inter-frame prediction, such as Adaptive Motion Vector Difference Resolution (AMVR) for signaling notification MVD, Merge with Motion Vector Differences (MMVD), Triangular Prediction Mode (TPM), Combined Intra-Inter-Prediction (CIIP), Advanced TMVP (ATMVP, also known as SbTMVP), Affine Prediction Mode, Generalized Bi-Prediction (GBI), Decoder-Side Motion Vector Refinement (DMVR), and Bi-directional Optical Flow (BIO, also known as BDOF).

[0171] There are three different merge list construction processes supported in VVC:

[0172] 1) Sub-block merge candidate list: This list contains ATMVP and affine merge candidates. A merge list construction process is shared by both affine and ATMVP modes. Here, ATMVP and affine merge candidates can be added sequentially. The sub-block merge list size is signaled in the strip header, with a maximum value of 5.

[0173] 2) Regular merge list: For inter-frame codec blocks, a shared merge list construction process is used. Here, spatial / temporal merge candidates, HMVP, paired merge candidates, and zero-motion candidates can be inserted sequentially. The signaling in the stripe header informs the size of the regular merge list, with a maximum value of 6. MMVD, TPM, and CIIP rely on the regular merge list.

[0174] 3) IBC merge list: Performed in a similar manner to the regular merge list.

[0175] Similarly, there is a list of three AMVPs supported in VVC:

[0176] 1) Affine AMVP Candidate List

[0177] 2) Regular AMVP Candidate List

[0178] 3) IBC AMVP Candidate List: The same construction process as the IBC merge list.

[0179] 2.2.1 Codec Block Structure in VVC

[0180] In VVC, a quadtree / binary tree / ternary tree (QT / BT / TT) structure is used to divide the image into square or rectangular blocks.

[0181] In addition to QT / BT / TT, VVC also employs a split-tree (also known as a dual codec tree) for I-frames. In the case of a split-tree, the codec block structure is signaled separately for the luminance and chrominance components.

[0182] In addition, except for blocks encoded using several specific encoding / decoding methods (such as intra-frame sub-segmentation prediction, where PU equals TU but is less than CU; and inter-frame encoded / decoded sub-block transformation, where PU equals CU but TU is less than PU), CU is set to equal PU and TU.

[0183] 2.2.2 Affine Prediction Mode

[0184] In HEVC, only translational motion models are applied to motion compensation prediction (MCP). However, in the real world, many types of motion exist, such as zooming in / out, rotation, perspective motion, and other unconventional motions. In VVC, simplified affine transformation motion compensation prediction is applied using 4-parameter and 6-parameter affine models. Figures 10A-10B As shown, the affine motion field of the block for a 4-parameter affine model ( Figure 10A It is described by two control point motion vectors (CPMV), and for a 6-parameter affine model ( Figure 10B It is described by 3 CPMVs.

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

[0186]

[0187]

[0188] Where (mv h 0,mv h 0) is the motion vector of the top-left control point, and (mv h 1,mv h 1) is the motion vector of the upper right control point, and (mv h 2,mv h 2) is the motion vector of the lower left control point. All three motion vectors are called the control point motion vector (CPMV). (x, y) represents the coordinates of the representative point relative to the upper left sample point within the current block, and (mv h (x,y),mv v (x, y) is the motion vector derived from the sample located at (x, y). The CP motion vector can be signaled (e.g., in affine AMVP mode) or derived in real-time (e.g., in affine merge mode). w and h are the width and height of the current block. In practice, division is implemented through right shift and rounding operations. In VTM, the representative point is defined as the center position of the sub-block; for example, when the coordinates of the top-left corner of a sub-block relative to the top-left sample within the current block are (xs, ys), the coordinates of the representative point are defined as (xs+2, ys+2). For each sub-block (i.e., 4x4 in VTM), the representative point is used to derive the motion vector for the entire sub-block.

[0189] To further simplify motion compensation prediction, a sub-block-based affine transformation prediction is applied. To derive the motion vector for each M×N (where M and N are set to 4 in the current VVC) sub-block, the following calculations are performed according to equations (1) and (2): Figure 11 The motion vector of the center sample point of each sub-block is shown and rounded to 1 / 16 fractional accuracy. A 1 / 16 pixel motion-compensated interpolation filter is then used to generate the prediction for each sub-block using the derived motion vector. The 1 / 16 pixel interpolation filter is introduced by an affine pattern.

[0190] After MCP, the high-accuracy motion vector of each sub-block is rounded and saved with the same accuracy as the normal motion vector.

[0191] 2.2.3 MERGE of the entire block

[0192] 2.2.3.1 Constructing the merge list in the regular merge pattern

[0193] 2.2.3.1.1 History-based Motion Vector Prediction (HMVP)

[0194] Unlike the merge list design, VVC uses the history-based motion vector prediction (HMVP) method.

[0195] The HMVP stores motion information from previous encoding / decoding operations. Motion information from previously encoded / decoded blocks is defined as HMVP candidates. Multiple HMVP candidates are stored in a table called the HMVP table, which is maintained in real-time during the encoding / decoding process. When encoding / decoding a new slice / LCU line / strip begins, the HMVP table is cleared. As long as inter-frame encoded / decoded blocks and non-sub-block, non-TPM modes exist, the associated motion information is added to the last entry of the table as a new HMVP candidate. The overall encoding / decoding flow is as follows: Figure 12 Described in the text.

[0196] 2.2.3.1.2. Standard merge list construction process

[0197] The construction of a regular merge list (for translational motion) can be summarized according to the following sequence of steps:

[0198] Step 1: Derive airspace candidates

[0199] Step 2: Insert HMVP candidate

[0200] Step 3: Insert pairwise average candidates

[0201] Step 4: Default motion candidates

[0202] HMVP candidates can be used in both the AMVP and merge candidate list construction processes. Figure 13 The modified merge candidate list construction process is depicted (highlighted in blue). When the merge candidate list is not full after the insertion of TMVP candidates, HMVP candidates stored in the HMVP table can be used to populate the merge candidate list. Considering that a block is generally highly correlated with its nearest neighboring block in terms of motion information, HMVP candidates in the table are inserted in descending order of their indexes. The last entry in the table is added to the list first, and the first entry is added last. Similarly, redundancy removal is applied to HMVP candidates. Once the total number of available merge candidates reaches the maximum number of merge candidates allowed for signaling notification, the merge candidate list construction process terminates.

[0203] Note that all spatial / temporal / HMVP candidates should be encoded and decoded in non-IBC mode. Otherwise, they are not allowed to be added to the regular merge candidate list.

[0204] The HMVP table contains up to 5 regular sports candidates, and each of them is unique.

[0205] 2.2.3.1.2.1 Pruning process

[0206] A candidate is added to the list only if the corresponding candidate used for redundancy checking does not have the same motion information. This comparison process is called the pruning process.

[0207] The pruning process among the airspace candidates depends on the use of TPM for the current block.

[0208] When the current block is not encoded or decoded in TPM mode (e.g., regular merge, MMVD, CIIP), the spatial merge candidate is subjected to the HEVC pruning process (i.e., five-stage pruning).

[0209] 2.2.4 Triangular Prediction Mode (TPM)

[0210] In VVC, triangular splitting mode is supported for inter-frame prediction. Triangular splitting mode is only applied to CUs that are 8x8 or larger and are encoded / decoded in merge mode but not in MMVD or CIIP mode. For CUs that meet these conditions, signaling informs the CU level flag to indicate whether triangular splitting mode is applied.

[0211] When using this mode, the CU is evenly divided into two triangular segments, using either diagonal or anti-diagonal division, such as... Figure 14As shown. Each triangle segment in the CU is predicted inter-frame using its own motion; only unidirectional prediction is allowed for each segment, i.e., each segment has one motion vector and one reference index. Unidirectional prediction motion constraints are applied to ensure that, as with regular bidirectional prediction, each CU requires only two motion-compensated predictions.

[0212] If the CU-level flag indicates that the current CU is encoded and decoded using the triangular segmentation mode, further signaling informs a flag indicating the direction of the triangular segmentation (diagonal or anti-diagonal) and two merge indices (one for each segment). After predicting each of the triangular segments, a blending process with adaptive weights is used to adjust the sample values ​​along the diagonal or anti-diagonal edges. This is the prediction signaling for the entire CU, and the transform and quantization processes are applied to the entire CU as in other prediction modes. Finally, the motion field of the CU predicted using the triangular segmentation mode is stored in 4x4 cells.

[0213] The regular merge candidate list is repeatedly used for triangle segmentation merge prediction without additional motion vector pruning. For each merge candidate in the regular merge candidate list, one and only one of its L0 or L1 motion vectors is used for triangle prediction. Furthermore, the order of selection of L0 to L1 motion vectors is based on their merge index parity. In this scenario, the regular merge list can be used directly.

[0214] 2.2.4.1 TPM's merge list construction process

[0215] Basically, the standard merge list building process is applied as proposed. However, some modifications have been added.

[0216] Specifically, the following applies:

[0217] 1) How the pruning process is performed depends on the TPM used on the current block.

[0218] - If the current block is not encoded in TPM, invoke HEVC 5 pruning applied to the spatial merge candidate.

[0219] Otherwise (if the current block is encoded / decoded using TPM), when adding a new spatial merge candidate, full pruning is applied. That is, B1 is compared with A1; B0 is compared with A1 and B1; A0 is compared with A1, B1, and B0; and B2 is compared with A1, B1, A0, and B0.

[0220] 2) Whether to check motion information from B2 depends on the use of TPM for the current block.

[0221] - If the current block is not encoded in TPM, then B2 is accessed and checked only if there are fewer than 4 space merge candidates before checking B2.

[0222] Otherwise (if the current block is encoded in TPM), B2 is always accessed and checked, regardless of how many available space merge candidates are available before adding B2.

[0223] 2.2.4.2 Adaptive Weighting Process

[0224] After predicting each triangular prediction unit, an adaptive weighting process is applied to the diagonal edges between two triangular prediction units to derive the final prediction for the entire CU. The two sets of weighting factors are defined as follows:

[0225] ●The first weighting factor group: {7 / 8, 6 / 8, 4 / 8, 2 / 8, 1 / 8} and {7 / 8, 4 / 8, 1 / 8} were used for luminance and chrominance samples, respectively;

[0226] ●The second weighting factor group: {7 / 8, 6 / 8, 5 / 8, 4 / 8, 3 / 8, 2 / 8, 1 / 8} and {6 / 8, 4 / 8, 2 / 8} were used for luminance and chrominance samples, respectively.

[0227] The weighting factor group is selected based on the comparison of the motion vectors of the two triangular prediction units. The second weighting factor group is used when any of the following conditions are true:

[0228] – The reference images for the two triangular prediction units are different from each other.

[0229] – The absolute value of the difference between the horizontal values ​​of two motion vectors is greater than 16 pixels.

[0230] – The absolute value of the difference between the vertical values ​​of two motion vectors is greater than 16 pixels.

[0231] Otherwise, use the first weighted factor group. Figure 15 An example is shown in the image.

[0232] 2.2.4.3 Motion Vector Storage

[0233] The motion vector of the triangular prediction unit ( Figure 16 Mv1 and Mv2 in the CU are stored in a 4×4 grid. For each 4×4 grid, depending on the grid's position within the CU, either a unidirectional or bidirectional predicted motion vector is stored. Figure 16 As shown, unidirectional predicted motion vectors (Mv1 or Mv2) are stored in a 4×4 grid located in the unweighted region (i.e., not at the diagonal edge). Conversely, bidirectional predicted motion vectors are stored in a 4×4 grid located in the weighted region. The bidirectional predicted motion vectors are derived from Mv1 and Mv2 according to the following rules:

[0234] 1) When Mv1 and Mv2 have motion vectors from different directions (L0 or L1), Mv1 and Mv2 are simply combined to form a bidirectional predicted motion vector.

[0235] 2) When both Mv1 and Mv2 originate from the same L0 (or L1) direction,

[0236] – If the reference image for Mv2 is the same as an image in the L1 (or L0) reference image list, then Mv2 is scaled to that image. Mv1 and the scaled Mv2 are combined to form a bidirectional predicted motion vector.

[0237] – If the reference image for Mv1 is the same as an image in the L1 (or L0) reference image list, then Mv1 is scaled to that image. The scaled Mv1 and Mv2 are combined to form a bidirectional predicted motion vector.

[0238] Otherwise, only Mv1 is stored for the weighted region.

[0239] 2.2.4.4 The syntax, semantics, and decoding process of the Merge pattern

[0240] 7.3.5.1 General Strip Header Syntax

[0241]

[0242] 7.3.7.5 Encoding / Decoding Unit Syntax

[0243]

[0244]

[0245] 7.3.7.7 Merge Data Syntax

[0246]

[0247]

[0248] 7.4.6.1 General Strip Header Semantics

[0249] `six_minus_max_num_merge_cand` specifies 6 minus the maximum number of merge motion vector prediction (MVP) candidates supported in the strip. The maximum number of merge MVP candidates, `MaxNumMergeCand`, is derived as follows:

[0250] MaxNumMergeCand=6-six_minus_max_num_merge_cand (7-57)

[0251] The value of MaxNumMergeCand should be in the range of 1 to 6 (inclusive).

[0252] `five_minus_max_num_subblock_merge_cand` specifies 5 minus the maximum number of subblock-based merge motion vector prediction (MVP) candidates supported in the strip. When `five_minus_max_num_subblock_merge_cand` does not exist, it is inferred to be equal to 5 - `sps_sbtmvp_enabled_flag`. The maximum number of subblock-based merge MVP candidates, `MaxNumSubblockMergeCand`, is derived as follows:

[0253] MaxNumSubblockMergeCand=5-five_minus_max_num_subblock_merge_cand(7-58)

[0254] The value of MaxNumSubblockMergeCand should be in the range of 0 to 5 (inclusive).

[0255] 7.4.8.5 Semantics of Encoding / Decoding Units

[0256] When pred_mode_flag is equal to 0, it indicates that the current codec unit is encoded and decoded in inter-frame prediction mode. When pred_mode_flag is equal to 1, it indicates that the current codec unit is encoded and decoded in intra-frame prediction mode.

[0257] When pred_mode_flag does not exist, it is inferred as follows:

[0258] – If cbWidth equals 4 and cbHeight equals 4, then pred_mode_flag is inferred to be equal to 1.

[0259] Otherwise, pred_mode_flag is inferred to be equal to 1 when decoding I stripes and equal to 0 when decoding P or B stripes, respectively.

[0260] For x = x0..x0 + cbWidth – 1 and y = y0..y0 + cbHeight – 1, the variable CuPredMode[x][y] is derived as follows:

[0261] – If pred_mode_flag equals 0, CuPredMode[x][y] is set to equal MODE_INTER.

[0262] Otherwise (pred_mode_flag equals 1), CuPredMode[x][y] is set to equal MODE_INTRA.

[0263] When `pred_mode_ibc_flag` equals 1, it indicates that the current codec unit is encoded and decoded in IBC predictive mode. When `pred_mode_ibc_flag` equals 0, it indicates that the current codec unit is not encoded and decoded in IBC predictive mode.

[0264] When pred_mode_ibc_flag does not exist, it is inferred as follows:

[0265] – If cu_skip_flag[x0][y0] equals 1, and cbWidth equals 4, and cbHeight equals 4, then pred_mode_ibc_flag is inferred to be equal to 1.

[0266] Otherwise, if both cbWidth and cbHeight are equal to 128, then pred_mode_ibc_flag is inferred to be equal to 0.

[0267] Otherwise, pred_mode_ibc_flag is inferred to be equal to the value of sps_ibc_enabled_flag when decoding I-stripes and to be equal to 0 when decoding P- or B-stripes.

[0268] When pred_mode_ibc_flag equals 1, for x = x0..x0 + cbWidth – 1 and y = y0..y0 + cbHeight – 1, the variable CuPredMode[x][y] is set to equal MODE_IBC.

[0269] `general_merge_flag[x0][y0]` specifies whether the inter-frame prediction parameters of the current codec unit are inferred from the inter-frame prediction segments of neighboring frames. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0270] When general_merge_flag[x0][y0] does not exist, it is inferred as follows:

[0271] – If cu_skip_flag[x0][y0] equals 1, then general_merge_flag[x0][y0] is inferred to be equal to 1.

[0272] Otherwise, general_merge_flag[x0][y0] is inferred to be equal to 0.

[0273] mvp_l0_flag[x0][y0] specifies the motion vector predictor index of list 0, where x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0274] When mvp_l0_flag[x0][y0] does not exist, it is inferred to be equal to 0.

[0275] mvp_l1_flag[x0][y0] has the same semantics as mvp_l0_flag, where l0 and list 0 are replaced by l1 and list 1, respectively.

[0276] `inter_pred_idc[x0][y0]` specifies whether list 0, list 1, or bidirectional prediction is used in the current codec unit, according to Table 7-10. Array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0277] Table 7-10 – Name Associations for Inter-Frame Prediction Modes

[0278]

[0279] When inter_pred_idc[x0][y0] does not exist, it is inferred to be equal to PRED_L0.

[0280] 7.4.8.7 Merge Data Semantics

[0281] The regular_merge_flag[x0][y0] value being 1 indicates that the regular merge mode is used to generate the inter-frame prediction parameters for the current codec unit. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0282] When regular_merge_flag[x0][y0] does not exist, it is inferred as follows:

[0283] – If all of the following conditions are true, then regular_merge_flag[x0][y0] is inferred to be equal to 1:

[0284] –sps_mmvd_enabled_flag equals 0.

[0285] –general_merge_flag[x0][y0] equals 1.

[0286] –cbWidth*cbHeight equals 32.

[0287] Otherwise, regular_merge_flag[x0][y0] is inferred to be equal to 0.

[0288] mmvd_merge_flag[x0][y0] equals 1, specifying that the merge mode with motion vector difference is used to generate the inter-frame prediction parameters of the current codec unit. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0289] When mmvd_merge_flag[x0][y0] does not exist, it is inferred as follows:

[0290] – mmvd_merge_flag[x0][y0] is inferred to be equal to 1 if all of the following conditions are true:

[0291] –sps_mmvd_enabled_flag equals 1.

[0292] –general_merge_flag[x0][y0] equals 1.

[0293] –cbWidth*cbHeight equals 32.

[0294] –regular_merge_flag[x0][y0] equals 0.

[0295] Otherwise, mmvd_merge_flag[x0][y0] is inferred to be equal to 0.

[0296] mmvd_cand_flag[x0][y0] specifies whether to merge the first (0) or second (1) candidate in the candidate list, along with the motion vector difference derived from mmvd_distance_idx[x0][y0] and mmvd_direction_idx[x0][y0]. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0297] When mmvd_cand_flag[x0][y0] does not exist, it is inferred to be equal to 0.

[0298] mmvd_distance_idx[x0][y0] specifies the index used to derive MmvdDistance[x0][y0], as specified in Table 7-12. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0299] Table 7-12 – Specification of MmvdDistance[x0][y0] based on mmvd_distance_idx[x0][y0]

[0300]

[0301] mmvd_direction_idx[x0][y0] specifies the index used to derive MmvdSign[x0][y0], as specified in Table 7-13. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0302] Table 7-13 – Specification of MmvdSign[x0][y0] based on mmvd_direction_idx[x0][y0]

[0303] mmvd_direction_idx[x0][y0] MmvdSign[x0][y0][0] MmvdSign[x0][y0][1] 0 +1 0 1 -1 0 2 0 +1 3 0 -1

[0304] The derivation of Merge plus the two components of MVD offset MmvdOffset[x0][y0] is as follows:

[0305] MmvdOffset[x0][y0][0]=(MmvdDistance[x0][y0]<<2)*MmvdSign[x0][y0][0](7-124)

[0306] MmvdOffset[x0][y0][1]=(MmvdDistance[x0][y0]<<2)*MmvdSign[x0][y0][1](7-125)

[0307] `merge_subblock_flag[x0][y0]` specifies whether to infer the sub-block-based inter-frame prediction parameters of the current codec unit from neighboring blocks. Array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image. When `merge_subblock_flag[x0][y0]` does not exist, it is inferred to be equal to 0.

[0308] merge_subblock_idx[x0][y0] specifies the merge candidate index of the merge candidate list based on subblocks, where x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0309] When merge_subblock_idx[x0][y0] does not exist, it is inferred to be equal to 0.

[0310] ciip_flag[x0][y0] specifies whether to apply combined inter-frame merge and intra-frame prediction to the current codec unit. Array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0311] When ciip_flag[x0][y0] does not exist, it is inferred to be equal to 0.

[0312] When ciip_flag[x0][y0] equals 1, the variable IntraPredModeY[x][y] is set to equal INTRA_PLANAR, where x = xCb..xCb + cbWidth – 1 and y = yCb..yCb + cbHeight – 1.

[0313] The variable MergeTriangleFlag[x0][y0] (which specifies whether motion compensation based on the triangle shape is used to generate prediction samples for the current codec unit when decoding B stripes) is derived as follows:

[0314] – MergeTriangleFlag[x0][y0] is set to 1 if all of the following conditions are true:

[0315] –sps_triangle_enabled_flag equals 1.

[0316] –slice_type equals B.

[0317] –general_merge_flag[x0][y0] equals 1.

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

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

[0320] –regular_merge_flag[x0][y0] equals 0.

[0321] –mmvd_merge_flag[x0][y0] equals 0.

[0322] –merge_subblock_flag[x0][y0] equals 0.

[0323] –ciip_flag[x0][y0] equals 0.

[0324] Otherwise, MergeTriangleFlag[x0][y0] is set to 0.

[0325] `merge_triangle_split_dir[x0][y0]` specifies the direction of the merge triangle pattern. The array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0326] When merge_triangle_split_dir[x0][y0] does not exist, it is inferred to be equal to 0.

[0327] merge_triangle_idx0[x0][y0] specifies the first merge candidate index of the motion compensation candidate list based on the triangle shape, where x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0328] When merge_triangle_idx0[x0][y0] does not exist, it is inferred to be equal to 0.

[0329] merge_triangle_idx1[x0][y0] specifies the second merge candidate index of the motion compensation candidate list based on the triangle shape, where x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0330] When merge_triangle_idx1[x0][y0] does not exist, it is inferred to be equal to 0.

[0331] merge_idx[x0][y0] specifies the merge candidate index in the merge candidate list, where x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the considered codec block relative to the top-left luminance sample of the image.

[0332] When merge_idx[x0][y0] does not exist, it is inferred as follows:

[0333] – If mmvd_merge_flag[x0][y0] equals 1, then merge_idx[x0][y0] is inferred to be equal to mmvd_cand_flag[x0][y0].

[0334] Otherwise (mmvd_merge_flag[x0][y0] equals 0), merge_idx[x0][y0] is inferred to be equal to 0.

[0335] 2.2.4.4.1 Decoding process

[0336] The provided decoding process is defined as follows:

[0337] 8.5.2.2 Derivation of the Luminance Motion Vector in Merge Mode

[0338] This procedure is called only when general_merge_flag[xCb][yCb] equals 1, where (xCb, yCb) specifies the top-left sample of the current luminance codec block relative to the top-left luminance sample of the current image.

[0339] The input to this process is:

[0340] – The brightness position (xCb, yCb) of the current brightness codec block relative to the current top-left brightness sample of the current image.

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

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

[0343] The output of this process is:

[0344] The brightness motion vectors mvL0[0][0] and mvL1[0][0] with a fractional sample accuracy of -1 / 16.

[0345] –Refer to indices refIdxL0 and refIdxL1,

[0346] – The prediction list uses the flags predFlagL0[0][0] and predFlagL1[0][0].

[0347] – Bidirectional prediction weight index bcwIdx.

[0348] –Merge candidate list mergeCandList.

[0349] The bidirectional prediction weight index bcwIdx is set to 0.

[0350] The motion vectors mvL0[0][0] and mvL1[0][0], the reference indices refIdxL0 and refIdxL1, and the prediction utilization flags predFlagL0[0][0] and predFlagL1[0][0] are derived through the following sequential steps:

[0351] 1. Invoke the derivation process for spatial merge candidates from neighboring codec units as specified in Clause 8.5.2.3, taking the luma codec block position (xCb, yCb), luma codec block width cbWidth, and luma codec block height cbHeight as input, and outputting availability flags availableFlagA0, availableFlagA1, availableFlagB0, availableFlagB1, and availableFlagB2, referencing indexes refIdxLXA0, refIdxLXA1, and refIdxLXA2. 1. refIdxLXB0, refIdxLXB1 and refIdxLXB2, the prediction list utilizes the flags predFlagLXA0, predFlagLXA1, predFlagLXB0, predFlagLXB1 and predFlagLXB2, and the motion vectors mvLXA0, mvLXA1, mvLXB0, mvLXB1 and mvLXB2, where X is 0 or 1, and the bidirectional prediction weight indexes bcwIdxA0, bcwIdxA1, bcwIdxB0, bcwIdxB1, bcwIdxB2.

[0352] 2. The reference index refIdxLXCol, where X is 0 or 1, and the bidirectional prediction weight index bcwIdxCol of the temporal merge candidate Col are set to equal to 0.

[0353] 3. Invoke the derivation process for temporal luminance motion vector prediction as specified in Clause 8.5.2.11, taking the luminance position (xCb, yCb), luminance codec block width cbWidth, luminance codec block height cbHeight, and variable refIdxL0Col as input, and outputting the availability flag availableFlagL0Col and the temporal motion vector mvL0Col. The derivation of variables availableFlagCol, predFlagL0Col, and predFlagL1Col is as follows:

[0354] availableFlagCol=availableFlagL0Col (8-263)

[0355] predFlagL0Col=availableFlagL0Col (8-264)

[0356] predFlagL1Col=0 (8-265)

[0357] 4. When slice_type equals B, invoke the derivation process for temporal luminance motion vector prediction as specified in Clause 8.5.2.11, taking the luminance position (xCb, yCb), luminance codec block width cbWidth, luminance codec block height cbHeight, and variable refIdxL1Col as input, and outputting the availability flag availableFlagL1Col and the temporal motion vector mvL1Col. The derivation of variables availableFlagCol and predFlagL1Col is as follows:

[0358] availableFlagCol=availableFlagL0Col||availableFlagL1Col(8-266)

[0359] predFlagL1Col=availableFlagL1Col (8-267)

[0360] 5. The Merge candidate list mergeCandList is constructed as follows:

[0361]

[0362]

[0363] 6. The variables numCurrMergeCand and numOrigMergeCand are set to be equal to the number of Merge candidates in mergeCandList.

[0364] 7. When numCurrMergeCand is less than (MaxNumMergeCand-1) and NumHmvpCand is greater than 0, the following applies:

[0365] – Invoke the historical derivation process for merge candidates as specified in Clause 8.5.2.6, taking mergeCandList and numCurrMergeCand as inputs and the modified mergeCandList and numCurrMergeCand as outputs.

[0366] –numOrigMergeCand is set to be equal to numCurrMergeCand.

[0367] 8. When numCurrMergeCand is less than MaxNumMergeCand but greater than 1, the following applies:

[0368] – The derivation of the pairwise average merge candidates as specified in Clause 8.5.2.4 is invoked, taking mergeCandList, reference indices refIdxL0N and refIdxL1N, prediction list using flags predFlagL0N and predFlagL1N, motion vectors mvL0N and mvL1N for each candidate N in mergeCandList, and numCurrMergeCand as input, and the output is assigned to mergeCandList, numCurrMergeCand, reference indices refIdxL0avgCand and refIdxL1avgCand, prediction list using flags predFlagL0avgCand and predFlagL1avgCand, and motion vectors mvL0avgCand and mvL1avgCand of the candidate avgCand added to mergeCandList. The bidirectional prediction weight index bcwIdx of the candidate avgCand added to mergeCandList is set to 0.

[0369] –numOrigMergeCand is set to be equal to numCurrMergeCand.

[0370] 9. Invoke the derivation of the zero motion vector merge candidates as specified in Clause 8.5.2.5, taking mergeCandList, reference indices refIdxL0N and refIdxL1N, prediction list using flags predFlagL0N and predFlagL1N, motion vectors mvL0N and mvL1N for each candidate N in mergeCandList, and numCurrMergeCand as input, and assigning the output to mergeCandList, numCurrMergeCand, and reference index refIdxL0zeroCand. m and refIdxL1zeroCand m The prediction list uses the flags predFlagL0zeroCand m and predFlagL1zeroCand m and each new candidate zeroCand added to mergeCandList m Motion vector mvL0zeroCand m and mvL1zeroCand mEach new candidate zeroCand added to mergeCandList m The bidirectional prediction weight index bcwIdx is set to 0. The number of candidates added, numZeroMergeCand, is set to (numCurrMergeCand - numOrigMergeCand). When numZeroMergeCand is greater than 0, m ranges from 0 to numZeroMergeCand-1 (inclusive).

[0371] 10. Perform the following allocation, where N is the candidate at position merge_idx[xCb][yCb] in the merge candidate list mergeCandList (N = mergeCandList[merge_idx[xCb][yCb]]), and X is replaced with 0 or 1:

[0372] refIdxLX=refIdxLXN (8-269)

[0373] predFlagLX[0][0]=predFlagLXN (8-270)

[0374] mvLX[0][0][0]=mvLXN[0] (8-271)

[0375] mvLX[0][0][1]=mvLXN[1] (8-272)

[0376] bcwIdx=bcwIdxN (8-273)

[0377] 11. When mmvd_merge_flag[xCb][yCb] equals 1, the following applies:

[0378] – The derivation of the merge motion vector difference as specified in Clause 8.5.2.7 is invoked, with the brightness position (xCb, yCb), reference index refIdxL0, refIdxL1 and prediction list using flags predFlagL0[0][0] and predFlagL1[0][0] as input, and the motion vector difference mMvdL0 and mMvdL1 as output.

[0379] –For X to be 0 and 1, the motion vector difference mMvdLX is added to the Merge motion vector mvLX as follows:

[0380] mvLX[0][0][0]+=mMvdLX[0] (8-274)

[0381] mvLX[0][0][1]+=mMvdLX[1] (8-275)

[0382] mvLX[0][0][0]=Clip3(-2 17 ,2 17 -1,mvLX[0][0][0]) (8-276)

[0383] mvLX[0][0][1]=Clip3(-2 17 ,2 17 -1,mvLX[0][0][1]) (8-277)

[0384] 2.2.5 MMVD

[0385] The Ultimate Motion Vector Expression (UMVE, also known as MMVD) is presented. UMVE is used as a proposed motion vector expression method for skip or merge modes.

[0386] UMVE reuses the same merge candidates as the regular merge candidate list included in VVC. Among the merge candidates, a base candidate can be selected and further extended by the proposed motion vector representation method.

[0387] UMVE provides a new method for representing motion vector difference (MVD), in which the origin, motion amplitude, and motion direction are used to represent MVD.

[0388] Figure 17 An example of the UMVE search process is shown.

[0389] Figure 18 An example of a UMVE search point is shown.

[0390] The proposed technique uses the original merge candidate list. However, for the UMVE extension, only candidates of the default merge type (MRG_TYPE_DEFAULT_N) are considered.

[0391] The base candidate index defines the starting point. The base candidate index indicates the best candidate among the candidates in the following list.

[0392] Table 4. Basic Candidate IDX

[0393] Basic candidate IDX 0 1 2 3

[0014] N th MVP]]> <![CDATA[1 st MVP]]> <![CDATA[2 nd MVP]]> <![CDATA[3 rd MVP]]> <![CDATA[4 th MVP]]>

[0394] If the number of basic candidates is equal to 1, then the basic candidate IDX will not be notified by signaling.

[0395] The distance index is motion amplitude information. The distance index indicates a predefined distance from the starting point. The predefined distances are as follows:

[0396] Table 5. Distance from IDX

[0397]

[0398] The direction index represents the direction of MVD relative to the starting point. The direction index can represent four directions, as shown below.

[0399] Table 6. Directional IDX

[0400] Distance from IDX 00 01 10 11 x-axis + – N / A N / A y-axis N / A N / A + –

[0401] Immediately after sending the skip or merge flag, signal the UMVE flag. If the skip or merge flag is true, the UMVE flag is resolved. If the UMVE flag is equal to 1, the UMVE syntax is resolved. However, if it is not 1, the affine flag is resolved. If the affine flag is equal to 1, it is in affine mode; otherwise, the skip / merge index is resolved for the VTM's skip / merge mode.

[0402] No additional line buffer is needed due to UMVE candidates. The software's skip / merge candidates are used directly as the base candidates. The input UMVE index is used to determine the MV complement just before motion compensation. No long line buffer is needed for this.

[0403] Under the current normal testing conditions, the first or second merge candidate in the merge candidate list can be selected as the base candidate.

[0404] UMVE is also known as Merge with MV Differences (MMVD).

[0405] 2.2.6 Combined Intra-Inter-Frame Prediction (CIIP)

[0406] A multi-hypothesis prediction approach is proposed, in which combining intra-frame and inter-frame predictions is one way to generate multiple hypotheses.

[0407] When multi-hypothesis prediction is applied to improve intra-frame modes, it combines an intra-frame prediction with a merge index prediction. In the merge CU, a flag is signaled to the merge mode to select an intra-frame mode from the intra-frame candidate list when the flag is true. For the luma component, the intra-frame candidate list is derived from only one intra-frame prediction mode (i.e., planar mode). The weights applied to the prediction blocks from intra-frame and inter-frame predictions are determined by the encoding / decoding modes (intra-frame or non-intra-frame) of two neighboring blocks (A1 and B1).

[0408] 2.2.7 Merging based on sub-block technology

[0409] It is recommended to place motion candidates related to all sub-blocks into a separate merge list, in addition to the regular merge list of sub-block merge candidates.

[0410] Motion candidates related to sub-blocks are placed into a separate merge list called "Sub-block merge candidate list".

[0411] In one example, the list of sub-block merge candidates includes ATMVP candidates and affine merge candidates.

[0412] The candidate list for sub-block merge is populated with candidates in the following order:

[0413] a. ATMVP candidate (may be available or not);

[0414] b. Affine merge list (containing inherited affine candidates; and constructed affine candidates)

[0415] c. Zero-filled MV 4-parameter affine model

[0416] 2.2.7.1 ATMVP (also known as Sub-Block Temporal Motion Vector Predictor, SbTMVP)

[0417] The basic idea of ​​ATMVP is to derive multiple sets of temporal motion vector predictors for a block. Each sub-block is assigned a set of motion information. When generating ATMVP merge candidates, motion compensation is performed at the 8x8 level rather than at the entire block level.

[0418] In the current design, ATMVP predicts the motion vectors of sub-CUs within a CU in two steps, which are described in the following two subsections 2.2.7.1.1 and 2.2.7.1.2, respectively.

[0419] 2.2.7.1.1.1 Derivation of Initialization of Motion Vectors

[0420] The initial motion vector is represented by tempMv. When block A1 is available and it is not intra-frame encoded (i.e., encoded in inter-frame or IBC mode), the following is applied to derive the initial motion vector.

[0421] – If all of the following conditions are true, then tempMv is set to be equal to the motion vector of block A1 from list 1, denoted by mvL1A1:

[0422] – The reference image index for list 1 is available (not equal to -1) and it has the same POC value as the co-bit image (i.e., DiffPicOrderCnt(ColPic, RefPicList[1][refIdxL1A1]) equals 0).

[0423] – All reference images have a Proof of Concept (POC) that is not larger than the current image (i.e., DiffPicOrderCnt(aPic, currPic) for each image in the reference image list for the current strip, where aPic is less than or equal to 0).

[0424] –The current stripe is equal to stripe B.

[0425] –collocated_from_l0_flag equals 0.

[0426] Otherwise, if all of the following conditions are true, then tempMv is set to be equal to the motion vector of block A1 from list 0, denoted by mvL0A1:

[0427] – The reference image index for list 0 is available (not equal to -1).

[0428] – It has the same POC value as the co-positioned image (i.e., DiffPicOrderCnt(ColPic,RefPicList[0][refIdxL0A1]) equals 0).

[0429] Otherwise, the zero motion vector is used to initialize the MV.

[0430] The corresponding block (the center position of the current block plus the rounded MV, cropped to a specific range if necessary) is identified in the co-bit image of the signaling notification at the strip header with the initialized motion vector.

[0431] If the block is inter-frame encoded, proceed to step 2. Otherwise, the ATMVP candidate is set to unavailable.

[0432] 2.2.7.1.1.2 Derivation of Sub-CU Motion

[0433] The second step is to divide the current CU into sub-CUs and obtain the motion information of each sub-CU from the block corresponding to each sub-CU in the co-location image.

[0434] If the corresponding block of a sub-CU is encoded and decoded in inter-frame mode, the motion information is used to derive the final motion information of the current sub-CU by calling a co-bit MV derivation process that is no different from the regular TMVP process. Basically, if the corresponding block is predicted from target list X for unidirectional or bidirectional prediction, the motion vector is used; otherwise, if it is predicted from list Y (Y = 1-X) for unidirectional or bidirectional prediction and NoBackwardPredFlag equals 1, the MV of list Y is used. Otherwise, no motion candidate can be found.

[0435] If the block in the co-bit image identified by the initial MV and the current sub-CU position is intra-frame or IBC encoded, or if no motion candidate can be found as previously stated, then the following further applies:

[0436] This will be used to retrieve the co-location image R. col The motion vector of the motion field in the equation is represented by MV. col To minimize the impact of MV scaling, the method used to derive the MV is selected as follows. col MV in the airspace candidate list: If the reference image of the candidate MV is a co-bit image, then the MV is selected and used as the MV. col Without any scaling. Otherwise, the MV with the reference image that is closest to the co-located image is selected to derive the MV in the case of scaling. col .

[0437] The decoding process related to the derivation of the co-position motion vector is described below, where the parts related to ATMVP are... Highlight:

[0438] 8.5.2.12 Derivation of the co-positional motion vector

[0439] The input to this process is:

[0440] – The variable currCb specifies the current encoding / decoding block.

[0441] – The variable colCb specifies the co-bit encoding / decoding block within the co-bit image specified by ColPic.

[0442] – Luminance position (xColCb, yColCb), specifies the top-left sample of the co-bit luminance codec block specified by colCb relative to the top-left luminance sample of the co-bit image specified by ColPic.

[0443] – Refer to the index refIdxLX, where X is 0 or 1.

[0444] – Flag, indicating the candidate sbFlag for sub-block temporal merge.

[0445] The output of this process is:

[0446] Motion vector prediction accuracy of mvLXCol with a fractional sample point accuracy of -1 / 16.

[0447] –Availability flag: availableFlagLXCol.

[0448] The variable currPic specifies the current image.

[0449] The arrays predFlagL0Col[x][y], mvL0Col[x][y], and refIdxL0Col[x][y] are set to be equal to the co-bit images PredFlagL0[x][y], MvDmvrL0[x][y], and RefIdxL0[x][y] specified by ColPic, respectively, and the arrays predFlagL1Col[x][y], mvL1Col[x][y], and refIdxL1Col[x][y] are set to be equal to the co-bit images PredFlagL1[x][y], MvDmvrL1[x][y], and RefIdxL1[x][y] specified by ColPic, respectively.

[0450] The derivation of variables mvLXCol and availableFlagLXCol is as follows:

[0451] – If colCb is encoded and decoded in intra-frame or IBC prediction mode, then both components of mvLXCol are set to 0 and availableFlagLXCol is set to 0.

[0452] Otherwise, the motion vector mvCol, the reference index refIdxCol, and the reference list identifier listCol are derived as follows:

[0453] – If sbFlag equals 0, then availableFlagLXCol is set to 1, and the following applies:

[0454] – If predFlagL0Col[xColCb][yColCb] equals 0, then mvCol, refIdxCol, and listCol are set to equal to mvL1Col[xColCb][yColCb], refIdxL1Col[xColCb][yColCb], and L1, respectively.

[0455] Otherwise, if predFlagL0Col[xColCb][yColCb] equals 1 and predFlagL1Col[xColCb][yColCb] equals 0, then mvCol, refIdxCol, and listCol are set to mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb], and L0, respectively.

[0456] Otherwise (if predFlagL0Col[xColCb][yColCb] equals 1 and predFlagL1Col[xColCb][yColCb] equals 1), perform the following allocation:

[0457] – If NoBackwardPredFlag equals 1, then mvCol, refIdxCol, and listCol are set to equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively.

[0458] Otherwise, mvCol, refIdxCol, and listCol are set to equal mvLNCol[xColCb][yColCb], refIdxLNCol[xColCb][yColCb], and LN, respectively, where N is the value of collocated_from_l0_flag.

[0459] Otherwise (sbFlag equals 1), the following applies:

[0460] – If PredFlagLXCol[xColCb][yColCb] equals 1, then mvCol, refIdxCol, and listCol are set to equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, and availableFlagLXCol is set to 1.

[0461] – Otherwise (PredFlagLXCol[xColCb][yColCb] equals 0), the following applies:

[0462] – If for each image aPic in the reference image list of the current stripe, DiffPicOrderCnt(aPic,currPic) is less than or equal to 0, and PredFlagLYCol[xColCb][yColCb] is equal to 1, then mvCol, refIdxCol, and listCol are set to mvLYCol[xColCb][yColCb], refIdxLYCol[xColCb][yColCb], and LY, respectively, where Y equals ! X, where X is the value of X that called the procedure. availableFlagLXCol is set to 1.

[0463] Both components of –mvLXCol are set to 0, and availableFlagLXCol is also set to 0.

[0464] – When availableFlagLXCol is true, the derivations of mvLXCol and availableFlagLXCol are as follows:

[0465] – If LongTermRefPic(currPic, currCb, refIdxLX, LX) is not equal to LongTermRefPic(ColPic, colCb, refIdxCol, listCol), then both components of mvLXCol are set to 0 and availableFlagLXCol is set to 0.

[0466] Otherwise, the variable availableFlagLXCol is set to 1, refPicList[listCol][refIdxCol] is set to the list of reference images in listCol that contain the stripe of the codec block colCb in the co-bit image specified by ColPic, and the following applies:

[0467] colPocDiff=DiffPicOrderCnt(ColPic,refPicList[listCol][refIdxCol])(8-402)

[0468] currPocDiff=DiffPicOrderCnt(currPic,RefPicList[X][refIdxLX])(8-403)

[0469] – Invoke the temporal motion buffer compression process of the co-located motion vector as specified in Clause 8.5.2.15, with mvCol as input and the modified mvCol as output.

[0470] – If RefPicList[X][refIdxLX] is a long-term reference image, or colPocDiff equals currPocDiff, then mvLXCol is derived as follows:

[0471] mvLXCol=mvCol(8-404)

[0472] Otherwise, mvLXCol is derived as a scaled version of the motion vector mvCol, as follows:

[0473] tx=(16384+(Abs(td)>>1)) / td (8-405)

[0474] distScaleFactor=Clip3(-4096,4095,(tb*tx+32)>>6) (8-406)

[0475] mvLXCol=Clip3(-131072,131071,(distScaleFactor*mvCol+128-(distScaleFactor*mvCol>=0))>>8)) (8-407)

[0476] The derivation of td and tb is as follows:

[0477] td=Clip3(-128,127,colPocDiff) (8-408)

[0478] tb=Clip3(-128,127,currPocDiff) (8-409)

[0479] 2.2.8 Refinement of motion information

[0480] 2.2.8.1 Decoder-side Motion Vector Refinement (DMVR)

[0481] In bidirectional prediction, for the prediction of a block region, two prediction blocks formed using the motion vectors (MV) from list0 and list1, respectively, are combined to form a single prediction signal. In the decoder-side motion vector refinement (DMVR) method, the two motion vectors of the bidirectional prediction are further refined.

[0482] For DMVR in VVC, the MVD mirroring is performed between list 0 and list 1 as follows: Figure 19The assumptions are given, and bilateral matching is performed to refine the MV, i.e., to find the optimal MVD among several MVD candidates. Let MVL0(L0X, L0Y) and MVL1(L1X, L1Y) represent the MVs of two lists of reference images. The MVD represented by (MvdX, MvdY) of list 0 that minimizes a cost function (e.g., SAD) is defined as the optimal MVD. For the SAD function, it is defined as the sum of the motion vectors (L0X+MvdX, L0Y+MvdY) in the reference images of list 0 and the sum of the motion vectors (L0X+MvdX, L0Y+MvdY) in the reference images of list 0.

[0483] 1. Reference block of List 1 for the derivation of motion vectors (L1X-MvdX, L1Y-MvdY) in the reference image.

[0484] SAD between.

[0485] The motion vector thinning process can be iterated twice. In each iteration, up to six MVDs (with integer pixel precision) can be checked in two steps, such as... Figure 20 As shown. In the first step, MVD(0,0), (-1,0), (1,0), (0,-1), and (0,1) are checked. In the second step, one of MVD(-1,-1), (-1,1), (1,-1), or (1,1) can be selected and further checked. Assume 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:

[0486] MvdX = -1;

[0487] MvdY = -1;

[0488] If (Sad(1,0) <Sad(-1,0))

[0489] Then MvdX = 1;

[0490] If (Sad(0,1) <Sad(0,-1))

[0491] Then MvdY = 1;

[0492] In the first iteration, the starting point is the MV of the signaling notification, and in the second iteration, the starting point is the MV of the signaling notification plus the best MVD selected in the first iteration. DMVR is applied only when one reference image is the preceding image and the other reference image is the following image, and the two reference images have the same image order count distance from the current image.

[0493] Figure 19 An example of MVD(0,1) mirrored between list 0 and list 1 in DMVR is shown.

[0494] Figure 20 An example of an MV that can be examined in a single iteration is shown.

[0495] To further simplify the DMVR process, several changes have been proposed to the design in JEM. More specifically, the DMVR design adopted in VTM-4.0 (soon to be released) has the following key features:

[0496] • Terminate early when the SAD at position (0,0) between list 0 and list 1 is less than the threshold.

[0497] • The SAD between list 0 and list 1 is terminated early if some positions are zero.

[0498] • DMVR block size: W*H>=64&&H>=8, where W and H are the width and height of the block.

[0499] For DMVRs with CU dimensions > 16x16, the CU is divided into multiple 16x16 sub-blocks. If only the width or height of the CU is greater than 16, it is divided only in the vertical or horizontal direction.

[0500] • Reference block size (W+7)*(H+7) (for brightness).

[0501] • 25-point SAD-based integer pixel search (i.e., (+-)2 refinement of the search range, single-stage)

[0502] • DMVR based on bilinear interpolation.

[0503] • Subpixel thinning based on the “parameter error surface equation”. This process is performed only if the minimum SAD cost is not equal to zero and the optimal MVD is (0, 0) in the last MV thinning iteration.

[0504] • Luminosity / chromaticity MC with reference block fill (if required).

[0505] • Detailed MVs for MC and TMVP only.

[0506] 2.2.8.1.1 Use of DMVR

[0507] DMVR can be enabled when all of the following conditions are true:

[0508] – The DMVR enable flag in SPS (i.e., sps_dmvr_enabled_flag) is equal to 1.

[0509] – The TPM flag, inter-frame affine flag, sub-block merge flag (ATMVP or affine merge), and MMVD flag are all equal to 0.

[0510] –Merge flag equals 1

[0511] – The current block is predicted bidirectionally, and the POC distance between the current image and the reference images in list 1 is equal to the POC distance between the reference images in list 0 and the current image.

[0512] - Current CU height is greater than or equal to 8

[0513] – The number of luminance samples (CU width * height) is greater than or equal to 64

[0514] 2.2.8.1.2 Sub-pixel thinning based on the "parameter error surface equation"

[0515] The method can be summarized as follows:

[0516] 1. Parameter error surface fitting is calculated only if the center position is the optimal cost position in a given iteration.

[0517] 2. The center location cost and the costs at the (-1,0), (0,-1), (1,0), and (0,1) locations from the center are used to fit the following two-dimensional parabolic error surface equation.

[0518] E(x,y)=A(x-x0) 2 +B(y-y0) 2 +C

[0519] Where (x0, y0) corresponds to the position with the lowest cost, and C corresponds to the minimum cost value. By solving five equations with five unknowns, (x0, y0) is calculated as:

[0520] x0=(E(-1,0)-E(1,0)) / (2(E(-1,0)+E(1,0)-2E(0,0)))

[0521] y0=(E(0,-1)-E(0,1)) / (2((E(0,-1)+E(0,1)-2E(0,0)))

[0522] The precision of the division can be adjusted to compute (x0, y0) to any desired subpixel precision (i.e., how many bits of quotient to compute). For 1 / 16 pixel accuracy, only 4 bits of the absolute value of the quotient need to be computed, which facilitates the implementation of fast shift subtraction based on the 2 divisions required per CU.

[0523] 3. The calculated (x0, y0) is added to the integer distance thinning MV to obtain the subpixel accurate thinning increment MV.

[0524] 2.3 Intra-frame block copying

[0525] Intra-block copying (IBC) (also known as current picture reference) has been adopted in the HEVC Screen Content Coding extension (HEVC-SCC) and the current VVC test model (VTM-4.0). IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding. Figure 20 As shown, when IBC is applied, the current block is predicted from a reference block in the same image. Before the current block can be encoded or decoded, the samples in the reference block must have been reconstructed. While IBC is not very efficient for most camera-captured sequences, it shows significant encoding / decoding advantages for screen content. This is because screen content contains many repeating patterns, such as icons and text characters in screen content images. IBC can effectively remove redundancy between these repeating patterns. In HEVC-SCC, the codec unit (CU) of inter-frame encoding / decoding can apply IBC if it selects the current image as its reference image. In this case, the MV is called the block vector (BV), and the BV always has integer pixel precision. For compatibility with the main HEVC profile, the current image is marked as the "long-term" reference image in the Decoded Picture Buffer (DPB). It should be noted that, similarly, in multi-view / 3D video codec standards, inter-view reference images are also marked as "long-term" reference images.

[0526] By following the BV (Browser Value) to find its reference block, predictions can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixel from the original signaling. Transformation and quantization can then be applied as in other codec modes. Figure 21 This is a diagram illustrating intra-frame block copying.

[0527] However, when the reference block is outside the image, overlaps with the current block, is outside the reconstructed region, or is outside the valid region limited by some constraints, some or all pixel values ​​are undefined. Basically, there are two solutions to this problem. One is to prohibit such cases, for example, in bitstream consistency. The other is to apply padding to those undefined pixel values. The following sub-session describes this solution in detail.

[0528] 2.3.1 IBC in the VVC Test Model (VTM4.0)

[0529] In the current VVC test model (i.e., the VTM-4.0 design), the entire reference block should be together with the current codec tree unit (CTU) and should not overlap with the current block. Therefore, there is no need to pad the reference block or prediction block. The IBC flag is encoded into the prediction mode of the current CU. Therefore, there are a total of three prediction modes for each CU: MODE_INTRA, MODE_INTER, and MODE_IBC.

[0530] 2.3.1.1 IBC Merge Mode

[0531] In IBC merge mode, the index pointing to an entry in the IBC merge candidate list is parsed from the bitstream. The construction of the IBC merge list can be summarized according to the following sequence of steps:

[0532] ●Step 1: Derive spatial candidates

[0533] ●Step 2: Insert HMVP candidate

[0534] ●Step 3: Insert pairwise average candidates

[0535] In the derivation of spatial merge candidates, up to four merge candidates are selected from those located at positions A1, B1, B0, A0, and B2, as follows: Figure 2 As shown. The derivation order is A1, B1, B0, A0, and B2. Position B2 is considered only if any PU at positions A1, B1, B0, or A0 is unavailable (e.g., because it belongs to another stripe or slice) or is not encoded / decoded in IBC mode. After adding the candidate at position A1, the insertion of the remaining candidates undergoes a redundancy check, which ensures that candidates with the same motion information are excluded from the list, thereby improving encoding / decoding efficiency.

[0536] After inserting a spatial candidate, if the IBC merge list size is still smaller than the maximum IBC merge list size, an IBC candidate from the HMVP table can be inserted. Redundancy checks are performed when inserting an HMVP candidate.

[0537] Finally, the pairwise averaged candidates are inserted into the IBC merge list.

[0538] A merge candidate is called an invalid merge candidate when the reference block identified by the merge candidate is outside the image, overlaps with the current block, is outside the reconstructed region, or is outside the valid region restricted by some constraints.

[0539] Note that invalid merge candidates can be inserted into the IBC merge list.

[0540] 2.3.1.2 IBC AMVP Mode

[0541] In IBC AMVP mode, the AMVP index pointing to an entry in the IBC AMVP list is parsed from the bitstream. The construction of the IBC AMVP list can be summarized according to the following sequence of steps:

[0542] Step 1: Derive airspace candidates

[0543] Check A0 and A1 until a usable candidate is found.

[0544] Check B0, B1, and B2 until a usable candidate is found.

[0545] Step 2: Insert HMVP candidate

[0546] Step 3: Insert zero candidate

[0547] After inserting a spatial candidate, if the size of the IBC AMVP list is still smaller than the maximum IBC AMVP list size, then an IBC candidate from the HMVP table can be inserted.

[0548] Ultimately, the zero candidate was inserted into the IBC AMVP list.

[0549] 2.3.1.3 Chromaticity IBC Mode

[0550] In the current VVC, motion compensation in the chroma IBC mode is performed at the sub-block level. The chroma block is divided into several sub-blocks. Each sub-block determines whether its corresponding luma block has a block vector, and if so, its validity. The current VTM has encoder constraints, where the chroma IBC mode is tested if all sub-blocks in the current chroma CU have valid luma block vectors. For example, in YUV 420 video, the chroma block is NxM, and the co-occurring luma region is 2Nx2M. The sub-block size of the chroma block is 2x2. Several steps are involved in chroma mv derivation, followed by a block copying process.

[0551] 1) The chroma block will first be divided into (N>>1)*(M>>1) sub-blocks.

[0552] 2) For each sub-block with a top-left sample point at coordinates (x, y), retrieve the corresponding luminance block that covers the same top-left sample point at coordinates (2x, 2y).

[0553] 3) The encoder checks the block vector (bv) of the retrieved luminance block. If one of the following conditions is met, the bv is considered invalid.

[0554] a. The corresponding luminance block does not have a bv value.

[0555] b. The predicted block identified by bv has not yet been reconstructed.

[0556] c. The predicted block identified by bv partially or completely overlaps with the current block.

[0557] 4) The chromaticity motion vector of the sub-block is set to the motion vector of the corresponding luminance sub-block.

[0558] When all sub-blocks find a valid bv, enable IBC mode at the encoder.

[0559] 2.3.2 (in VTM5.0) Recent Progress of IBC

[0560] 2.3.2.1 Single BV List

[0561] In IBC, the BV predictors of merge mode and AMVP mode will share a common predictor list, which consists of the following elements:

[0562] • Two adjacent airspace locations (e.g.) Figure 2 (A1, B1)

[0563] · 5 HMVP entries

[0564] · Default zero vector

[0565] The number of candidates in the list is controlled by a variable derived from the strip header. For merge mode, up to the first 6 entries of the list will be used; for AMVP mode, the first 2 entries will be used. Furthermore, the list must conform to the shared merge list region requirement (the same shared list within SMR).

[0566] In addition to the aforementioned BV predictor candidate list, a simplified pruning operation is proposed between the HMVP candidate and the existing merge candidates (A1, B1). In this simplification, there will be at most two pruning operations, as it only compares the first HMVP candidate with (multiple) spatial merge candidates.

[0567] 2.3.2.2 Size Limitations of IBC

[0568] In the latest VVC and VTM5, it is proposed to explicitly use syntax constraints to disable the 128x128 IBC mode on top of the current bitstream constraints in previous VTM and VVC versions. This makes the presence of the IBC flag dependent on the CU size <128x128.

[0569] 2.3.2.3 Shared merge list for IBC

[0570] To reduce decoder complexity and support parallel encoding, a proposal is made to share the same merge candidate list for all leaf codec units (CUs) of an ancestor node in the CU partitioning tree, enabling parallel processing of small skip / merge codecs. The ancestor node is named the merge-shared node. A shared merge candidate list is generated at the merge-shared node, which is assumed to be a leaf CU.

[0571] More specifically, the following may apply:

[0572] – If a block has no more than 32 luminance samples and is divided into two 4×4 sub-blocks, a shared merge list is used between very small blocks (e.g., two adjacent 4×4 blocks).

[0573] However, if the block has more than 32 luminance samples, and after partitioning, at least one sub-block is less than the threshold (32), then all sub-blocks of the partition share the same merge list (e.g., 16×4 or 4×16 ternary partitioning or 8×8 quadrilateral partitioning).

[0574] This limitation applies only to IBC merge mode.

[0575] 2.4 Merge estimation area

[0576] HEVC / H.265 introduces the Merge Estimation Region (MER) to allow independent derivation of merge candidate lists for codec units within the same MER. Candidate blocks within the same MER as the current codec unit are not included in the merge candidate list. Spatial merge candidate availability is set to false if xPb >> Log2ParMrgLevel equals xNbA1 >> Log2ParMrgLevel and yPb >> Log2ParMrgLevel equals yNbA1 >> Log2ParMrgLevel. Here, Log2ParMrgLevel equals 2 + log2_parallel_merge_level_MINUS 2, xPb and yPb are the coordinates of the current block, and xNbA1 and yNbA1 are the coordinates of spatially neighboring blocks. The MER size is adaptive and signaled as log2_parallel_merge_level_minus2 in the image parameter set.

[0577] Figure 22 An example of MER is shown. Figure 22 As shown, gray blocks in the same MER (MER 3) as the current codec unit are not included in the merge candidate list, while blue blocks in different MERs (MER 2) can be included in the merge candidate list.

[0578] Figure 22 This is a diagram of MER.

[0579] 3 Examples of technical problems solved by the solutions and embodiments described herein

[0580] The current design of the IBC block under MER has the following problems:

[0581] 1. The process for constructing the merge candidate list for general merges or affine merges is well defined under MER. However, the process for constructing the block vector (BV) merge list for IBC blocks is undefined. Therefore, MER cannot be used when IBC is enabled.

[0582] 2. In the current design, when a neighboring block is within the MER (Matcher Registry), it is marked as unavailable. Therefore, for some CUs (Complex Units), it is possible that all neighboring blocks in the spatial domain become unavailable. Further research is needed on how to better handle this situation.

[0583] 4. List of example embodiments and techniques

[0584] In this document, Intra-Block Copying (IBC) is not limited to current IBC techniques, but can be interpreted as a technique for obtaining a reference (or predicted) block using samples from the current strip / slice / sub-picture / picture / other video units (such as CTU rows), excluding traditional intra-frame prediction methods. To address the above issues, a BV list construction process for IBC blocks under MER is proposed.

[0585] The following list of items should be considered as examples to illustrate general concepts. These items should not be interpreted in a narrow way. Furthermore, these items can be combined in any way.

[0586] "Under MER" can be interpreted as "within MER", "overlapping with MER", or "the size of the current codec block is not greater than the size of MER".

[0587] Figure 23 This is a diagram of the neighboring blocks in the MER spatial domain.

[0588] The spatially adjacent blocks of a MER are defined as those blocks outside the current MER. In addition, two concepts are introduced: spatially adjacent blocks of a MER and spatially non-adjacent blocks of a MER. Spatially adjacent blocks of a MER are those blocks that are spatially adjacent to the MER region, while spatially non-adjacent blocks of a MER are those blocks that are not spatially adjacent to the MER region. In both cases, they should be outside the current MER. For the bottom-right MER, in Figure 23 Examples of adjacent blocks in the MER spatial domain (e.g., C0, C1, D0, D1, and D2) and non-adjacent blocks in the MER spatial domain (e.g., E0, E1, F0, F1, and F2) are depicted.

[0589] IBC block BV list construction process

[0590] 1. When constructing the BV list for an IBC codec block, BV candidates from spatially adjacent (adjacent or / and non-adjacent) blocks under the MER that covers the current block cannot be used.

[0591] a. It is proposed that when constructing the BV list for an IBC codec block, only BV candidates from spatially adjacent (adjacent or / and non-adjacent) blocks outside the MER covering the current block, or / and BV candidates from the IBC HMVP table, or / and default BV candidates, may be used.

[0592] b. In one example, BV candidates from the IBC HMVP table can be added to the BV list.

[0593] i. Alternatively, BV candidates from neighboring blocks in the airspace may not be inserted into the BV list.

[0594] ii. In one example, BV candidates from the IBC HMVP table can be added to the BV list in a predefined order, or / and no pruning is performed when such BV candidates are added.

[0595] 1) In one example, the order is based on the ascending order of the table's entry indexes.

[0596] 2) In one example, the order is based on the descending order of the table's entry indexes.

[0597] 3) In one example, the first N entries in the table can be skipped.

[0598] 4) In one example, the last N entries in the table can be skipped.

[0599] 5) In one example, entries with (multiple) invalid BVs can be skipped.

[0600] iii. Alternatively, BV candidates from IBC HMVP candidates can be modified before being inserted into the BV list.

[0601] 1) For example, offsets can be added to the horizontal and / or vertical components of BV candidates from the IBC HMVP table.

[0602] 2) For example, an HMVP candidate with (multiple) invalid BVs can be modified to a candidate with (multiple) valid BVs.

[0603] iv. Alternatively, a default BV candidate may be added after or before one or more HMVP BV candidates.

[0604] 1) In one example, the default BV candidate can be defined as (BVx, BVy).

[0605] a. In one example, BVx = 0, BVy = 0.

[0606] b. In one example, BVx = –W, BVy = –H, where W and

[0607] H represents the width and height of the current block.

[0608] c. In one example, the BV list could refer to the IBC AMVP list or / and the IBC merge list.

[0609] 2. After decoding a video block (e.g., CU) under MER, the BV HMVP table (i.e., the HMVP table for IBC codec blocks) may not be updated.

[0610] 3. The BV HMVP table can only be updated once within MER.

[0611] a. In one example, the BVHMVP table is only updated if the current CU is not within the MER, or if its bottom right corner coincides with the bottom right corner of the MER.

[0612] The motion list construction process (e.g., BV list, or normal (non-sub-block) merge list, or sub-block merge list).

[0613] 4. It is recommended that motion information from neighboring blocks in the MER spatial domain (e.g., adjacent neighboring blocks in the MER spatial domain and / or non-adjacent neighboring blocks in the MER spatial domain) be used during the motion list construction process.

[0614] When to start checking neighboring blocks in the MER spatial domain or when to start adding motion candidates from neighboring blocks in the MER spatial domain

[0615] a. In one example, when checking the neighboring blocks (e.g., Figure 23 When A0 in the MER is unavailable (e.g., within the same MER as the current block), the neighboring blocks in the MER spatial domain are checked instead.

[0616] i. Alternatively, if motion information of neighboring blocks in the MER spatial domain is available, it can be used to derive candidates that can be directly added to the motion list as replacements for candidates derived from the spatial domain blocks.

[0617] b. In one example, after checking all spatial neighboring blocks, you can check the spatial neighboring blocks of MER.

[0618] i. Alternatively, motion information from neighboring blocks in the MER spatial domain can be added after the spatial merge candidate.

[0619] c. In one example, after checking HMVP candidates, you can check neighboring blocks in the MER spatial domain.

[0620] i. Alternatively, motion information from neighboring blocks in the MER spatial domain can be added after the HMVP candidate.

[0621] How many MER spatial neighbor blocks need to be checked; how many candidates come from MER neighbor blocks?

[0622] d. In one example, up to X (where X is an integer) candidates from adjacent neighboring blocks and non - adjacent neighboring blocks of the MER空域 can be added to the motion list. For example, X is equal to 2.

[0623] To check which MER spatial domains are adjacent to blocks

[0624] e. In one example, neighboring blocks of the MER空域 at fixed positions can be checked, and motion information from those fixed positions can be used during the motion list construction.

[0625] i. For two blocks within the same MER (e.g., Figure 24 CU0 and CU1 in

[0626] ), the same set of allowed neighboring blocks of the MER空域 can be defined, and only those blocks in the set can be checked and used. Figure 24 1) In one example, one or more of the blocks labeled C0, C1, D0, D1, and D2 in

[0627] can be checked and used only. Figure 24 2) In one example, one or more of the blocks labeled E0, E1, E0, F1, and F2 in

[0628] can be checked and used only. 3) In one example, when the adjacent neighboring blocks of the current block are not available, by assuming that the current block size is equal to the MER size, the corresponding neighboring blocks of the MER空域 can be used alternatively. Let (x0, y0) represent the upper - left position of the current block relative to the upper - left sample point of the current picture, bW represent the block width, bH represent the block height, mW represent the MER width, and mH represent the MER height (e.g., as represented in Figure 24 ), the following can apply:

[0629] a. In one example, if the left block (e.g., A1) located at (x0 - 1, y0 + bH - 1) is not available, the block (e.g., C1) located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH)+mH - 1) can be used.

[0630] b. In one example, if the lower - left block (e.g., A0) located at (xCb - 1, yCb + cbHeight) is not available, the block (e.g., C0) located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH)+mH) can be used.

[0631] c. In one example, if the upper - right block (e.g., B0) located at (x0 + bW, y0 - 1) is unavailable, the block (e.g., D0) located at ((x0 >> Log2(mW)) << Log2(mW)+mW, (y0 >> Log2(mH)) << Log2(mH)-1) can be used.

[0632] d. In one example, if the upper block (e.g., B1) located at ((x0 >> Log2(mW)) << Log2(mW)+mw1, y0 - 1) is unavailable, the block (e.g., D1) located at (x0 + bW - 1, (y0 >> Log2(mH)) << Log2(mH)-1) can be used.

[0633] e. In one example, if the upper - left block (e.g., B2) located at (x0 - 1, y0 - 1) is unavailable, the block located at ((x0 >> Log2(mW)) << Log2(mW)-1, (y0 >> Log2(mH)) << Log2(mH)-1) can be used.

[0634] f. In one example, the MER spatial - neighborhood blocks at adaptive positions can be checked, and the motion information from those adaptive positions can be used during the motion - list construction process. In this case, at least for two blocks below MER, at least one of the blocks to be checked is different.

[0635] i. In one example, when the neighboring adjacent blocks of the current block are unavailable, by assuming that the current - block size is equal to the MER size, the corresponding MER spatial - neighborhood blocks can be alternatively used. Denoting the upper - left position of the current block relative to the upper - left sample point of the current picture as (x0,y0), the block width as bW, the block height as bH, the MER width as mW, and the MER height as mH (e.g., as represented in Figure 25 ), the following can apply:

[0636] 1) In one example, if the left block (e.g., A1) located at (x0 - 1,y0 + bH - 1) is unavailable, the block (e.g., C1) located at ((x0 >> Log2(mW)) << Log2(mW)-1,y0 + bH - 1) can be used.

[0637] 2) In one example, if the lower - left block (e.g., A0) located at (xCb - 1, yCb+cbHeight) is unavailable, the block (e.g., C0) located at ((x0 >> Log2(mW)) << Log2(mW)-1, y0 + bH) can be used.

[0638] 3) In one example, if the upper - right block (e.g., B0) located at (x0 + bW, y0 - 1) is unavailable, then the block located at (x0 + bW, (y0 >> Log2(mH)) << Log2(mH) - 1) (e.g., D0) can be used.

[0639] 4) In one example, if the upper block (e.g., B1) located at (x0 + bW - 1, y0 - 1) is unavailable, then the block located at (x0 + bW - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) (e.g., D1) can be used.

[0640] 5) In one example, if the upper - left block (e.g., B2) located at (x0 - 1, y0 - 1) is unavailable, then the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) can be used.

[0641] ii. For different blocks (e.g., Figure 26 CU0 and CU1 in) within the same MER, different sets of allowed MER spatial - neighboring blocks can be defined, and only those blocks in the set can be checked and used.

[0642] 1) In one example, only one or more of the blocks marked as C0, C1, D0, D1, and D2 in Figure 26 can be checked and used in the motion - list construction of CU0.

[0643] 2) In one example, only one or more of the blocks marked as E0, E1, F0, F1, and F2 in Figure 26 can be checked and used in the motion - list construction of CU0.

[0644] 3) In one example, only one or more of the blocks marked as C'0, C'1, D'0, D'1, and D'2 in Figure 26 can be checked and used in the motion - list construction of CU1.

[0645] 4) In one example, only one or more of the blocks marked as E'0, E'1, F'0, F'1, and F'2 in Figure 26 can be checked and used in the motion - list construction of CU1.

[0646] g. In one example, whether a motion candidate from a MER spatial - neighboring block can be added to the motion list can depend on the position and / or availability of the MER spatial - neighboring block.

[0647] i. In one example, during the motion list construction process, adjacent and / or non-adjacent blocks from MER spatial domains outside of MER can be used (e.g., Figure 22 Motion candidates (e.g., IBC candidates, or normal inter-frame candidates, or sub-block candidates (e.g., affine)) of at least one of the bottom left, left, top right, top left and top adjacent blocks in the frame.

[0648] 1) In one example, motion candidates located at a specific location can be added to the motion list.

[0649] a. In one example, a "specific location" could be C1, D1 (or E1, F1).

[0650] b. In one example, a “specific location” could be D1, C1 (or F1, E1).

[0651] c. In one example, a “specific location” could be C1, D1, D2 (or E1, F1, F2).

[0652] d. In one example, a “specific location” could be D1, D2 (or F1, F2).

[0653] e. In one example, a “specific location” could be C1, D2 (or E1, F2).

[0654] 2) In one example, candidates from neighboring blocks in the airspace can be inserted into the motion list in a predefined order.

[0655] a. In one example, the “predefined order” could be C1, C0, D0, D1, and D2 (or E1, E0, F0, F1, and F2).

[0656] b. In one example, the “predefined order” could be D1, D0, C1, C0 and D2 (or F1, F0, E1, E0 and F2).

[0657] c. In one example, the “predefined order” could be D2, C1, D1, C0, and D0 (or F2, E1, F1, E0, and F0).

[0658] 3) In one example, during the motion list construction process, BV candidates from at least one of the non-adjacent bottom-left, left, top-right, top-left, and top-neighboring blocks outside of MER can be used.

[0659] ii. In one example, a block is considered usable only if it is encoded or decoded in a specific mode.

[0660] 1) In one example, "specific mode" could refer to IBC mode.

[0661] 2) In one example, “specific mode” could refer to a normal inter-frame mode (e.g., an inter-frame mode based on translation motion).

[0662] 3) In one example, "specific pattern" can refer to an affine pattern.

[0663] iii. In one example, if a neighboring block used in the motion list construction is outside the MER, then the neighboring block is considered unavailable.

[0664] iv. In one example, candidates from neighboring blocks in the MER spatial domain can be added to the motion list via a pruning operation.

[0665] 1) In one example, a candidate may not be added to the motion list if the candidate's motion information already exists in the motion list.

[0666] 2) In one example, two candidates from neighboring blocks in the MER spatial domain can be compared to determine if they are identical or similar. Only when the two candidates are not identical or similar can they both be added to the motion list.

[0667] v. Alternatively, candidates from neighboring blocks in the MER airspace can be added to the motion list without pruning.

[0668] 5. In one example, the maximum number of candidates in a block's motion list can depend on whether the block is under a MER.

[0669] a. In one example, the maximum number of candidates in the motion list for the first block under MER and the second block not under MER can be different.

[0670] i. In one example, the maximum number of candidates in the motion list of the first block can be less than the maximum number of candidates in the motion list of the second block.

[0671] ii. In one example, the maximum number of candidates in the motion list of the first block can be greater than the maximum number of candidates in the motion list of the second block.

[0672] iii. Alternatively, for the first and second blocks, the maximum number of candidates in the motion list can be the same.

[0673] b. In one example, the maximum number of candidates in the motion list under MER can be notified at the sequence level / picture level / strip level / piece group level signaling, such as in the sequence header / picture header / SPS / VPS / DPS / PPS / APS / strip header / piece group header.

[0674] i. In one example, the maximum number of candidates for the motion list of blocks under MER can only be signaled when MER is enabled for video / sequence / image / strip / sub-image / slice group / slice / CTU line, etc.

[0675] ii. In one example, the maximum number of candidates for the motion list (e.g., BV list) of blocks under the MER can be signaled based on the maximum number of candidates for the motion list of blocks not under the MER (e.g., denoted as maxBvListSizeMer).

[0676] 1) For example, you can signal maxBvListSizeNonMer – maxBvListSizeMer instead of maxBvListSizeMer.

[0677] 6. In one example, the block's motion list construction process can depend on the block's position within the MER. A block is considered completely within the MER when its left and top boundaries do not coincide with any boundaries of the MER. For example... Figure 33 As shown, CU0 and CU1 are blocks that are completely within MER, while CU2 and CU3 are not.

[0678] a. In one example, the motion list building process in bullet points 1-5 can be applied only to blocks that are entirely within the MER.

[0679] i. In one example, up to X (where X is an integer) pairs of average candidates can be added to the motion list of a block that is entirely within the MER, for example, X equals 2 or 3.

[0680] b. In one example, the signaling for the merge index of a block that is entirely within the MER can be different from that of a block that is not within the MER or is not entirely within the MER.

[0681] i. In one example, let N represent the maximum number of merge MVP candidates in the VVC. The maximum number (M) of merge MVP candidates for blocks that are entirely within the MER can be different from N.

[0682] 1) In one example, M can be less than N, for example, M = 2 but N = 5.

[0683] 2) In one example, the maximum value of the truncated Rice binarized code of the merge index of a block that is completely within MER can depend on M (e.g., it is equal to M-1).

[0684] c. In one example, the MMVD process for a block that is entirely within the MER can be different from that for a block that is not within the MER or is not entirely within the MER.

[0685] i. In one example, the maximum number (T) of MMVD base candidates for blocks that are completely within MER can be greater than 2, for example, T = 3, 4 or 5.

[0686] ii. In one example, for blocks that are entirely within MER, the predefined distance in MMVD can be modified.

[0687] 1) In one example, the modified predefined distance can be equal to d*S, where d represents the original predefined distance and S represents the multiscale.

[0688] a. In one example, S can be equal to 2 or 3.

[0689] b. In one example, S can be equal to 1 / 2 or 1 / 3.

[0690] 7. Propose specification constraints for BT and TT partitions to enable MER in VVC. Let R1, R2, W, and H represent MER width, MER height, block width, and block height, respectively.

[0691] a. In one example, when W>R1 and H<=R2, horizontal BT partitioning can be disabled for the current block.

[0692] b. In one example, vertical BT partitioning can be disabled for the current block when W <= R1 and H > R2.

[0693] c. In one example, when (W>R1||H>R2) and H<=K*R2, the horizontal TT partitioning can be disabled for the current block.

[0694] i. In one example, K can be an integer, such as K = 2.

[0695] d. In one example, vertical TT partitioning can be disabled for the current block when (W>R1||H>R2) and W<=K*R1.

[0696] i. In one example, K can be an integer, such as K = 2.

[0697] e. In one example, R1 may not be equal to R2, for example, R1 = 32, R2 = 64, or R1 = 64, R2 = 32.

[0698] f. In one example, R1 can be equal to R2, for example, R1 = R2 = 32, or R1 = R2 = 64.

[0699] g. In one example, if a type of partition is disabled, the codeword representing that type of partition can be skipped.

[0700] h. In one example, if a type of partition is disabled, the syntax elements (such as flags) representing that type of partition can be skipped.

[0701] i. In one example, whether and / or how to apply specification constraints to BT and TT partitions can depend on the strip / slice group type, and / or image type, and / or partition tree type (e.g., dual-tree / single-tree).

[0702] i. In one example, when only intra-frame codec tools are allowed for the current picture / sub-picture / strip / slice, for example, when the current picture is an I-frame or the current stripe is an I-strip, the specification constraints on BT and TT partitions may not be applied.

[0703] ii. In one example, when inter-frame encoding / decoding tools are allowed for the current picture / sub-picture / strip / slice, for example, when the current picture is a P / B frame or the current stripe is a P / B stripe, specification constraints on BT and TT partitions can be applied.

[0704] j. In one example, canonical constraints on BT and TT partitioning can be applied to blocks within a specific region of an image / frame.

[0705] i. The region can refer to a sub-image / strip / piece within an image / frame, or a predefined rectangular region (e.g., region of interest, ROI).

[0706] ii. In one example, the canonical constraints on the BT and TT partitions may not apply to a portion of the block outside the picture / frame. Let (x0, y0), picW, and picH represent the top-left luminance sample, picture / frame width, and picture / frame height of the block.

[0707] 1) In one example, a portion of the block is outside the image / frame when the top left corner of the block is inside the image / frame and the top right corner and / or the bottom left corner is outside the image / frame.

[0708] 2) In one example, BT partitioning constraints may not be applied to blocks when part of a block is outside of an image / frame.

[0709] a. In one example, horizontal BT partitioning of the block is still allowed when y0 <= picH and y0+T > picH.

[0710] i. In one example, T can be equal to the block height (T = H).

[0711] b. In one example, vertical BT partitioning of the block is still allowed when x0 <= picW and x0+T > picW.

[0712] i. In one example, T can be equal to the block width (T = W).

[0713] 3) In one example, TT partitioning constraints may not be applied to a block when part of the block is outside the image / frame.

[0714] a. In one example, the horizontal TT partitioning of the block is still allowed when y0 <= picH and y0+T > picH.

[0715] i. In one example, T can be equal to the block height (T = H).

[0716] ii. In one example, T can be equal to b*H, where b = 1 / 2 or 1 / 4.

[0717] b. In one example, vertical TT partitioning of the block is still allowed when x0 <= picW and x0+T > picW.

[0718] i. In one example, T can be equal to the block width (T = W).

[0719] ii. In one example, T can be equal to b*W, where b = 1 / 2 or 1 / 4.

[0720] Use of tools

[0721] 8. Whether and / or how to apply the above methods may depend on the following information:

[0722] a. Signaling notification messages in DPS / SPS / VPS / PPS / APS / Picture Header / Strip Header / Piece Group Header / Maximum Codec Unit (LCU) / Codec Unit (CU) / LCU Line / LCU Group / TU / PU Block / Video Codec Unit

[0723] b. Location of CU / PU / TU / block / video codec unit

[0724] c. Block dimensions of the current block and / or its neighboring blocks

[0725] d. The block shape of the current block and / or its neighboring blocks

[0726] e. The encoding / decoding mode of the block, such as IBC or non-IBC inter-frame mode or non-IBC sub-block mode.

[0727] f. Color format indication (e.g., 4:2:0, 4:4:4)

[0728] g. Encoding / decoding tree structure

[0729] h. Strip / Piece Type and / or Image Type

[0730] i. Color components (e.g., can be applied only to the chromaticity component or the luminance component)

[0731] j. Time-domain layer ID

[0732] k. Standard configuration files / levels / hierarchies

[0733] Figure 24 An example of a MER spatial neighboring block at a fixed location is shown.

[0734] Figure 25 An example of a MER spatial neighboring block at an adaptive location within a block is shown.

[0735] Figure 26 Examples of MER spatial neighboring blocks at adaptive positions in different blocks are shown.

[0736] 5 Examples

[0737] Changes to the current codec specification of the VVC standard Highlighting. Deleted text is highlighted. mark.

[0738] 5.1 Example 1

[0739] The draft working paper may be modified as follows.

[0740] 8.6.2 Derivation of the block vector components of the IBC block

[0741] 8.6.2.1 Overview

[0742] …

[0743] When IsGt4by4 equals TRUE At that time, the update procedure for the history-based block vector predictor list specified in Clause 8.6.2.6 is invoked using the luma block vector bvL.

[0744] Bitstream consistency requires that the luminance block vector bvL must comply with the following constraints:

[0745] …

[0746] 8.6.2.3 Derivation of IBC Spatial Block Vector Candidates

[0747] …

[0748] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[0749]

[0750] The derivation of variables availableFlagA1 and bvA1 is as follows:

[0751] …

[0752] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB1.

[0753]

[0754] The derivation of variables availableFlagB1 and bvB1 is as follows:

[0755] …

[0756] 5.2 Example 2

[0757] The draft working paper may be modified as follows.

[0758] 8.6.2 Derivation of the block vector components of the IBC block

[0759] 8.6.2.1 Overview

[0760] …

[0761] When IsGt4by4 equals TRUE At that time, the update procedure for the history-based block vector predictor list specified in Clause 8.6.2.6 is invoked using the luma block vector bvL.

[0762] Bitstream consistency requires that the luminance block vector bvL must comply with the following constraints:

[0763] …

[0764] 8.6.2.3 Derivation of IBC Spatial Block Vector Candidates

[0765] …

[0766] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[0767]

[0768] The derivation of variables availableFlagA1 and bvA1 is as follows:

[0769] –If availableA1 equals FALSE Then availableFlagA1 is set to 0, and both components of bvA1 are set to 0.

[0770]

[0771]

[0772] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[0773] bvA1=MvL0[xNbA1][yNbA1] (1122)

[0774] The following applies to the derivation of availableFlagB1 and bvB1:

[0775] – The luminance position (xNbB1, yNbB1) within the adjacent luminance codec block is set to equal to (xCb+cbWidth-1, yCb-1).

[0776] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB1.

[0777]

[0778] The derivation of variables availableFlagB1 and bvB1 is as follows:

[0779] -If one or more of the following conditions are true, then availableFlagB1 is set to 0, and both components of bvB1 are set to 0:

[0780] –availableB1 equals FALSE, .

[0781] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB1, yNbB1) have the same block vector.

[0782]

[0783]

[0784] Otherwise, availableFlagB1 is set to 1 and the following allocation is performed:

[0785] bvB1=MvL0[xNbB1][yNbB1] (1123)

[0786] 5.3 Example 3

[0787] The draft working paper may be modified as follows.

[0788] 8.6.2 Derivation of the block vector components of the IBC block

[0789] 8.6.2.1 Overview

[0790] …

[0791] When IsGt4by4 equals TRUE At that time, the update procedure for the history-based block vector predictor list specified in Clause 8.6.2.6 is invoked using the luma block vector bvL.

[0792] Bitstream consistency requires that the luminance block vector bvL must comply with the following constraints:

[0793] …

[0794] 8.6.2.3 Derivation of IBC Spatial Block Vector Candidates

[0795] …

[0796] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[0797]

[0798] The derivation of variables availableFlagA1 and bvA1 is as follows:

[0799] –If availableA1 equals FALSE If so, availableFlagA1 is set to 0, and both components of bvA1 are set to 0.

[0800]

[0801] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[0802] bvA1=MvL0[xNbA1][yNbA1] (1122)

[0803] The following applies to the derivation of availableFlagB1 and bvB1:

[0804] – The luminance position (xNbB1, yNbB1) within the adjacent luminance codec block is set to equal to (xCb+cbWidth-1, yCb-1).

[0805] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB1.

[0806]

[0807] The derivation of variables availableFlagB1 and bvB1 is as follows:

[0808] - AvailableFlagB1 is set to 0 if one or more of the following conditions are true, and both components of bvB1 are set to 0:

[0809] –availableB1 equals FALSE .

[0810] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB1, yNbB1) have the same block vector.

[0811]

[0812] Otherwise, availableFlagB1 is set to 1 and the following allocation is performed:

[0813] bvB1=MvL0[xNbB1][yNbB1] (1123)

[0814] 5.4 Example 4

[0815] The draft working paper may be modified as follows.

[0816] 8.5.2.3 Derivation of Spatial Merge Candidates

[0817] …

[0818] The following applies to the derivations of availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1:

[0819] – The luminance position (xNbB1, yNbB1) within the adjacent luminance codec block is set to equal to (xCb+cbWidth-1, yCb-1).

[0820] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB1.

[0821]

[0822] – When xCb>>Log2ParMrgLevel equals xNbB1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB1>>Log2ParMrgLevel

[0823]

[0824] The derivations of variables availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1 are as follows:

[0825] –If availableB1 equals FALSE Then availableFlagB1 is set to 0, both components of mvLXB1 are set to 0, refIdxLXB1 is set to -1, and predFlagLXB1 is set to 0, where X is 0 or 1, hpelIfIdxB1 is set to 0, and bcwIdxB1 is set to 0.

[0826]

[0827] Otherwise, availableFlagB1 is set to 1 and the following allocation is performed:

[0828] mvLXB1=MvLX[xNbB1][yNbB1] (499)

[0829] refIdxLXB1=RefIdxLX[xNbB1][yNbB1] (500)

[0830] predFlagLXB1=PredFlagLX[xNbB1][yNbB1] (501)

[0831] hpelIfIdxB1=HpelIfIdx[xNbB1][yNbB1] (502)

[0832] bcwIdxB1=BcwIdx[xNbB1][yNbB1] (503)

[0833] The following applies to the derivations of availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1:

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

[0835] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance positions (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[0836]

[0837] – When xCb>>Log2ParMrgLevel equals xNbA1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA1>>Log2ParMrgLevel

[0838]

[0839] The derivations of variables availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1 are as follows:

[0840] - AvailableFlagA1 is set to 0 if one or more of the following conditions are true: both components of mvLXA1 are set to 0; refIdxLXA1 is set to -1; predFlagLXA1 is set to 0, where X is 0 or 1; hpelIfIdxA1 is set to 0; and bcwIdxA1 is set to 0.

[0841] –availableA1 equals FALSE .

[0842] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB1, yNbB1) have the same motion vector and the same reference index.

[0843]

[0844] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[0845] mvLXA1=MvLX[xNbA1][yNbA1] (504)

[0846] refIdxLXA1=RefIdxLX[xNbA1][yNbA1] (505)

[0847] predFlagLXA1=PredFlagLX[xNbA1][yNbA1] (506)

[0848] hpelIfIdxA1=HpelIfIdx[xNbA1][yNbA1] (507)

[0849] bcwIdxA1=BcwIdx[xNbA1][yNbA1] (508)

[0850] The following applies to the derivation of availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0:

[0851] – The luminance position (xNbB0, yNbB0) within the adjacent luminance codec block is set to equal to (xCb+cbWidth, yCb-1).

[0852] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB0, yNbB0), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB0.

[0853]

[0854] – When xCb>>Log2ParMrgLevel equals xNbB0>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB0>>Log2ParMrgLevel

[0855] The derivations of variables availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0 are as follows:

[0856] - AvailableFlagB0 is set to 0 if one or more of the following conditions are true: both components of mvLXB0 are set to 0; refIdxLXB0 is set to -1; predFlagLXB0 is set to 0, where X is 0 or 1; hpelIfIdxB0 is set to 0; and bcwIdxB0 is set to 0.

[0857] –availableB0 equals FALSE, .

[0858] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbB1, yNbB1) and (xNbB0, yNbB0) have the same motion vector and the same reference index.

[0859]

[0860]

[0861] Otherwise, availableFlagB0 is set to 1 and the following allocation is performed:

[0862] mvLXB0=MvLX[xNbB0][yNbB0] (509)

[0863] refIdxLXB0=RefIdxLX[xNbB0][yNbB0] (510)

[0864] predFlagLXB0=PredFlagLX[xNbB0][yNbB0] (511)

[0865] hpelIfIdxB0=HpelIfIdx[xNbB0][yNbB0] (512)

[0866] bcwIdxB0=BcwIdx[xNbB0][yNbB0] (513)

[0867] The following applies to the derivation of availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0:

[0868] – The luminance position (xNbA0, yNbA0) within the adjacent luminance codec block is set to equal to (xCb-1, yCb+cbWidth).

[0869] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance positions (xNbA0, yNbA0), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA0.

[0870]

[0871] – When xCb>>Log2ParMrgLevel equals xNbA0>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA0>>Log2ParMrgLevel

[0872] The derivations of variables availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0 are as follows:

[0873] – AvailableFlagA0 is set to 0 if one or more of the following conditions are true: both components of mvLXA0 are set to 0; refIdxLXA0 is set to -1; predFlagLXA0 is set to 0, where X is 0 or 1; hpelIfIdxA0 is set to 0; and bcwIdxA0 is set to 0.

[0874] –availableA0 equals FALSE, .

[0875] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbA0, yNbA0) have the same motion vector and the same reference index.

[0876]

[0877]

[0878] Otherwise, availableFlagA0 is set to 1 and the following allocation is performed:

[0879] mvLXA0=MvLX[xNbA0][yNbA0] (514)

[0880] refIdxLXA0=RefIdxLX[xNbA0][yNbA0] (515)

[0881] predFlagLXA0=PredFlagLX[xNbA0][yNbA0] (516)

[0882] hpelIfIdxA0=HpelIfIdx[xNbA0][yNbA0] (517)

[0883] bcwIdxA0=BcwIdx[xNbA0][yNbA0] (518)

[0884] The following applies to the derivations of availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2:

[0885] – The luminance position (xNbB2, yNbB2) within the adjacent luminance codec block is set to be equal to (xCb-1, yCb-1).

[0886] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB2, yNbB2), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB2.

[0887]

[0888] When xCb>>Log2ParMrgLevel equals xNbB2>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB2>>Log2ParMrgLevel...

[0889] The derivations of variables availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2 are as follows:

[0890] – AvailableFlagB2 is set to 0 if one or more of the following conditions are true: both components of mvLXB2 are set to 0; refIdxLXB2 is set to -1; predFlagLXB2 is set to 0, where X is 0 or 1; hpelIfIdxB2 is set to 0; and bcwIdxB2 is set to 0.

[0891] –availableB2 equals FALSE, .

[0892] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB2, yNbB2) have the same motion vector and the same reference index.

[0893]

[0894] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbB1, yNbB1) and (xNbB2, yNbB2) have the same motion vector and the same reference index.

[0895]

[0896] –availableFlagA0+availableFlagA1+availableFlagB0+availableFlagB1 equals 4.

[0897]

[0898] Otherwise, availableFlagB2 is set to 1 and the following allocation is performed:

[0899] mvLXB2=MvLX[xNbB2][yNbB2] (519)

[0900] refIdxLXB2=RefIdxLX[xNbB2][yNbB2] (520)

[0901] predFlagLXB2=PredFlagLX[xNbB2][yNbB2] (521)

[0902] hpelIfIdxB2=HpelIfIdx[xNbB2][yNbB2] (522)

[0903] bcwIdxB2=BcwIdx[xNbB2][yNbB2] (523)

[0904] 5.5 Example 5

[0905] The draft working paper may be modified as follows.

[0906] 8.5.2.3 Derivation of Spatial Merge Candidates

[0907] …

[0908] The following applies to the derivation of availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1:

[0909] – The luminance position (xNbB1, yNbB1) within the adjacent luminance codec block is set to equal to (xCb+cbWidth-1, yCb-1).

[0910] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB1.

[0911]

[0912] – When xCb>>Log2ParMrgLevel equals xNbB1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB1>>Log2ParMrgLevel

[0913] The derivations of variables availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1 are as follows:

[0914] –If availableB1 equals FALSE Then availableFlagB1 is set to 0, both components of mvLXB1 are set to 0, refIdxLXB1 is set to -1, and predFlagLXB1 is set to 0, where X is 0 or 1, hpelIfIdxB1 is set to 0, and bcwIdxB1 is set to 0.

[0915]

[0916] Otherwise, availableFlagB1 is set to 1 and the following allocation is performed:

[0917] mvLXB1=MvLX[xNbB1][yNbB1] (499)

[0918] refIdxLXB1=RefIdxLX[xNbB1][yNbB1] (500)

[0919] predFlagLXB1=PredFlagLX[xNbB1][yNbB1] (501)

[0920] hpelIfIdxB1=HpelIfIdx[xNbB1][yNbB1] (502)

[0921] bcwIdxB1=BcwIdx[xNbB1][yNbB1] (503)

[0922] The following applies to the derivations of availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1:

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

[0924] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) to equal (xCb, yCb), the neighboring luminance positions (xNbA1, yNbA1), checkPredModeY to equal TRUE, and cIdx to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[0925]

[0926] – When xCb>>Log2ParMrgLevel equals xNbA1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA1>>Log2ParMrgLevel

[0927] The derivations of variables availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1 are as follows:

[0928] - AvailableFlagA1 is set to 0 if one or more of the following conditions are true: both components of mvLXA1 are set to 0; refIdxLXA1 is set to -1; predFlagLXA1 is set to 0, where X is set to either 0 or 1; hpelIfIdxA1 is set to 0; and bcwIdxA1 is set to 0.

[0929] –availableA1 equals FALSE, .

[0930] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB1, yNbB1) have the same motion vector and the same reference index.

[0931]

[0932]

[0933] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[0934] mvLXA1=MvLX[xNbA1][yNbA1] (504)

[0935] refIdxLXA1=RefIdxLX[xNbA1][yNbA1] (505)

[0936] predFlagLXA1=PredFlagLX[xNbA1][yNbA1] (506)

[0937] hpelIfIdxA1=HpelIfIdx[xNbA1][yNbA1] (507)

[0938] bcwIdxA1=BcwIdx[xNbA1][yNbA1] (508)

[0939] The following applies to the derivation of availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0:

[0940] – The luminance position (xNbB0, yNbB0) within the adjacent luminance codec block is set to equal to (xCb+cbWidth, yCb-1).

[0941] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB0, yNbB0), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB0.

[0942]

[0943] – When xCb>>Log2ParMrgLevel equals xNbB0>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB0>>Log2ParMrgLevel

[0944] The derivations of variables availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0 are as follows:

[0945] - If one or more of the following conditions are true, availableFlagB0 is set to 0, both components of mvLXB0 are set to 0, refIdxLXB0 is set to -1, and predFlagLXB0 is set to 0, where X is 0 or 1, hpelIfIdxB0 is set to 0, and bcwIdxB0 is set to 0:

[0946] –availableB0 equals FALSE, .

[0947] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbB1, yNbB1) and (xNbB0, yNbB0) have the same motion vector and the same reference index.

[0948]

[0949] Otherwise, availableFlagB0 is set to 1 and the following allocation is performed:

[0950] mvLXB0=MvLX[xNbB0][yNbB0] (509)

[0951] refIdxLXB0=RefIdxLX[xNbB0][yNbB0] (510)

[0952] predFlagLXB0=PredFlagLX[xNbB0][yNbB0] (511)

[0953] hpelIfIdxB0=HpelIfIdx[xNbB0][yNbB0] (512)

[0954] bcwIdxB0=BcwIdx[xNbB0][yNbB0] (513)

[0955] The following applies to the derivation of availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0:

[0956] – The luminance position (xNbA0, yNbA0) within the adjacent luminance codec block is set to equal to (xCb-1, yCb+cbWidth).

[0957] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) to equal (xCb, yCb), the neighboring luminance positions (xNbA0, yNbA0), checkPredModeY to equal TRUE, and cIdx to equal 0 as inputs, and assign the output to the block availability flag availableA0.

[0958]

[0959] When xCb>>Log2ParMrgLevel equals xNbA0>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA0>>Log2ParMrgLevel...

[0960] The derivations of variables availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0 are as follows:

[0961] – AvailableFlagA0 is set to 0 if one or more of the following conditions are true: both components of mvLXA0 are set to 0; refIdxLXA0 is set to -1; predFlagLXA0 is set to 0, where X is 0 or 1; hpelIfIdxA0 is set to 0; and bcwIdxA0 is set to 0.

[0962] –availableA0 equals FALSE, .

[0963] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbA0, yNbA0) have the same motion vector and the same reference index.

[0964]

[0965] Otherwise, availableFlagA0 is set to 1 and the following allocation is performed:

[0966] mvLXA0=MvLX[xNbA0][yNbA0] (514)

[0967] refIdxLXA0=RefIdxLX[xNbA0][yNbA0] (515)

[0968] predFlagLXA0=PredFlagLX[xNbA0][yNbA0] (516)

[0969] hpelIfIdxA0=HpelIfIdx[xNbA0][yNbA0] (517)

[0970] bcwIdxA0=BcwIdx[xNbA0][yNbA0] (518)

[0971] The following applies to the derivations of availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2:

[0972] – The luminance position (xNbB2, yNbB2) within the adjacent luminance codec block is set to be equal to (xCb-1, yCb-1).

[0973] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB2, yNbB2), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB2.

[0974]

[0975] – When xCb>>Log2ParMrgLevel equals xNbB2>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB2>>Log2ParMrgLevel

[0976] The derivations of variables availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2 are as follows:

[0977] – AvailableFlagB2 is set to 0 if one or more of the following conditions are true: both components of mvLXB2 are set to 0; refIdxLXB2 is set to -1; predFlagLXB2 is set to 0, where X is 0 or 1; hpelIfIdxB2 is set to 0; and bcwIdxB2 is set to 0.

[0978] –availableB2 equals FALSE, .

[0979] –availableA1 equals TRUE, Furthermore, the brightness positions (xNbA1, yNbA1) and (xNbB2, yNbB2) have the same motion vector and the same reference index.

[0980]

[0981] –availableB1 equals TRUE, Furthermore, the brightness positions (xNbB1, yNbB1) and (xNbB2, yNbB2) have the same motion vector and the same reference index.

[0982]

[0983] –availableFlagA0+availableFlagA1+availableFlagB0+availableFlagB1 equals 4.

[0984]

[0985]

[0986] Otherwise, availableFlagB2 is set to 1 and the following allocation is performed:

[0987] mvLXB2=MvLX[xNbB2][yNbB2] (519)

[0988] refIdxLXB2=RefIdxLX[xNbB2][yNbB2] (520)

[0989] predFlagLXB2=PredFlagLX[xNbB2][yNbB2] (521)

[0990] hpelIfIdxB2=HpelIfIdx[xNbB2][yNbB2] (522)

[0991] bcwIdxB2=BcwIdx[xNbB2][yNbB2] (523)

[0992] 5.6 Example 6

[0993] The draft working paper may be modified as follows.

[0994] 8.5.5.2 Derivation of motion vectors and reference indices in sub-block merge mode

[0995] …

[0996] The variables numSbColX, numSbColY, and the subblock merge candidate list subblockMergeCandList are derived by the following ordered steps:

[0997] 1. When sps_sbtmvp_enabled_flag equals 1, the following applies:

[0998] – For the derivation of availableFlagA1, refIdxLXA1, predFlagLXA1, and mvLXA1, the following applies:

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

[1000] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[1001]

[1002] – When xCb>>Log2ParMrgLevel equals xNbA1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA1>>Log2ParMrgLevel

[1003]

[1004] The derivations of variables availableFlagA1, refIdxLXA1, predFlagLXA1, and mvLXA1 are as follows:

[1005] –If availableA1 equals FALSE The availableFlagA1 is set to 0, the two components of mvLXA1 are set to 0, refIdxLXA1 is set to -1, and predFlagLXA1 is set to 0, where X is 0 or 1, and bcwIdxA1 is set to 0.

[1006]

[1007] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[1008] mvLXA1=MvLX[xNbA1][yNbA1] (680)

[1009] refIdxLXA1=RefIdxLX[xNbA1][yNbA1] (681)

[1010] predFlagLXA1=PredFlagLX[xNbA1][yNbA1] (682)

[1011] …

[1012] 2. When sps_affine_enabled_flag equals 1, the derivation of sample point positions (xNbA0, yNbA0), (xNbA1, yNbA1), (xNbA2, yNbA2), (xNbB0, yNbB0), (xNbB1, yNbB1), (xNbB2, yNbB2), and (xNbB3, yNbB3) is as follows:

[1013] (xNbA0,yNbA0)=(xCb-1,yCb+cbHeight) (683)

[1014] (xNbA1,yNbA1)=(xCb-1,yCb+cbHeight-1) (684)

[1015] (xNbA2,yNbA2)=(xCb-1,yCb) (685)

[1016] (xNbB0,yNbB0)=(xCb+cbWidth,yCb-1) (686)

[1017] (xNbB1,yNbB1)=(xCb+cbWidth-1,yCb-1) (687)

[1018] (xNbB2,yNbB2)=(xCb-1,yCb-1) (688)

[1019] (xNbB3,yNbB3)=(xCb,yCb-1) (689)

[1020]

[1021] 3. When `sps_affine_enabled_flag` equals 1, the variable `availableFlagA` is set to `FALSE`, and the following applies to (xNbA0, yNbA0) from (xNbA1, yNbA1)... k yNbA k ):

[1022] – Invoke the derivation of the neighboring block availability specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) to be equal to (xCb, yCb) and the neighboring luminance position (xNbA). k yNbA k The input is set to checkPredModeY equal to TRUE and cIdx equal to 0, and the output is assigned to the block availability flag availableA. k .

[1023]

[1024] – When xCb >> Log2ParMrgLevel equals xNbA k >>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA k >>Log2ParMrgLevel

[1025] –When availableA k It equals TRUE and MotionModelIdc[xNbA] k ][yNbA k When ] is greater than 0 and availableFlagA equals FALSE, the following applies:

[1026] – The variable availableFlagA is set to TRUE, and motionModelIdcA is set to MotionModelIdc[xNbA]. k ][yNbA k ], (xNb, yNb) is set to equal (CbPosX[0][xNbA]). k ][yNbA k ],CbPosY[0][xNbA k ][yNbA k ]), nbW is set to be equal to CbWidth[0][xNbAk ][yNbA k ], nbH is set to equal CbHeight[0][xNbA k ][yNbA k ], numCpMv is set to equal to MotionModelIdc[xNbA k ][yNbA k +1, and set bcwIdxA to be equal to BcwIdx[xNbA] k ][yNbA k ].

[1027] – For X replaced by 0 or 1, the following applies:

[1028] –When PredFlagLX[xNbA] k ][yNbA k When ] equals 1, the derivation process of the luminance affine control point motion vector from the neighboring block specified in Clause 8.5.5.5 is invoked, taking the luminance codec block position (xCb, yCb), luminance codec block width and height (cbWidth, cbHeight), neighboring luminance codec block position (xNb, yNb), neighboring luminance codec block width and height (nbW, nbH), and the number of control point motion vectors numCpMv as input, and the control point motion vector predictor candidate cpMvLXA[cpid] as output, where cpIdx = 0..numCpMv-1.

[1029] – Make the following allocation:

[1030] predFlagLXA=PredFlagLX[xNbA k ][yNbA k (690)

[1031] refIdxLXA=RefIdxLX[xNbAk][yNbAk] (691)

[1032]

[1033]

[1034] 4. When `sps_affine_enabled_flag` equals 1, the variable `availableFlagB` is set to FALSE, and for the range from (xNbB0, yNbB0) to (xNbB2, yNbB2), the value of `(xNbB0, yNbB0)` is set to FALSE. k yNbB k The following applies:

[1035] – Invoke the derivation of the neighboring block availability specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) to be equal to (xCb, yCb) and the neighboring luminance position (xNbB) to be equal to (xCb, yCb). k yNbB k The input is set to checkPredModeY equal to TRUE and cIdx equal to 0, and the output is assigned to the block availability flag availableB. k .

[1036]

[1037] – When xCb >> Log2ParMrgLevel equals xNbB k >>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB k >>Log2ParMrgLevel

[1038] –When availableB k Equals TRUE and MotionModelIdc[xNbB] k ][yNbB k When [the value] is greater than 0 and availableFlagB equals FALSE, the following applies:

[1039] – The variable availableFlagB is set to TRUE, and motionModelIdcB is set to MotionModelIdc[xNbB] k ][yNbB k ], (xNb, yNb) is set to equal to (CbPosX[0][xNbAB][yNbB k ],CbPosY[0][xNbB k ][yNbB k ]), nbW is set to be equal to CbWidth[0][xNbB k ][yNbB k ], nbH is set to be equal to CbHeight[0][xNbB k ][yNbB k ], numCpMv is set to equal to MotionModelIdc[xNbB k ][yNbB k ]+1, and bcwIdxB is set to equal BcwIdx[xNbB k ][yNbBk ].

[1040] – For X replaced by 0 or 1, the following applies:

[1041] –When PredFlagLX[xNbB k ][yNbB k When TRUE is true, the derivation process of the luminance affine control point motion vector from the neighboring block as specified in Clause 8.5.5.5 is invoked. The luminance codec block position (xCb, yCb), luminance codec block width and height (cbWidth, cbHeight), neighboring luminance codec block position (xNb, yNb), neighboring luminance codec block width and height (nbW, nbH), and the number of control point motion vectors numCpMv are taken as inputs, and the control point motion vector predictor candidate cpMvLXB[cpIdx] is taken as output, where cpIdx = 0..numCpMv-1.

[1042] – Make the following allocation:

[1043] predFlagLXB=PredFlagLX[xNbB k ][yNbB k (692)

[1044] refIdxLXB=RefIdxLX[xNbB k ][yNbB k (693)

[1045]

[1046]

[1047] 5. When sps_affine_enabled_flag equals 1, the following applies:

[1048] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA2, yNbA2), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA2.

[1049]

[1050] – When xCb>>Log2ParMrgLevel equals xNbA2>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA2>>Log2ParMrgLevel

[1051] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) to equal (xCb, yCb), the neighboring luminance position (xNbB3, yNbB3), checkPredModeY to equal TRUE, and cIdx to equal 0 as inputs, and assign the output to the block availability flag availableB3.

[1052]

[1053] – When xCb>>Log2ParMrgLevel equals xNbB3>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB3>>Log2ParMrgLevel.

[1054]

[1055] – Invoke the derivation process specified in Clause 8.5.5.6 for constructing affine control point motion vector merge candidates, with the luma codec block position (xCb, yCb), luma codec block width and height (cbWidth, cbHeight), and availability flag. availableA0 , availableA1 , available A2 , availableB0 , availableB1 , available B2 , available B3 As input, and with the availability flag availableFlagConstK, the reference index refIdxLXConstK, the prediction list utilization flag predFlagLXConstK, the motion model index motionModelIdcConstK, the bidirectional prediction weight index bcwIdxConstK, and cpMvpLXConstK[cpIdx] as output, where X is 0 or 1, K = 1..6, and cpIdx = 0..2.

[1056] …

[1057] 5.7 Example 7

[1058] The draft working paper may be modified as follows.

[1059] 8.5.5.2 Derivation of motion vectors and reference indices in sub-block merge mode

[1060] …

[1061] The variables numSbColX, numSbColY, and the subblock merge candidate list subblockMergeCandList are derived by the following ordered steps:

[1062] 1. When sps_sbtmvp_enabled_flag equals 1, the following applies:

[1063] – For the derivation of availableFlagA1, refIdxLXA1, predFlagLXA1, and mvLXA1, the following applies:

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

[1065] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA1.

[1066]

[1067] When xCb>>Log2ParMrgLevel equals xNbA1>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA1>>Log2ParMrgLevel...

[1068]

[1069] The derivations of variables availableFlagA1, refIdxLXA1, predFlagLXA1, and mvLXA1 are as follows:

[1070] –If availableA1 equals FALSE The availableFlagA1 is set to 0, the two components of mvLXA1 are set to 0, refIdxLXA1 is set to -1, and predFlagLXA1 is set to 0, where X is 0 or 1, and bcwIdxA1 is set to 0.

[1071]

[1072] Otherwise, availableFlagA1 is set to 1 and the following allocation is performed:

[1073] mvLXA1=MvLX[xNbA1][yNbA1] (680)

[1074] refIdxLXA1=RefIdxLX[xNbA1][yNbA1] (681)

[1075] predFlagLXA1=PredFlagLX[xNbA1][yNbA1] (682)

[1076] …

[1077] 2. When sps_affine_enabled_flag equals 1, the derivation of sample point positions (xNbA0, yNbA0), (xNbA1, yNbA1), (xNbA2, yNbA2), (xNbB0, yNbB0), (xNbB1, yNbB1), (xNbB2, yNbB2), and (xNbB3, yNbB3) is as follows:

[1078] (xNbA0,yNbA0)=(xCb-1,yCb+cbHeight) (683)

[1079] (xNbA1,yNbA1)=(xCb-1,yCb+cbHeight-1) (684)

[1080] (xNbA2,yNbA2)=(xCb-1,yCb) (685)

[1081] (xNbB0,yNbB0)=(xCb+cbWidth,yCb-1) (686)

[1082] (xNbB1,yNbB1)=(xCb+cbWidth-1,yCb-1) (687)

[1083] (xNbB2,yNbB2)=(xCb-1,yCb-1) (688)

[1084] (xNbB3,yNbB3)=(xCb,yCb-1) (689)

[1085]

[1086] 3. When `sps_affine_enabled_flag` equals 1, the variable `availableFlagA` is set to `FALSE`, and the following applies to (xNbA0, yNbA0) from (xNbA1, yNbA1)... k yNbA k ):

[1087] – Invoke the derivation of the neighboring block availability specified in Clause 6.4.4, setting the current luminance position (xCurr, yCurr) and the neighboring luminance position (xNbA) to be equal to (xCb, yCb). k yNbA k The function takes checkPredModeY (set to TRUE) and cIdx (set to 0) as inputs and assigns the output to the block availability flag availableA. k .

[1088]

[1089] When xCb >> Log2ParMrgLevel equals xNbA k >>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA k >>Log2ParMrgLevel

[1090] –When availableA k It equals TRUE and MotionModelIdc[xNbA] k ][yNbA k When ] is greater than 0 and availableFlagA equals FALSE, the following applies:

[1091] – The variable availableFlagA is set to TRUE, and motionModelIdcA is set to MotionModelIdc[xNbA]. k ][yNbA k ], (xNb, yNb) is set to be equal to (CbPosX[0][xNbA k ][yNbA k ],CbPosY[0][xNbA k ][yNbA k ]), nbW is set to be equal to CbWidth[0][xNbA k ][yNbA k ], nbH is set to equal CbHeight[0][xNbA k ][yNbA k ], numCpMv is set to equal to MotionModelIdc[xNbA k ][yNbA k +1, and set bcwIdxA to be equal to BcwIdx[xNbA] k ][yNbA k ].

[1092] – For X replaced by 0 or 1, the following applies:

[1093] –When PredFlagLX[xNbA] k ][yNbA k When ] equals 1, the derivation process of the luminance affine control point motion vector from the neighboring block specified in Clause 8.5.5.5 is invoked, taking the luminance codec block position (xCb, yCb), luminance codec block width and height (cbWidth, cbHeight), neighboring luminance codec block position (xNb, yNb), neighboring luminance codec block width and height (nbW, nbH), and the number of control point motion vectors numCpMv as input, and the control point motion vector predictor candidate cpMvLXA[cpIdx] as output, where cpIdx = 0..numCpMv-1.

[1094] – Make the following allocation:

[1095] predFlagLXA=PredFlagLX[xNbA k ][yNbA k (690)

[1096] refIdxLXA=RefIdxLX[xNbAk][yNbAk] (691)

[1097]

[1098]

[1099] 4. When `sps_affine_enabled_flag` equals 1, the variable `availableFlagB` is set to `FALSE`, and the following applies to (xNbB0, yNbB0) to (xNbB2, yNbB2) (xNbB0, yNbB0). k yNbB k ):

[1100] – The derivation of the neighboring block availability specified in Clause 6.4.4 is invoked, setting the current luminance position (xCurr, yCurr) and the neighboring luminance position (xNbB) to be equal to (xCb, yCb). k yNbB k The function takes checkPredModeY (set to TRUE) and cIdx (set to 0) as inputs and assigns the output to the block availability flag availableB. k .

[1101]

[1102] When xCb >> Log2ParMrgLevel equals xNbB k >>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB k >>Log2ParMrgLevel

[1103] –When availableB k Equals TRUE and MotionModelIdc[xNbB] k ][yNbB k When [the value] is greater than 0 and availableFlagB equals FALSE, the following applies:

[1104] – The variable availableFlagB is set to TRUE, and motionModelIdcB is set to MotionModelIdc[xNbB] k ][yNbB k ], (xNb, yNb) is set to equal to (CbPosX[0][xNbAB][yNbB k ],CbPosY[0][xNbB k ][yNbB k ]), nbW is set to be equal to CbWidth[0][xNbB k ][yNbB k ], nbH is set to be equal to CbHeight[0][xNbB k ][yNbB k ], numCpMv is set to equal to MotionModelIdc[xNbB k ][yNbB k ]+1, and bcwIdxB is set to equal BcwIdx[xNbB k ][yNbB k ].

[1105] – For X replaced by 0 or 1, the following applies:

[1106] –When PredFlagLX[xNbB k ][yNbB k When TRUE is true, the derivation process of the luminance affine control point motion vector from the neighboring block as specified in Clause 8.5.5.5 is invoked. The luminance codec block position (xCb, yCb), luminance codec block width and height (cbWidth, cbHeight), neighboring luminance codec block position (xNb, yNb), neighboring luminance codec block width and height (nbW, nbH), and the number of control point motion vectors numCpMv are taken as inputs, and the control point motion vector predictor candidate cpMvLXB[cpIdx] is taken as output, where cpIdx = 0..numCpMv-1.

[1107] – Make the following allocation:

[1108] predFlagLXB=PredFlagLX[xNbB k ][yNbB k (692)

[1109] refIdxLXB=RefIdxLX[xNbB k ][yNbB k (693)

[1110]

[1111]

[1112] 5. When sps_affine_enabled_flag equals 1, the following applies:

[1113] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbA2, yNbA2), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableA2.

[1114]

[1115] – When xCb>>Log2ParMrgLevel equals xNbA2>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbA2>>Log2ParMrgLevel

[1116] – Call the derivation procedure for the availability of neighboring blocks specified in Clause 6.4.4, taking the current luminance position (xCurr, yCurr) set to equal (xCb, yCb), the neighboring luminance position (xNbB3, yNbB3), checkPredModeY set to equal TRUE, and cIdx set to equal 0 as inputs, and assign the output to the block availability flag availableB3.

[1117]

[1118] – When xCb>>Log2ParMrgLevel equals xNbB3>>Log2ParMrgLevel and yCb>>Log2ParMrgLevel equals yNbB3>>Log2ParMrgLevel.

[1119] – Invoke the derivation process specified in Clause 8.5.5.6 for constructing affine control point motion vector merge candidates, with the luma codec block position (xCb, yCb), luma codec block width and height (cbWidth, cbHeight), and availability flag. availableA0 , availableA1 , available A2 , availableB0 , availableB1 , available B2 , available B3 As input, the availability flag availableFlagConstK, the reference index refIdxLXConstK, the prediction list utilization flag predFlagLXConstK, the motion model index motionModelIdcConstK, the bidirectional prediction weight index bcwIdxConstK, and cpMvpLXConstK[cpIdx] are used as outputs, where X is 0 or 1, K = 1..6, and cpIdx = 0..2.

[1120] …

[1121] 5.8 Example 8

[1122] The draft working paper may be modified as follows.

[1123] 6.4.2 Permissible Binary Partitioning Processes

[1124] …

[1125] The derivation of the variable allowBtSplit is as follows:

[1126] – allowBtSplit will be set to FALSE if one or more of the following conditions are true:

[1127] –cbSize is less than or equal to MinBtSizeY

[1128] –cbWidth is greater than maxBtSize

[1129] –cbHeight is greater than maxBtSize

[1130] –mttdepth is greater than or equal to maxMttDepth

[1131] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[1132] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 4, and btSplit equals Split_BT_VER

[1133] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1134] –cbWidth*cbHeight equals 32, and modeType equals MODE_TYPE_INTER

[1135] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1136] –btSplit equals Split_BT_VER

[1137] –y0+CBheight is greater than pic_height_in_luma_samples

[1138] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1139] –btSplit equals Split_BT_VER

[1140] –cbHeight is greater than 64

[1141] –x0+cbWidth is greater than pic_width_in_luma_samples

[1142] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1143] –btSplit equals Split_BT_VER

[1144] –cbWidth is less than or equal to (1 < <Log2ParMrgLevel)

[1145] –cbHeight is greater than (1< <Log2ParMrgLevel)

[1146] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1147] –btSplit equals Split_BT_HOR

[1148] –cbWidth is greater than 64

[1149] –y0+cbHeight is greater than pic_height_in_luma_samples

[1150] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1151] –btSplit equals Split_BT_HOR

[1152] –cbHeight is less than or equal to (1< <Log2ParMrgLevel)

[1153] –cbWidth is greater than (1 < <Log2ParMrgLevel)

[1154] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1155] –x0+cbWidth is greater than pic_width_in_luma_samples

[1156] –y0+cbHeight is greater than pic_height_in_luma_samples

[1157] –cbWidth is greater than minQtSize

[1158] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1159] –btSplit equals Split_BT_HOR

[1160] –x0+cbWidth is greater than pic_width_in_luma_samples

[1161] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[1162] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true:

[1163] –mttDepth is greater than 0

[1164] –partIdx equals 1

[1165] –MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[1166] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1167] –btSplit equals Split_BT_VER

[1168] –cbWidth is less than or equal to 64

[1169] –cbHeight is greater than 64

[1170]

[1171] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1172] –btSplit equals Split_BT_HOR

[1173] –cbWidth is greater than 64

[1174] –cbHeight is less than or equal to 64

[1175]

[1176] Otherwise, allowBtSplit is set to TRUE.

[1177] …

[1178] 6.4.3 Permissible ternary partitioning processes

[1179] …

[1180] The derivation of the variable allowTtSplit is as follows:

[1181] – allowTtSplit will be set to FALSE if one or more of the following conditions are true:

[1182] –cbSize is less than or equal to 2*MinTtSizeY

[1183] –cbWidth is greater than Min(64, maxTtSize)

[1184] –cbHeight is greater than Min(64, maxTtSize)

[1185]

[1186] –mttDepth is greater than or equal to maxMttDepth

[1187] –x0+cbWidth is greater than pic_width_in_luma_samples

[1188] –y0+cbHeight is greater than pic_height_in_luma_samples

[1189] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[1190] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 8, and ttSplit equals Split_TT_VER

[1191] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1192] –cbWidth*cbHeight equals 64, and modeType equals MODE_TYPE_INTER

[1193] Otherwise, allowTtSplit is set to TRUE.

[1194] …

[1195] 5.9 Example 9

[1196] The draft working paper may be modified as follows.

[1197] 6.4.2 Permissible Binary Partitioning Processes

[1198] …

[1199] The derivation of the variable allowBtSplit is as follows:

[1200] – allowBtSplit will be set to FALSE if one or more of the following conditions are true:

[1201] –cbSize is less than or equal to MinBtSizeY

[1202] –cbWidth is greater than maxBtSize

[1203] –cbHeight is greater than maxBtSize

[1204] –mttDepth is greater than or equal to maxMttDepth

[1205] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[1206] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 4, and btSplit equals Split_BT_VER

[1207] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1208] –cbWidth*cbHeight equals 32, and modeType equals MODE_TYPE_INTER

[1209]

[1210] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1211] –btSplit equals Split_BT_VER

[1212] –y0+cbHeight is greater than pic_height_in_luma_samples

[1213] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1214] –btSplit equals Split_BT_VER

[1215] –cbHeight is greater than 64

[1216] –x0+cbWidth is greater than pic_width_in_luma_samples

[1217] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1218] –btSplit equals Split_BT_VER

[1219] –cbWidth is less than or equal to (1 < <Log2ParMrgLevel)

[1220] –cbHeight is greater than (1< <Log2ParMrgLevel)

[1221] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1222] –btSplit equals Split_BT_HOR

[1223] –cbWidth is greater than 64

[1224] –y0+cbHeight is greater than pic_height_in_luma_samples

[1225] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1226] –btSplit equals Split_BT_HOR

[1227] –cbHeight is less than or equal to (1< <Log2ParMrgLevel)

[1228] –cbWidth is greater than (1 < <Log2ParMrgLevel)

[1229] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1230] –x0+cbWidth is greater than pic_width_in_luma_samples

[1231] –y0+cbHeight is greater than pic_height_in_luma_samples

[1232] –cbWidth is greater than minQtSize

[1233] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1234] –btSplit equals Split_BT_HOR

[1235] –x0+cbWidth is greater than pic_width_in_luma_samples

[1236] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[1237] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true:

[1238] –mttDepth is greater than 0

[1239] –partIdx equals 1

[1240] –MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[1241] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1242] –btSplit equals Split_BT_VER

[1243] –cbWidth is less than or equal to 64

[1244] –cbHeight is greater than 64

[1245] —Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1246] –btSplit equals Split_BT_HOR

[1247] –cbWidth is greater than 64

[1248] –cbHeight is less than or equal to 64

[1249] Otherwise, allowBtSplit is set to TRUE.

[1250] …

[1251] 6.4.3 Permissible ternary partitioning processes

[1252] …

[1253] The derivation of the variable allowTtSplit is as follows:

[1254] – allowTtSplit will be set to FALSE if one or more of the following conditions are true:

[1255] –cbSize is less than or equal to 2*MinTtSizeY

[1256] –cbWidth is greater than Min(64, maxTtSize)

[1257] –cbHeight is greater than Min(64, maxTtSize)

[1258]

[1259] –mttDepth is greater than or equal to maxMttDepth

[1260] –x0+cbWidth is greater than pic_width_in_luma_samples

[1261] –y0+cbHeight is greater than pic_height_in_luma_samples

[1262] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[1263] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 8, and ttSplit equals Split_TT_VER

[1264] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1265] –cbWidth*cbHeight equals 64, and modeType equals MODE_TYPE_INTER

[1266] Otherwise, allowTtSplit is set to TRUE.

[1267] 5.10 Example 10

[1268] The draft working paper may be modified as follows.

[1269] 6.4.2 Permissible Binary Partitioning Processes

[1270] …

[1271] The derivation of the variable allowBtSplit is as follows:

[1272] – allowBtSplit will be set to FALSE if one or more of the following conditions are true:

[1273] –cbSize is less than or equal to MinBtSizeY

[1274] –cbWidth is greater than maxBtSize

[1275] –cbHeight is greater than maxBtSize

[1276] –mttDepth is greater than or equal to maxMttDepth

[1277] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[1278] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 4, and btSplit equals Split_BT_VER

[1279] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1280] –cbWidth*cbHeight equals 32, and modeType equals MODE_TYPE_INTER

[1281]

[1282] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1283] –btSplit equals Split_BT_VER

[1284] –y0+cbHeight is greater than pic_height_in_luma_samples

[1285] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1286] –btSplit equals Split_BT_VER

[1287] –cbHeight is greater than 64

[1288] –x0+cbWidth is greater than pic_width_in_luma_samples

[1289] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1290] –btSplit equals Split_BT_VER

[1291] –cbWidth is less than or equal to (1 < <Log2ParMrgLevel)

[1292] –cbHeight is greater than (1< <Log2ParMrgLevel)

[1293] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1294] –btSplit equals Split_BT_HOR

[1295] –cbWidth is greater than 64

[1296] –y0+cbHeight is greater than pic_height_in_luma_samples

[1297] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1298] –btSplit equals Split_BT_HOR

[1299] –cbHeight is less than or equal to (1< <Log2ParMrgLevel)

[1300] –cbWidth is greater than (1 < <Log2ParMrgLevel)

[1301] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1302] –x0+cbWidth is greater than pic_width_in_luma_samples

[1303] –y0+cbHeight is greater than pic_height_in_luma_samples

[1304] –cbWidth is greater than minQtSize

[1305] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1306] –btSplit equals Split_BT_HOR

[1307] –x0+cbWidth is greater than pic_width_in_luma_samples

[1308] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[1309] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true:

[1310] –mttDepth is greater than 0

[1311] –partIdx equals 1

[1312] –MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[1313] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1314] –btSplit equals Split_BT_VER

[1315] –cbWidth is less than or equal to 64

[1316] –cbHeight is greater than 64

[1317] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1318] –btSplit equals Split_BT_HOR

[1319] –cbWidth is greater than 64

[1320] –cbHeight is less than or equal to 64

[1321] Otherwise, allowBtSplit is set to TRUE.

[1322] …

[1323] 6.4.3 Permissible ternary partitioning processes

[1324] …

[1325] The derivation of the variable allowTtSplit is as follows:

[1326] – allowTtSplit will be set to FALSE if one or more of the following conditions are true:

[1327] –cbSize is less than or equal to 2*MinTtSizeY

[1328] –cbWidth is greater than Min(64, maxTtSize)

[1329] –cbHeight is greater than Min(64, maxTtSize)

[1330]

[1331] –mttDepth is greater than or equal to maxMttDepth

[1332] –x0+cbWidth is greater than pic_width_in_luma_samples

[1333] –y0+cbHeight is greater than pic_height_in_luma_samples

[1334] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[1335] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 8, and ttSplit equals Split_TT_VER

[1336] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1337] –cbWidth*cbHeight equals 64, and modeType equals MODE_TYPE_INTER

[1338] Otherwise, allowTtSplit is set to TRUE.

[1339] …

[1340] 5.11 Example 11

[1341] The draft working paper may be modified as follows.

[1342] 6.4.2 Permissible Binary Partitioning Processes

[1343] …

[1344] The derivation of the variable allowBtSplit is as follows:

[1345] – allowBtSplit will be set to FALSE if one or more of the following conditions are true:

[1346] –cbSize is less than or equal to MinBtSizeY

[1347] –cbWidth is greater than maxBtSize

[1348] –cbHeight is greater than maxBtSize

[1349] –mttDepth is greater than or equal to maxMttDepth

[1350] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[1351] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 4, and btSplit equals Split_BT_VER

[1352] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1353] –cbWidth*cbHeight equals 32, and modeType equals MODE_TYPE_INTER

[1354]

[1355]

[1356] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1357] –btSplit equals Split_BT_VER

[1358] –y0+cbHeight is greater than pic_height_in_luma_samples

[1359] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1360] –btSplit equals Split_BT_VER

[1361] –cbHeight is greater than 64

[1362] –x0+cbWidth is greater than pic_width_in_luma_samples

[1363] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1364] –btSplit equals Split_BT_VER

[1365] –cbWidth is less than or equal to (1 < <Log2ParMrgLevel)

[1366] –cbHeight is greater than (1< <Log2ParMrgLevel)

[1367] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1368] –btSplit equals Split_BT_HOR

[1369] –cbWidth is greater than 64

[1370] –y0+cbHeight is greater than pic_height_in_luma_samples

[1371] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1372] –btSplit equals Split_BT_HOR

[1373] –cbHeight is less than or equal to (1< <Log2ParMrgLevel)

[1374] –cbWidth is greater than (1 < <Log2ParMrgLevel)

[1375] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1376] –x0+cbWidth is greater than pic_width_in_luma_samples

[1377] –y0+cbHeight is greater than pic_height_in_luma_samples

[1378] –cbWidth is greater than minQtSize

[1379] —Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1380] –btSplit equals Split_BT_HOR

[1381] –x0+cbWidth is greater than pic_width_in_luma_samples

[1382] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[1383] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true:

[1384] –mttDepth is greater than 0

[1385] –partIdx equals 1

[1386] –MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[1387] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1388] –btSplit equals Split_BT_VER

[1389] –cbWidth is less than or equal to 64

[1390] –cbHeight is greater than 64

[1391] Otherwise, allowBtSplit will be set to FALSE if all of the following conditions are true.

[1392] –btSplit equals Split_BT_HOR

[1393] –cbWidth is greater than 64

[1394] –cbHeight is less than or equal to 64

[1395] Otherwise, allowBtSplit is set to TRUE.

[1396] …

[1397] 6.4.3 Permissible ternary partitioning processes

[1398] …

[1399] The derivation of the variable allowTtSplit is as follows:

[1400] – allowTtSplit will be set to FALSE if one or more of the following conditions are true:

[1401] –cbSize is less than or equal to 2*MinTtSizeY

[1402] –cbWidth is greater than Min(64, maxTtSize)

[1403] –cbHeight is greater than Min(64, maxTtSize)

[1404]

[1405]

[1406] –mttDepth is greater than or equal to maxMttDepth

[1407] –x0+cbWidth is greater than pic_width_in_luma_samples

[1408] –y0+cbHeight is greater than pic_height_in_luma_samples

[1409] –treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[1410] –treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 8, and ttSplit equals Split_TT_VER

[1411] –treeType equals DUAL_TREE_CHROMA, and modeType equals MODE_TYPE_INTRA

[1412] –cbWidth*cbHeight equals 64, and modeType equals MODE_TYPE_INTER

[1413] —Otherwise, allowTtSplit is set to TRUE.

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

[1415] System 1900 may include a codec component 1904 capable of implementing the various codec or encoding methods described in this document. Codec component 1904 can reduce the average bit rate of the video from input 1902 to the output of codec component 1904 to produce a codec representation of the video. Therefore, codec techniques are sometimes referred to as video compression or video transcoding techniques. The output of codec component 1904 may be stored or transmitted via a communication connection as represented by component 1906. The stored or communicated bitstream (or codec) representation of the video received at input 1902 may be used by component 1908 to generate pixel values ​​or displayable video that are sent to display interface 1910. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although some video processing operations are referred to as "codec" operations or tools, it should be understood that the codec tool or operation is used at the encoder, and the corresponding decoding tool or operation will be inverted by the decoder to retrieve the result of the codec.

[1416] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or DisplayPort. Examples of storage interfaces include SATA (Serial Advanced Technology Accessory), PCI, IDE, etc. The technologies described in this document can be implemented in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[1417] Figure 28This is a block diagram of a video processing apparatus 3600. Apparatus 3600 can be used to implement one or more of the methods described herein. Apparatus 3600 can be implemented in smartphones, tablets, computers, Internet of Things (IoT) receivers, etc. Apparatus 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. The processors(multiple) 3602 can be configured to implement one or more methods described in this document. The memories(multiple) 3604 can be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 3606 can be used to implement some of the techniques described in this document in hardware circuitry.

[1418] Figure 30 This is a block diagram illustrating an example video encoding / decoding system 100 that can utilize the techniques disclosed herein.

[1419] like Figure 30 As shown, the video encoding / decoding system 100 may include a source device 110 and a target device 120. The source device 110 generates encoded video data and may be referred to as a video encoding device. The target device 120 can decode the encoded video data generated by the source device 110 and may be referred to as a video decoding device.

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

[1421] Video source 112 may include sources such as video capture devices, interfaces for receiving video data from video content providers, and / or computer graphics systems that generate video data, or combinations of these sources. Video data may include one or more images. Video encoder 114 encodes the video data from video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming a codec representation of the video data. The bitstream may include codec images and associated data. A codec image is a codec representation of an image. Associated data may include sequence parameter sets, image parameter sets, and other syntax elements. I / O interface 116 includes a modulator / demodulator (modem) and / or a transmitter. Encoded video data may be transmitted directly to target device 120 via network 130a through I / O interface 116. Encoded video data may also be stored on storage medium / server 130b for access by target device 120.

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

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

[1424] The video encoder 114 and the video decoder 124 can operate according to video compression standards such as High Efficiency Video Codec (HEVC), Multi-Functional Video Codec (VVC), and other current and / or other standards.

[1425] Figure 31 This is a block diagram illustrating an example of a video encoder 200, which can be... Figure 30 The video encoder 114 in the system 100 shown in the figure.

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

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

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

[1429] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, can be highly integrated, but for interpretive purposes... Figure 31 The examples are shown separately.

[1430] The segmentation unit 201 can segment an image into one or more video blocks. The video encoder 200 and the video decoder 300 can support various video block sizes.

[1431] The mode selection unit 203 can, for example, select one of the intra-frame or inter-frame encoding / decoding modes based on the error result, and provide the obtained intra-frame or inter-frame encoded / decoded blocks to the residual generation unit 207 to generate residual block data and to the reconstruction unit 212 to reconstruct the encoded blocks for use as reference images. In some examples, the mode selection unit 203 can select a combined intra-frame and inter-frame prediction (CIIP) mode, where the prediction is based on the inter-frame prediction signal and the intra-frame prediction signal. The mode selection unit 203 can also select the resolution of the motion vector (e.g., sub-pixel or full-pixel precision) for the blocks in the inter-frame prediction case.

[1432] To perform inter-frame prediction on the current video block, motion estimation unit 204 can generate motion information for the current video block by comparing one or more reference frames from buffer 213 with the current video block. Motion compensation unit 205 can determine the predicted video block for the current video block based on the motion information of the image from buffer 213 (rather than the image associated with the current video block) and decoded samples.

[1433] The motion estimation unit 204 and the motion compensation unit 205 can perform different operations on the current video block, for example, the different operations performed depend on whether the current video block is in an I-strip, a P-strip, or a B-strip.

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

[1435] In other examples, motion estimation unit 204 can perform bidirectional prediction of the current video block. Motion estimation unit 204 can search for a reference video block for the current video block in the reference images of list 0 and can also search for another reference video block for the current video block in the reference images of list 1. Motion estimation unit 204 can then generate a reference index indicating that the reference images in list 0 or list 1 contain the reference video block, and a motion vector indicating the spatial displacement between the reference video block and the current video block. Motion estimation unit 204 can output the reference index and the motion vector of the current video block as the motion information of the current video block. Motion compensation unit 205 can generate a predicted video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[1436] In some examples, the motion estimation unit 204 can output the complete set of motion information for the decoder's decoding process.

[1437] In some examples, motion estimation unit 204 may not output the complete set of motion information for the current video. Instead, motion estimation unit 204 may signal the motion information of the current video block by referencing the motion information of another video block. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.

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

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

[1440] As discussed above, the video encoder 200 can predictively signal motion vectors. Two examples of predictive signaling notification techniques that can be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and merge pattern signaling notification.

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

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

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

[1444] The transform processing unit 208 can generate one or more transform coefficient video blocks of the current video block by applying one or more transforms to the residual video block associated with the current video block.

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

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

[1447] After the video block is reconstructed in reconstruction unit 212, a loop filtering operation can be performed to reduce video block artifacts in the video block.

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

[1449] Figure 32 This is a block diagram illustrating an example of a video decoder 300, which can be... Figure 30 The video decoder 114 in the system 100 shown in the figure.

[1450] The video decoder 300 can be configured to perform any or all of the techniques disclosed herein. Figure 32 In the example, the video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video decoder 300. In some examples, the processor can be configured to perform any or all of the techniques described in this disclosure.

[1451] exist Figure 32 In the example, the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 can perform operations related to the video encoder 200 ( Figure 31 The decoding process is the overall inversion of the encoding process described.

[1452] The entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 can decode the entropy-coded video, and based on the entropy-coded video data, the motion compensation unit 302 can determine motion information including motion vectors, motion vector precision, reference image list index, and other motion information. The motion compensation unit 302 can determine this information, for example, by performing AMVP and merge modes.

[1453] The motion compensation unit 302 can generate motion compensation blocks, possibly based on interpolation filters. The identifier of the interpolation filter to be used at sub-pixel precision can be included in the syntax element.

[1454] The motion compensation unit 302 can use the interpolation filter used by the video encoder 200 during the encoding of the video block to calculate the interpolation values ​​of a sub-integer number of pixels of the reference block. The motion compensation unit 302 can determine the interpolation filter used by the video encoder 200 based on the received syntax information and use the interpolation filter to generate the prediction block.

[1455] The motion compensation unit 302 can use some syntactic information to determine: the size of the blocks used to encode (multiple) frames and / or (multiple) stripes of the encoded video sequence, segmentation information describing how each macroblock of the image of the encoded video sequence is segmented, a mode indicating how each segment is encoded, one or more reference frames (and a list of reference frames) for each inter-frame coded block, and other information for decoding the encoded video sequence.

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

[1457] The reconstruction unit 306 can sum the residual blocks using the corresponding prediction blocks generated by the motion compensation unit 202 or the intra-frame prediction unit 303 to form a decoded block. As desired, a deblocking filter can also be applied to filter the decoded block to remove blocking artifacts. The decoded video block is then stored in a buffer 307, which provides a reference block for subsequent motion compensation / intra-frame prediction and also produces the decoded video for presentation on the display device.

[1458] The following provides a list of preferred embodiments.

[1459] The following scheme shows an example implementation of the technology discussed in the previous chapter (e.g., Project 1).

[1460] 1. A method for video processing (e.g., Figure 29 The method described in (2900) includes: for the conversion between video blocks of a video region and the codec representation of the video, maintaining (2902) a list of block vector (BV) candidates based on a selection rule that selectively specifies included candidates based on the merge estimation region (MER) of the video blocks; and performing (2904) a conversion based on the list of BV candidates.

[1461] 2. The method according to Scheme 1, wherein the video block is encoded and decoded using the Intra-Block Copy (IBC) mode.

[1462] 3. The method according to any one of Schemes 1-2, wherein the selection rule specifies that candidates are excluded from the blocks below the MER of the video block.

[1463] 4. The method according to any one of schemes 1-3, wherein the selection rule specifies that blocks other than MER and / or candidate and / or default block vector candidates in the motion vector prediction table based on block vector history.

[1464] The following schemes show example implementations of the techniques discussed in the previous chapter (e.g., Items 2-3).

[1465] 5. A video processing method, comprising: determining a conversion between video blocks and a codec representation of the video; and processing a candidate list based on block vector history, the list following the rule that the list is not updated when the video block is in a merge estimation region (MER) in a first case, or when the list has been updated once previously within the MER in a second case.

[1466] 6. The method according to Scheme 5, wherein the rule specifies that the list is updated only when the bottom right corner of the video block coincides with the bottom right corner of the MER, provided that the video block is within the MER.

[1467] The following scheme shows an example implementation of the technology discussed in the previous chapter (e.g., Project 4).

[1468] 7. A video processing method, comprising: a conversion between video blocks and a codec representation of the video; maintaining a list of motion candidates; selectively adding candidates of neighboring blocks of merge estimated regions (MERs) from the video blocks to the list based on rules; and performing the conversion based on the list of motion candidates.

[1469] 8. The method according to scheme 7, wherein the rule specifies that the neighboring blocks of the MER are checked if the neighboring blocks of the video block are not available to be added to the list.

[1470] 9. The method according to scheme 7, wherein the rule specifies that the neighboring blocks of MER are checked after all available neighboring blocks of the video block are checked.

[1471] 10. The method according to scheme 7, wherein the rule specifies the order in which the neighboring blocks of MER are checked after all historical motion vector prediction candidates are checked.

[1472] 11. The method according to any one of schemes 7-10, wherein the rule specifies that at most X candidates from the neighboring blocks of MER are added to the list, where X is an integer.

[1473] 12. The method according to scheme 11, wherein X = 2.

[1474] 13. The method according to scheme 7, wherein the rule specifies a predefined order in which neighboring blocks of MER are added to the list.

[1475] 14. The method according to scheme 7, wherein the rule specifies that the neighboring blocks of the MER located at the adaptive position are checked so as to check at least two blocks in different ways.

[1476] 15. The method according to scheme 7, wherein the rule specifies that the addition of the list is restricted to the neighboring blocks of the MER that meet the location condition or availability condition.

[1477] 16. The method according to scheme 15, wherein the location condition specifies that motion candidates from at least one location other than MER are used to add to the list.

[1478] The following scheme shows an example implementation of the technology discussed in the previous chapter (e.g., Project 5).

[1479] 17. A video processing method comprising: a conversion between video blocks and a codec representation of the video; maintaining a list of motion candidates, the size of which depends on whether the video blocks are below a merge estimation region (MER) according to a size rule; and performing the conversion based on the list of motion candidates.

[1480] 18. The method according to Scheme 17, wherein the size rule specifies that the size of the list of blocks under MER is different from the size of the list of blocks under MER.

[1481] 19. The method according to any one of schemes 17-18, wherein the fields in the encoding / decoding representation correspond to the maximum size of the list.

[1482] 20. The method according to Scheme 19, wherein the field is included at the sequence level, image level, strip level, or slice group level.

[1483] 21. The method according to any one of Schemes 19-20, wherein the field is included in a sequence header or image header or sequence parameter set or video parameter set or image parameter set or adaptive parameter set or strip header or slice header.

[1484] The following scheme shows an example implementation of the technology discussed in the previous chapter (e.g., Project 6).

[1485] 22. A video processing method, comprising: determining the position of a video block relative to a corresponding merge estimation region, and performing a conversion between the video block and a codec representation of the video by selecting a motion list construction process based on rules depending on the position.

[1486] 23. The method according to scheme 22, wherein the location includes the exact location of the video block within the merge estimation region.

[1487] 24. The method according to scheme 23, wherein the rule specifies that different motion list construction processes are used for blocks with complete internal locations and remaining blocks.

[1488] The following scheme shows an example implementation of the technology discussed in the previous chapter (e.g., Item 7).

[1489] 25. A video processing method comprising: determining, for a video block of a video, characteristics of a merge estimation region of the video block; and performing a conversion between the video block and a codec representation of the video, wherein a tree partitioning pattern used during the conversion depends on the characteristics according to a rule.

[1490] 26. The method according to scheme 25, wherein the rule disables horizontal binary tree partitioning of video blocks because the width W of the video block is greater than R1 and / or the height H of the video block is less than or equal to R2, where R1 and R2 are rational numbers.

[1491] 27. The method according to scheme 25, wherein the rule disables horizontal binary tree partitioning of video blocks because the width W of the video block is less than or equal to R1 and / or the height H of the video block is greater than R2, wherein R1 and R2 are rational numbers.

[1492] 28. The method according to any one of claims 1 to 27, wherein the conversion includes encoding the video into a codec representation.

[1493] 29. The method according to any one of claims 1 to 27, wherein the conversion includes decoding the encoding / decoding representation to generate pixel values ​​of the video.

[1494] 30. A video decoding apparatus, comprising a processor configured to perform the method described in one or more of embodiments 1 to 29.

[1495] 31. A video encoding apparatus, comprising a processor configured to perform the method described in one or more of embodiments 1 to 29.

[1496] 32. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method described in any one of 1 to 29.

[1497] 33. The methods, apparatus or systems described in this document.

[1498] Figure 34 A flowchart of an example method for video processing is shown. The method includes: for a conversion between a current video block and a bitstream of the video, determining (3402) one or more block vector (BV) candidates for the current video block based on a merge estimation region (MER) covering the current video block; adding (3404) the one or more BV candidates to a BV list associated with the current video block; and performing a conversion based on the BV list (3406).

[1499] In some examples, the current video block is an intra-block copy (IBC) codec block.

[1500] In some examples, BV candidates from spatially adjacent neighboring blocks or / and spatially adjacent non-adjacent blocks under MER are not added to the BV list.

[1501] In some examples, only BV candidates from spatially adjacent neighboring blocks or / and spatially adjacent non-neighboring blocks outside of MER, or / and BV candidates from the IBC history-based motion vector prediction (HMVP) table, or / and default BV candidates are added to the BV list.

[1502] In some examples, BV candidates from adjacent blocks in the airspace are not added to the BV list.

[1503] In some examples, BV candidates from the IBC HMVP table are added to the BV list in a predefined order, or / and no pruning is performed when the BV candidate is added.

[1504] In some examples, the order is based on ascending or descending order of the table's entry index.

[1505] In some examples, the first N entries in the table are skipped.

[1506] In some examples, the last N entries in the table are skipped.

[1507] In some examples, entries with (multiple) invalid BVs are skipped.

[1508] In some examples, BV candidates from the IBC HMVP table are modified before being added to the BV list.

[1509] In some examples, offsets are added to the horizontal and / or vertical components of the BV candidates from the IBC HMVP table.

[1510] In some examples, HMVP candidates with (multiple) invalid BVs are modified to candidates with (multiple) valid BVs.

[1511] In some examples, one or more default BV candidates are added after or before one or more HMVP BV candidates, where the default BV candidates are defined as (BVx, BVy).

[1512] In some examples, BVx = 0, BVy = 0.

[1513] In some examples, BVx = –W, BVy = –H, where W and H are the width and height of the current video block.

[1514] In some examples, the BV list refers to the IBC AMVP list and / or IBC merge list associated with the current video block.

[1515] In some examples, the IBC HMVP table is not updated after decoding the current video block under MER.

[1516] In some examples, the IBC HMVP table is updated only once for video blocks within the MER.

[1517] In some examples, the IBC HMVP table is updated only if the current video block is not within the MER, or if the bottom right corner of the current video block coincides with the bottom right corner of the MER.

[1518] Figure 35 A flowchart of an example method for video processing is shown. The method includes: for a conversion between a current video block and a bitstream of the video, during the motion candidate list construction process, determining (3502) one or more motion candidates for the current video block based on the merge estimation region (MER) covering the current video block; during the motion candidate list construction process, adding (3504) one or more motion candidates to the motion candidate list associated with the current video block; and performing a conversion based on the motion candidate list (3506).

[1519] In some examples, the motion candidate list includes a block vector (BV) candidate list, a normal merge list, or a sub-block merge list.

[1520] In some examples, motion candidates from MER spatial neighbor blocks are used during the motion candidate list construction process. MER spatial neighbor blocks include MER spatial neighbor blocks and / or MER spatial neighbor non-neighbor blocks.

[1521] In some examples, when the spatial neighboring block of the current video block is not available, the spatial neighboring block of the MER is checked during the motion candidate list construction process.

[1522] In some examples, if motion information of the spatial neighboring blocks of the MER is available, the motion information is used to derive motion candidates, which are then directly added to the motion candidate list as replacements for motion candidates derived from the spatial neighboring blocks.

[1523] In some examples, during the motion candidate list construction process, after checking all spatial neighboring blocks of the current video block, the MER spatial neighboring blocks are checked.

[1524] In some examples, motion candidates from neighboring blocks in the MER spatial domain are added to the motion candidate list following the spatial domain merge candidate.

[1525] In some examples, after examining all historical motion vector prediction (HMVP) candidates, the spatial neighboring blocks of the MER are checked.

[1526] In some examples, motion candidates from neighboring blocks in the MER spatial domain are added to the motion candidate list following the HMVP candidate.

[1527] In some examples, up to X candidates from the MER neighboring blocks are added to the motion candidate list, where X is an integer.

[1528] In some examples, X = 2.

[1529] In some examples, during the motion candidate list construction process, the MER spatial neighboring blocks at fixed positions are checked and the motion information from those fixed positions is used.

[1530] In some examples, for two blocks within the same MER, the same set of allowed MER spatial neighboring blocks is defined, and only those blocks in the set are checked and used.

[1531] In some examples, only one or more of the MER spatial neighboring adjacent blocks in the set are checked and used.

[1532] In some examples, only one or more of the MER spatial neighboring non - adjacent blocks in the set are checked and used.

[1533] In some examples, when the neighboring adjacent blocks of the current video block are not available, the corresponding MER spatial neighboring blocks are alternatively used by assuming that the size of the current video block is equal to the size of the MER, where the upper - left position of the current video block relative to the upper - left sample point of the current picture is represented by (x0, y0), the block width is represented by bW, the block height is represented by bH, the MER width is represented by mW, and the MER height is represented by mH.

[1534] In some examples, if the left block located at (x0 - 1, y0 + bH - 1) is not available, the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH)+mH - 1) is used.

[1535] In some examples, if the lower - left block located at (x0 - 1, y0 + bH) is not available, the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH)+mH) is used.

[1536] In some examples, if the upper - right block located at (x0 + bW, y0 - 1) is not available, the block located at ((x0 >> Log2(mW)) << Log2(mW)+mW, (y0 >> Log2(mH)) << Log2(mH)-l) is used.

[1537] In some examples, if the upper block located at ((x0 >> Log2(mW)) << Log2(mW) + mW - 1, y0 - 1) is unavailable, the block located at (x0 + bW - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) is used.

[1538] In some examples, if the upper-left block located at (x0 - 1, y0 - 1) is unavailable, the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) is used.

[1539] In some examples, during the construction of the motion candidate list, the MER spatial neighboring blocks at the adaptive positions are checked and the motion information from those adaptive positions is used.

[1540] In some examples, at least for two blocks below the MER, at least one of the blocks to be checked is different.

[1541] In some examples, when the neighboring adjacent blocks of the current video block are unavailable, the corresponding MER spatial neighboring blocks are alternatively used by assuming that the size of the current video block is equal to the size of the MER, where the upper-left position of the current video block relative to the upper-left sample of the current picture is represented by (x0, y0), the block width is represented by bW, the block height is represented by bH, the MER width is represented by mW, and the MER height is represented by mH.

[1542] In some examples, if the left block located at (x0 - 1, y0 + bH - 1) is unavailable, the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, y0 + bH - 1) is used.

[1543] In some examples, if the lower-left block located at (x0 - 1, y0 + bH) is unavailable, the block located at ((x0 >> Log2(mW)) << Log2(mW) - 1, y0 + bH) is used.

[1544] In some examples, if the upper-right block located at (x0 + bW, y0 - 1) is unavailable, the block located at (x0 + bW, (y0 >> Log2(mH)) << Log2(mH) - 1) is used.

[1545] In some examples, if the upper block located at ((x0 >> Log2(mW)) << Log2(mW) + mW - 1, y0 - 1) is unavailable, the block located at (x0 + bW - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) is used.

[1546] In some examples, if the upper left block at (x0 - 1, y0 - 1) is unavailable, then the block at ((x0 >> Log2(mW)) << Log2(mW) - 1, (y0 >> Log2(mH)) << Log2(mH) - 1) is used.

[1547] In some examples, for different blocks within the same MER, different sets of allowed MER spatial neighboring blocks associated with the different blocks are defined, and only those blocks within the same set are checked and used.

[1548] In some examples, only one or more of the MER spatial neighboring adjacent blocks (C0, C1, D0, D1, and D2) in the first set associated with the first block are checked and used.

[1549] In some examples, only one or more of the MER spatial neighboring non - adjacent blocks (E0, E1, F0, F1, and F2) in the first set associated with the first block are checked and used.

[1550] In some examples, only one or more of the MER spatial neighboring adjacent blocks (C'0, C'1, D'0, D'1, and D'2) in the second set associated with the second block are checked and used.

[1551] In some examples, only one or more of the MER spatial neighboring non - adjacent blocks (E'0, E'1, F'0, F'1, and F'2) in the second set associated with the second block are checked and used.

[1552] In some examples, whether to add a motion candidate from a MER spatial neighboring block to the motion candidate list depends on the position or / and availability of the MER spatial neighboring block.

[1553] In some examples, during the process of constructing the motion candidate list, motion candidates from at least one of the MER spatial neighboring adjacent blocks or / and MER spatial neighboring non - adjacent blocks outside the MER are used.

[1554] In some examples, the motion candidates include IBC candidates, or normal inter - frame candidates, or sub - block candidates including affine candidates.

[1555] In some examples, a motion candidate at a specific position is added to the motion candidate list.

[1556] In some examples, the specific position includes the left neighboring adjacent block and the upper neighboring adjacent block, or the left neighboring non - adjacent block and the upper neighboring non - adjacent block.

[1557] In some examples, the specific position includes the upper neighboring adjacent block and the left neighboring adjacent block, or the upper neighboring non - adjacent block and the left neighboring non - adjacent block.

[1558] In some examples, specific locations include left adjacent neighbor block, top adjacent neighbor block and top left adjacent neighbor block, or left adjacent non-adjacent block, top adjacent non-adjacent block and top left adjacent non-adjacent block.

[1559] In some examples, specific locations include the top neighboring block and the top left neighboring block, or the top non-neighboring block and the top left non-neighboring block.

[1560] In some examples, specific locations include the left nearest neighbor block and the top left nearest neighbor block, or the left nearest non-neighbor block and the top left nearest non-neighbor block.

[1561] In some examples, motion candidates from neighboring blocks in the airspace are inserted into the motion candidate list in a predefined order.

[1562] In some examples, the predefined order is left adjacent neighbor block, bottom left adjacent neighbor block, top right adjacent neighbor block, top adjacent neighbor block and top left adjacent neighbor block, or left adjacent non-adjacent block, bottom left adjacent non-adjacent block, top right adjacent non-adjacent block, top adjacent non-adjacent block and top left adjacent non-adjacent block.

[1563] In some examples, the predefined order is top adjacent block, top right adjacent block, left adjacent block, bottom left adjacent block and top left adjacent block, or top non-adjacent block, top right non-adjacent block, left non-adjacent block, bottom left non-adjacent block and top left non-adjacent block.

[1564] In some examples, the predefined order is top-left adjacent block, left adjacent block, top adjacent block, bottom-left adjacent block and top-right adjacent block, or top-left non-adjacent block, left non-adjacent block, top non-adjacent block, bottom-left non-adjacent block and top-right non-adjacent block.

[1565] In some examples, during the motion candidate list construction process, BV candidates are used from at least one of the following: lower left neighbor non-adjacent block, left neighbor non-adjacent block, upper right neighbor non-adjacent block, upper left neighbor non-adjacent block, and upper neighbor non-adjacent block, which are outside of the MER.

[1566] In some examples, MER spatial neighbor blocks are only determined to be available if the block is encoded or decoded in a specific mode.

[1567] In some examples, specific modes include the IBC mode.

[1568] In some examples, specific modes include normal inter-frame mode.

[1569] In some examples, normal inter-frame modes include inter-frame modes based on translation motion.

[1570] In some examples, neighboring blocks of the current video block used in the motion candidate list construction are considered unavailable if they are outside the MER.

[1571] In some examples, motion candidates from neighboring blocks in the MER spatial domain are added to the motion candidate list via a pruning operation.

[1572] In some examples, a motion candidate is not added to the motion candidate list when its motion information already exists in the list.

[1573] In some examples, two motion candidates from neighboring blocks in the MER spatial domain are compared to determine whether the two motion candidates are the same or similar, and only when the two motion candidates are not the same or similar are they added to the motion candidate list.

[1574] In some examples, motion candidates from neighboring blocks in the MER spatial domain are added to the motion candidate list without pruning.

[1575] In some examples, the maximum number of motion candidates in the block's motion candidate list depends on whether the block is under a MER.

[1576] In some examples, the maximum number of motion candidates in the motion candidate lists for the first block under MER and the second block not under MER are different.

[1577] In some examples, the maximum number of motion candidates in the motion list of the first block is less than the maximum number of motion candidates in the motion list of the second block.

[1578] In some examples, the maximum number of motion candidates in the motion list of the first block is greater than the maximum number of motion candidates in the motion list of the second block.

[1579] In some examples, the maximum number of motion candidates in the motion candidate lists of the first block under MER and the second block not under MER is the same.

[1580] In some examples, the maximum number of motion candidates in the motion candidate list of a block under the signaling notification MER at the sequence level, picture level, strip level, or slice group level.

[1581] In some examples, the maximum number of motion candidates is specified in the block motion candidate list under the signaling notification MER in the sequence header, image header, SPS, VPS, DPS, PPS, APS, strip header, or slice header.

[1582] In some examples, the maximum number of motion candidates in the motion candidate list for a block under the MER is signaled only when MER is enabled for a video, sequence, image, strip, sub-image, slice group, slice, or CTU line.

[1583] In some examples, the signaling notifies the maximum number of motion candidates in the motion candidate list of the block represented by the MER of maxBvListSizeNonMer, depending on the maximum number of motion candidates in the motion candidate list that are not under the block represented by the MER of maxBvListSizeNonMer.

[1584] In some examples, the signaling notifies maxBvListSizeNonMer – maxBvListSizeMer instead of maxBvListSizeMer.

[1585] In some examples, the motion candidate list construction process depends on the block position within the MER.

[1586] In some examples, the motion candidate list construction process is applied only to blocks that are completely within the MER, where a block is completely within the MER if its left and top boundaries do not coincide with any boundary of the MER.

[1587] In some examples, when the block is entirely within the MER, up to X pairwise averaged candidates are added to the motion candidate list, where X is an integer.

[1588] In some examples, X equals 2 or 3.

[1589] In some examples, the signaling notification for the merge index of a block that is entirely within the MER differs from that of a block that is not within the MER or is not entirely within the MER.

[1590] In some examples, the maximum number M of merge MVP candidates that are entirely within the MER is different from the maximum number N of merge MVP candidates in the VVC, where M and N are integers.

[1591] In some examples, M is less than N

[1592] In some examples, M = 2 and N = 5.

[1593] In some examples, the maximum value of the truncated Rice binarized code of the merge index of a block completely within MER depends on M.

[1594] In some examples, the maximum value is equal to M-1.

[1595] In some examples, the Merge (MMVD) process with motion vector difference for blocks that are completely within the MER differs from that for blocks that are not within the MER or are not completely within the MER.

[1596] In some examples, the maximum number T of MMVD base candidates for blocks that are completely within MER is greater than 2.

[1597] In some examples, T = 3, 4, or 5.

[1598] In some examples, for blocks that are entirely within MER, the predefined distance in MMVD is modified.

[1599] In some examples, the modified predefined distance is equal to d*S, where d represents the original predefined distance and S represents the multiscale.

[1600] In some examples, S equals 2 or 3.

[1601] In some examples, S equals 1 / 2 or 1 / 3.

[1602] Figure 36 A flowchart of an example method for video processing is shown. The method includes: for a conversion between a current video block and a bitstream of the video, determining (3602) one or more canonical constraints on a binary tree (BT) and / or ternary tree (TT) partition based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps with the MER; and performing (3604) a conversion based on the one or more canonical constraints.

[1603] In some examples, the MER width, MER height, block width, and block height of the current video block are represented by R1, R2, W, and H, respectively, and one or more canonical constraints on the binary tree (BT) and / or ternary tree (TT) partitioning depend on at least one of the MER width, MER height, block width, and block height.

[1604] In some examples, horizontal BT partitioning is disabled for the current video block when W>R1 and H<=R2.

[1605] In some examples, vertical BT partitioning is disabled for the current video block when W <= R1 and H > R2.

[1606] In some examples, horizontal TT partitioning is disabled for the current video block when (W>R1||H>R2) and H<=K*R2, where K is an integer.

[1607] In some examples, K = 2.

[1608] In some examples, vertical TT partitioning is disabled for the current video block when (W>R1||H>R2) and W<=K*R1, where K is an integer.

[1609] In some examples, K = 2.

[1610] In some examples, R1 is not equal to R2.

[1611] In some examples, R1 = 32, R2 = 64, or R1 = 64, R2 = 32.

[1612] In some examples, R1 equals R2.

[1613] In some examples, R1 = R2 = 32, or R1 = R2 = 64.

[1614] In some examples, if a type of partition is disabled, the codeword representing that type of partition is skipped.

[1615] In some examples, if a type of partition is disabled, the syntax element representing that type of partition is skipped.

[1616] In some examples, whether and / or how one or more specification constraints are applied to BT and TT partitions depends on the strip or slice group type, and / or the image type, and / or the partition tree type including video (two-tree and / or single-tree).

[1617] In some examples, when only intra-frame codec tools are allowed for the current picture, current sub-picture, current stripe, or current slice, one or more specification constraints on the BT and TT partitions are not applied.

[1618] In some examples, the current image is an I-frame, or the current stripe is an I-strip.

[1619] In some examples, when only inter-frame encoding / decoding tools are allowed for the current picture, current subpicture, current stripe, or current slice, one or more specification constraints on the BT and TT partitions are not applied.

[1620] In some examples, the current image is a P / B frame, or the current stripe is a P / B stripe.

[1621] In some examples, when a block is located in a specific region within a picture or frame of a video, one or more canonical constraints on the BT and TT partitions are applied to the block.

[1622] In some examples, a specific region includes at least one of a sub-image, strip, slice, or predefined rectangular region, which includes a region of interest (ROI) in a frame of an image or video.

[1623] In some examples, when a portion of a block is outside of a picture or frame in the video, one or more canonical constraints on the BT and TT partitions are not applied to the block, where the top-left luminance sample, picture or frame width, and picture or frame height of the block are represented by (x0, y0), picW, and picH, respectively.

[1624] In some examples, a portion of the block is outside the images or frames of the video when the top-left corner of the block is inside the image or frame, and the top-right and / or bottom-left corners of the block are outside the image or frame.

[1625] In some examples, when a portion of a block is outside of a picture or frame in the video, one or more canonical constraints on the BT partition are not applied to the block.

[1626] In some examples, horizontal BT partitioning of blocks is still allowed when y0 <= picH and y0 + T > picH, where T is an integer.

[1627] In some examples, T equals the block height.

[1628] In some examples, vertical BT partitioning of blocks is still allowed when x0 <= picW and x0 + T > picW, where T is an integer.

[1629] In some examples, T equals the block width.

[1630] In some examples, when a portion of a block is outside of a picture or frame in the video, one or more canonical constraints on the TT partition are not applied to the block.

[1631] In some examples, horizontal TT partitioning of the block is still allowed when y0 <= picH and y0 + T > picH, where T is an integer.

[1632] In some examples, T equals the block height.

[1633] In some examples, T equals b*H, where b = 1 / 2 or 1 / 4.

[1634] In some examples, vertical TT partitioning of the block is still allowed when x0 <= picW and x0 + T > picW, and T is an integer.

[1635] In some examples, T equals the block width.

[1636] In some examples, T equals b*W, where b = 1 / 2 or 1 / 4.

[1637] In some examples, whether and / or how to perform deterministic and additive operations depends on the following information:

[1638] a. A message notified by signaling in at least one of DPS, SPS, VPS, PPS, APS, picture header, strip header, slice header, maximum codec unit (LCU), codec unit (CU), LCU line, LCU group, TU, PU block, video codec unit;

[1639] b. The position of at least one of CU, PU, ​​TU, block, and video codec unit;

[1640] c. The block dimension of the current block and / or its neighboring blocks;

[1641] d. The block shape of the current block and / or its neighboring blocks;

[1642] e. Encoding and decoding modes for blocks, including IBC or non-IBC inter-frame modes or non-IBC sub-block modes;

[1643] f. Indication of color format, including 4:2:0 and 4:4:4;

[1644] g. Encoding / decoding tree structure;

[1645] h. Strip, slice type, and / or image type;

[1646] i. Color components, including only chromaticity components or luminance components;

[1647] j. Temporal layer ID;

[1648] k. Standard configuration files, levels, and hierarchies.

[1649] In some examples, the conversion involves encoding the current video block into a bitstream.

[1650] In some examples, the conversion involves decoding the current video chunk from the bitstream.

[1651] In some examples, the conversion includes generating a bitstream from the current video block; the method also includes storing the bitstream in a non-transitory computer-readable recording medium.

[1652] Figure 37 A flowchart of an example method for video processing is shown. The method includes: for a conversion between a current video block and a bitstream of the video, during the construction of a motion candidate list, determining (3702) one or more motion candidates for the current video block based on a merge estimation region (MER) covering the current video block; during the construction of the motion candidate list, adding (3704) one or more motion candidates to a motion candidate list associated with the current video block; generating (3706) a bitstream from the current video block based on the motion candidate list; and storing (3708) the bitstream in a non-transitory computer-readable recording medium.

[1653] In this document, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm can be applied during the conversion from the pixel representation of a video to the corresponding bitstream representation, and vice versa. As defined in the syntax, the bitstream representation of the current video block can, for example, correspond to bits that are co-occurring or scattered at different locations within the bitstream. For example, a macroblock can be encoded based on the error residuals from the transformation and encoding / decoding, and also using bits in the header and other fields in the bitstream.

[1654] The disclosures and other schemes, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits or in computer software, firmware, or hardware, containing the structures disclosed in this document and their equivalents, or combinations thereof. The disclosed and other embodiments can be implemented as one or more computer program products encoded on a computer-readable medium, such as one or more computer program instruction modules, for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. The computer-readable medium can be a combination of a machine-readable storage device, a machine-readable storage substrate, a memory device, a substance that influences machine-readable propagating signals, or one or more of the above. The term "data processing apparatus" encompasses all means, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or one or more of the above. Propagating signals are artificially generated signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device.

[1655] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including standalone programs or modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on one computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communications network.

[1656] The processing and logic flows described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processing and logic flows can also be executed by special-purpose logic circuitry, and the devices can be implemented as special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[1657] Processors suitable for executing computer programs include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors in any type of digital computer. Typically, a processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magneto-optical, magneto-optical, or optical disc) for storing data, or operatively coupled to receive data from or transfer data to a mass storage device (e.g., magneto-optical, magneto-optical, or optical disc), or both. However, a computer does not necessarily need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into special-purpose logic circuitry.

[1658] While this patent document contains numerous details, these details should not be construed as limiting any subject matter or the scope of the claims, but rather as descriptions of features specific to particular embodiments of a particular art. In this patent document, certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in various suitable sub-combinations. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in the same manner, in certain circumstances one or more features from the claimed combination may be removed from the combination, and the claimed combination may be for sub-combinations or variations thereof.

[1659] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order or sequence shown, or performing all the shown operations to achieve the desired result. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.

[1660] Only a few implementations and examples are described, and other implementations, enhancements and variations can be made based on what is described and shown in this patent document.

Claims

1. A method of video processing, comprising: determining, for a first conversion between a current video block of a video and a bitstream of the video, one or more normative constraints on binary tree (BT) and / or ternary tree (TT) partitioning based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps the MER; and performing the first conversion based on the one or more normative constraints; wherein the one or more normative constraints on BT and TT partitioning are not applied to a block when a portion of the block is outside a picture or frame of the video, wherein a top-left luma sample, a picture or frame width, and a picture or frame height of the block are represented by (x0, y0), picW, and picH, respectively; wherein a portion of the block is outside the picture or frame of the video when a top-left corner of the block is inside the picture or frame and a top-right corner or / and a bottom-left corner of the block is outside the picture or frame.

2. The method of claim 1, wherein, a MER width, a MER height, a block width, and a block height of the current video block are represented by R1, R2, W, and H, respectively, and the one or more normative constraints on binary tree and / or ternary tree partitioning depend on at least one of the MER width, the MER height, the block width, and the block height.

3. The method of claim 2, wherein, a horizontal BT partition is disabled for the current video block when W > R1 and H <= R2.

4. The method of claim 2, wherein, a vertical BT partition is disabled for the current video block when W <= R1 and H > R2.

5. The method of claim 2, wherein, a horizontal TT partition is disabled for the current video block when (W > R1 || H > R2) and H <= K * R2, K being an integer.

6. The method of claim 5, wherein, K=2。 7. The method of claim 6, wherein, a vertical TT partition is disabled for the current video block when (W > R1 || H > R2) and W <= K * R1, K being an integer.

8. The method of claim 7, wherein, K=2。 9. The method of claim 6, wherein, R1 is not equal to R2.

10. The method of claim 9, wherein, R1 = 32, R2 = 64, or R1 = 64, R2 = 32.

11. The method of claim 6, wherein, R1 is equal to R2.

12. The method of claim 9, wherein, R1 = R2 = 32, or R1 = R2 = 64.

13. The method of claim 1, wherein, if a type of partition is disabled, a codeword representing the type of partition is skipped.

14. The method of claim 1, wherein, if a type of partition is disabled, a syntax element representing the type of partition is skipped.

15. The method of claim 1, wherein, whether and / or how the one or more normative constraints on BT and TT partitioning are applied depends on a slice or tile group type, and / or a picture type, and / or a split tree type including a dual tree and / or a single tree of the video.

16. The method of claim 15, wherein, the one or more normative constraints on BT and TT partitioning are not applied when only an intra coding tool is allowed for a current picture, a current subpicture, a current slice, or a current tile.

17. The method of claim 16, wherein, the current picture is an I frame, or the current slice is an I slice.

18. The method of claim 15, wherein, the one or more normative constraints on BT and TT partitioning are not applied when only an inter coding tool is allowed for a current picture, a current subpicture, a current slice, or a current tile.

19. The method of claim 18, wherein, the current picture is a P / B frame, or the current slice is a P / B slice.

20. The method of claim 1, wherein, The one or more normative constraints on BT and TT partitioning are applied to the block when the block is within a certain region in a picture or frame of the video.

21. The method of claim 20, wherein, The certain region comprises at least one of a sub-picture, a slice, a tile, or a pre-defined rectangular region comprising a region of interest (ROI) in the picture or frame of the video.

22. The method of claim 1, wherein, The one or more normative constraints on BT partitioning are not applied to the block when a portion of the block is outside a picture or frame of the video.

23. The method of claim 22, wherein, A horizontal BT partitioning of a block is still allowed when y0 <= picH and y0 + T > picH, T being an integer.

24. The method of claim 23, wherein, T is equal to the block height.

25. The method of claim 22, wherein, A vertical BT partitioning of a block is still allowed when x0 <= picW and x0 + T > picW, T being an integer.

26. The method of claim 23, wherein, T is equal to the block width.

27. The method of claim 1, wherein, The one or more normative constraints on TT partitioning are not applied to the block when a portion of the block is outside a picture or frame of the video.

28. The method of claim 27, wherein, A horizontal TT partitioning of a block is still allowed when y0 <= picH and y0 + T > picH, T being an integer.

29. The method of claim 28, wherein, T is equal to the block height.

30. The method of claim 27, wherein, T is equal to b*H, where b = 1 / 2 or 1 / 4.

31. The method of claim 27, wherein, A vertical TT partitioning of a block is still allowed when x0 <= picW and x0 + T > picW, T being an integer.

32. The method of claim 31, wherein, T is equal to the block width.

33. The method of claim 31, wherein, T is equal to b*W, where b = 1 / 2 or 1 / 4.

34. The method of claim 1, further comprising: determining, for a second conversion between a current video block of the video and a bitstream of the video, one or more block vector (BV) candidates for the current video block based on a merge estimation region (MER) covering the current video block; adding the one or more BV candidates to a BV list associated with the current video block; and performing the second conversion based on the BV list. The current video block is an intra block copy (IBC) coded block.

35. The method of claim 34, wherein, No BV candidate from a spatial neighboring collocated block or / and a spatial neighboring non-collocated block below the MER is added to the BV list.

36. The method of claim 35, wherein, Only BV candidates from a spatial neighboring collocated block or / and a spatial neighboring non-collocated block outside the MER, or / and BV candidates from a history-based motion vector prediction (HMVP) table based on IBC, or / and default BV candidates are added to the BV list.

37. The method of claim 35, wherein, No BV candidate from a spatial neighboring block is added to the BV list.

38. The method of claim 35, wherein, BV candidates from the IBC HMVP table are added to the BV list in a predefined order, or / and no pruning is performed when adding the BV candidates.

39. The method of claim 37, wherein, The order is in ascending or descending order based on entry indices of the table.

40. The method of claim 39, wherein, The first N entries in the table are skipped.

41. The method of claim 39, wherein, The last N entries in the table are skipped.

42. The method of claim 39, wherein, Entries with invalid BVs are skipped.

43. The method of claim 39, wherein, BV candidates from the IBC HMVP table are modified before being added to the BV list.

44. The method of claim 37, wherein, An offset is added to a horizontal component or / and a vertical component of BV candidates from the IBC HMVP table.

45. The method of claim 44, wherein, ​ 46. The method of claim 44, wherein, modifying a HMVP candidate with an invalid BV to a candidate with a valid BV.

47. The method of claim 37, wherein, adding one or more default BV candidates after or before one or more HMVP BV candidates, wherein the default BV candidate is defined as (BVx, BVy).

48. The method of claim 47, wherein, BVx = 0, BVy = 0.

49. The method of claim 47, wherein, BVx = -W, BVy = -H, wherein W and H are the width and height of the current video block.

50. The method of any one of claims 34-49, wherein, the BV list refers to an IBC AMVP list or / and an IBC merge list associated with the current video block.

51. The method of claim 37, wherein, not updating the IBC HMVP table after decoding the current video block under the MER.

52. The method of claim 37, wherein, updating the IBC HMVP table only once for video blocks within the MER.

53. The method of claim 37, wherein, updating the IBC HMVP table only if the current video block is not within the MER or the bottom-right corner of the current video block coincides with the bottom-right corner of the MER.

54. The method of claim 1, further comprising: for a third conversion between a current video block of the video and a bitstream of the video, determining one or more motion candidates of the current video block based on a merge estimation region (MER) covering the current video block during a motion candidate list construction process; adding the one or more motion candidates to a motion candidate list associated with the current video block during the motion candidate list construction process; and performing the conversion based on the motion candidate list. the motion candidate list comprises a block vector (BV) candidate list, a normal merge list, or a sub-block merge list.

55. The method of claim 54, wherein, using motion candidates from MER spatial neighboring blocks of the MER during the motion candidate list construction process, the MER spatial neighboring blocks comprising MER spatial neighboring neighboring blocks or / and MER spatial neighboring non-neighboring blocks of the MER.

56. The method of claim 55, wherein, checking MER spatial neighboring blocks of the MER during the motion candidate list construction process when spatial neighboring blocks of the current video block are not available.

57. The method of claim 56, wherein, if motion information of the MER spatial neighboring blocks is available, using the motion information to derive motion candidates that are directly added to the motion candidate list as a replacement of motion candidates derived from the spatial neighboring blocks.

58. The method of claim 57, wherein, checking the MER spatial neighboring blocks after all spatial neighboring blocks of the current video block are checked during the motion candidate list construction process.

59. The method of claim 56, wherein, adding motion candidates from the MER spatial neighboring blocks to the motion candidate list after spatial merge candidates.

60. The method of claim 59, wherein, checking the MER spatial neighboring blocks after all history-based motion vector prediction (HMVP) candidates are checked.

61. The method of claim 56, wherein, adding motion candidates from the MER spatial neighboring blocks to the motion candidate list after the HMVP candidates.

62. The method of claim 61, wherein, adding at most X candidates from the MER neighboring blocks to the motion candidate list, wherein X is an integer.

63. The method of any one of claims 56-62, wherein, checking MER spatial neighboring blocks at fixed positions and using motion information from the fixed positions during the motion candidate list construction process.

64. The method of claim 63, wherein, X = 2。 65. The method of claim 56, wherein, ​ 66. The method of claim 65, wherein, For two blocks within the same MER, the same set of allowed MER spatial neighboring blocks is defined and only those blocks in the set are examined and used.

67. The method of claim 66, wherein, Only one or more of the MER spatial neighboring blocks in the set are examined and used.

68. The method of claim 66, wherein, Only one or more of the MER spatial non-neighboring blocks in the set are examined and used.

69. The method of claim 66, wherein, When the neighboring blocks of the current video block are not available, the corresponding MER spatial neighboring blocks are used instead by assuming that the size of the current video block is equal to the size of the MER, where (x0, y0) denotes the top-left position of the current video block relative to the top-left sample of the current picture, bW denotes the block width, bH denotes the block height, mW denotes the MER width, and mH denotes the MER height.

70. The method of claim 69, wherein, If the left block at (x0 - 1, y0 + bH - 1) is not available, the block at ((x0 » Log2(mW)) « Log2(mW) - 1, (y0 » Log2(mH)) « Log2(mH) + mH - 1) is used.

71. The method of claim 69, wherein, If the bottom-left block at (x0 - 1, y0 + bH) is not available, the block at ((x0 » Log2(mW)) « Log2(mW) - 1, (y0 » Log2(mH)) « Log2(mH) + mH) is used.

72. The method of claim 69, wherein, If the top-right block at (x0 + bW, y0 - 1) is not available, the block at ((x0 » Log2(mW)) « Log2(mW) + mW, (y0 » Log2(mH)) « Log2(mH) - 1) is used.

73. The method of claim 69, wherein, If the top block at ((x0 » Log2(mW)) « Log2(mW) + mW - 1, y0 - 1) is not available, the block at (x0 + bW - 1, (y0 » Log2(mH)) « Log2(mH) - 1) is used.

74. The method of claim 69, wherein, If the top-left block at (x0 - 1, y0 - 1) is not available, the block at ((x0 » Log2(mW)) « Log2(mW) - 1, (y0 » Log2(mH)) « Log2(mH) - 1) is used.

75. The method of claim 56, wherein, During the motion candidate list construction process, MER spatial neighboring blocks at adaptive positions are examined and motion information from the adaptive positions is used.

76. The method of claim 75, wherein, At least for two blocks below the MER, at least one of the blocks to be examined is different.

77. The method of claim 76, wherein, When a spatial neighboring block of the current video block is not available, a corresponding MER spatial neighboring block is used instead by assuming that the size of the current video block is equal to the size of the MER, wherein (x0, y0) denotes the top-left position of the current video block relative to the top-left sample of the current picture, bW denotes the block width, bH denotes the block height, mW denotes the MER width, and mH denotes the MER height.

78. The method of claim 77, wherein, If the left block at (x0−1, y0+bH−1) is not available, the block at ((x0>>Log2(mW))<<Log2(mW)−1, y0+bH−1) is used.

79. The method of claim 77, wherein, If the bottom-left block at (x0−1, y0+bH) is not available, the block at ((x0>>Log2(mW))<<Log2(mW)−1, y0+bH) is used.

80. The method of claim 77, wherein, If the top-right block at (x0+bW, y0−1) is not available, the block at (x0+bW, (y0>>Log2(mH))<<Log2(mH)−1) is used.

81. The method of claim 77, wherein, If the top block at ((x0>>Log2(mW))<<Log2(mW)+mW−1, y0−1) is not available, the block at (x0+bW−1, (y0>>Log2(mH))<<Log2(mH)−1) is used.

82. The method of claim 77, wherein, If the top-left block at (x0−1, y0−1) is not available, the block at ((x0>>Log2(mW))<<Log2(mW)−1, (y0>>Log2(mH))<<Log2(mH)−1) is used.

83. The method of claim 76, wherein, For different blocks within the same MER, different sets of allowed MER spatial neighboring blocks associated with the different blocks are defined, and only those blocks in the same set are checked and used.

84. The method of claim 83, wherein, Only one or more of the MER spatial neighboring blocks (C0, C1, D0, D1, and D2) in a first set associated with a first block are checked and used.

85. The method of claim 83, wherein, Only one or more of the MER spatial non-neighboring blocks (E0, E1, F0, F1, and F2) in the first set associated with the first block are checked and used.

86. The method of claim 83, wherein, Only one or more of the MER spatial neighboring blocks (C'0, C'1, D'0, D'1, and D'2) in a second set associated with a second block are checked and used.

87. The method of claim 83, wherein, Only one or more of the MER spatial non-neighboring blocks (E'0, E'1, F'0, F'1, and F'2) in the second set associated with the second block are checked and used.

88. The method of claim 56, wherein, Whether to add a motion candidate from a MER spatial neighboring block to the motion candidate list depends on the location or / and availability of the MER spatial neighboring block.

89. The method of claim 88, wherein, During the motion candidate list construction process, a motion candidate from at least one of the MER spatial neighboring blocks or / and the MER spatial non-neighboring blocks outside the MER is used.

90. The method of claim 89, wherein, The motion candidate includes an IBC candidate, or a normal inter candidate, or a sub-block candidate including an affine candidate.

91. The method of claim 90, wherein, A motion candidate located at a specific position is added to the motion candidate list.

92. The method of claim 91, wherein, The specific position includes a left neighboring block and an above neighboring block, or a left non-neighboring block and an above non-neighboring block.

93. The method of claim 91, wherein, The specific position includes an above neighboring block and a left neighboring block, or an above non-neighboring block and a left non-neighboring block.

94. The method of claim 91, wherein, The specific position includes a left neighboring block, an above neighboring block and a top-left neighboring block, or a left non-neighboring block, an above non-neighboring block and a top-left non-neighboring block.

95. The method of claim 91, wherein, The specific position includes an above neighboring block and a top-left neighboring block, or an above non-neighboring block and a top-left non-neighboring block.

96. The method of claim 91, wherein, The specific position includes a left neighboring block and a top-left neighboring block, or a left non-neighboring block and a top-left non-neighboring block.

97. The method of claim 91, wherein, Motion candidates from the spatial neighboring blocks are inserted into the motion candidate list in a predefined order.

98. The method of claim 97, wherein, The predefined order is a left neighboring block, a bottom-left neighboring block, a top-right neighboring block, an above neighboring block and a top-left neighboring block, or a left non-neighboring block, a bottom-left non-neighboring block, a top-right non-neighboring block, an above non-neighboring block and a top-left non-neighboring block.

99. The method of claim 97, wherein, The predefined order is an above neighboring block, a top-right neighboring block, a left neighboring block, a bottom-left neighboring block and a top-left neighboring block, or an above non-neighboring block, a top-right non-neighboring block, a left non-neighboring block, a bottom-left non-neighboring block and a top-left non-neighboring block.

100. The method of claim 97, wherein, The predefined order is a top-left neighboring block, a left neighboring block, an above neighboring block, a bottom-left neighboring block and a top-right neighboring block, or a top-left non-neighboring block, a left non-neighboring block, an above non-neighboring block, a bottom-left non-neighboring block and a top-right non-neighboring block.

101. The method of claim 90, wherein, During the motion candidate list construction process, a BV candidate from at least one of a bottom-left non-neighboring block, a left non-neighboring block, a top-right non-neighboring block, a top-left non-neighboring block and an above non-neighboring block outside the MER is used.

102. The method of claim 88, wherein, The MER spatial neighboring blocks are determined to be available only when the blocks are coded in a specific mode.

103. The method of claim 102, wherein, The specific mode includes an IBC mode.

104. The method of claim 102, wherein, The specific mode includes a normal inter mode.

105. The method of claim 104, wherein, The normal inter mode includes a translational motion based inter mode.

106. The method of claim 89, wherein, The neighboring blocks of the current video block used in the motion candidate list construction are considered to be unavailable if outside the MER.

107. The method of claim 89, wherein, Motion candidates from the MER spatial neighboring blocks are added to the motion candidate list by a pruning operation.

108. The method of claim 107, wherein, When the motion information of the motion candidate exists in the motion candidate list, no motion candidate is added to the motion candidate list.

109. The method of claim 107, wherein, two motion candidates from the MER spatial neighboring blocks are compared to determine whether the two motion candidates are identical or similar, and the two motion candidates are put into the motion candidate list only when the two motion candidates are not identical or similar.

110. The method of claim 89, wherein, motion candidates from the MER spatial neighboring blocks are added to the motion candidate list without a pruning operation.

111. The method of claim 55, wherein, The maximum number of motion candidates of the motion candidate list of a block depends on whether the block is under the MER.

112. The method of claim 111, wherein, For a first block under the MER and a second block not under the MER, the maximum number of motion candidates of the motion candidate list of the first block and the second block are different.

113. The method of claim 112, wherein, The maximum number of motion candidates of the motion list of the first block is smaller than the maximum number of motion candidates of the motion list of the second block.

114. The method of claim 112, wherein, The maximum number of motion candidates of the motion list of the first block is larger than the maximum number of motion candidates of the motion list of the second block.

115. The method of claim 111, wherein, For a first block under the MER and a second block not under the MER, the maximum number of motion candidates of the motion candidate list of the first block and the second block are the same.

116. The method of claim 111, wherein, The maximum number of motion candidates of the motion candidate list of a block under the MER is signaled at sequence level, picture level, slice level or tile group level.

117. The method of claim 116, wherein, The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled in sequence header, picture header, SPS, VPS, DPS, PPS, APS, slice header or tile group header.

118. The method of claim 117, wherein, The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled only when MER is enabled for the video, sequence, picture, slice, subpicture, tile group, tile or CTU row.

119. The method of claim 117, wherein, The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled as maxBvListSizeNonMer depending on the maximum number of motion candidates of the motion candidate list of a block not under the MER denoted as maxBvListSizeMer.

120. The method of claim 119, wherein, maxBvListSizeNonMer - maxBvListSizeMer is signaled instead of maxBvListSizeMer.

121. The method of claim 54, wherein, The motion candidate list construction process depends on the block position within the MER.

122. The method of claim 121, wherein, The motion candidate list construction process is applied only to the blocks that are completely within the MER, where a block is completely within the MER when the block is within the MER and neither the left boundary nor the top boundary of the block coincides with any boundary of the MER.

123. The method of claim 122, wherein, Up to X pair-wise average candidates are added to the motion candidate list in the case that the block is completely within the MER, X is an integer.

124. The method of claim 123, wherein, X is equal to 2 or 3.

125. The method of claim 122, wherein, The signaling of the merge index of a block that is completely within the MER is different from a block that is not within the MER or not completely within the MER.

126. The method of claim 125, wherein, The maximum number of merge MVP candidates M of a block that is completely within the MER is different from the maximum number of merge MVP candidates N in VVC, M and N are integers. The maximum number of motion candidates of the motion candidate list of a block under the MER is signaled at sequence level, picture level, slice level or tile group level. The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled in sequence header, picture header, SPS, VPS, DPS, PPS, APS, slice header or tile group header. The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled only when MER is enabled for the video, sequence, picture, slice, subpicture, tile group, tile or CTU row. The maximum number of motion candidates of the motion candidate list of the block under the MER is signaled as maxBvListSizeNonMer depending on the maximum number of motion candidates of the motion candidate list of a block not under the MER denoted as maxBvListSizeMer. maxBvListSizeNonMer - maxBvListSizeMer is signaled instead of maxBvListSizeMer. The motion candidate list construction process depends on the block position within the MER. The motion candidate list construction process is applied only to the blocks that are completely within the MER, where a block is completely within the MER when the block is within the MER and neither the left boundary nor the top boundary of the block coincides with any boundary of the MER. Up to X pair-wise average candidates are added to the motion candidate list in the case that the block is completely within the MER, X is an integer. X is equal to 2 or 3. The signaling of the merge index of a block that is completely within the MER is different from a block that is not within the MER or not completely within the MER. The maximum number of merge MVP candidates M of a block that is completely within the MER is different from the maximum number of merge MVP candidates N in VVC, M and N are integers.

127. The method of claim 126, wherein, M is smaller than N.

128. The method of claim 127, wherein, M = 2, and N = 5.

129. The method of claim 126, wherein, The maximum value of the truncated rice binarization code of the merge index of the block that is completely within the MER depends on M.

130. The method of claim 129, wherein, The maximum value is equal to M-1.

131. The method of claim 122, wherein, The Merge MMVD process with motion vector difference for the block that is completely within the MER is different from the block that is not within the MER or not completely within the MER.

132. The method of claim 131, wherein, The maximum number of MMVD base candidates T for the block that is completely within the MER is greater than 2.

133. The method of claim 132, wherein, T = 3, or 4, or 5.

134. The method of claim 131, wherein, The predefined distance in MMVD is modified for the block that is completely within the MER.

135. The method of claim 134, wherein, The modified predefined distance is equal to d*S, where d represents the original predefined distance, and S represents multiscale.

136. The method of claim 134, wherein, S is equal to 2 or 3, or S is equal to 1 / 2 or 1 / 3.

137. The method of claim 1, wherein, Whether and / or how the determining operation and the adding operation are performed depends on the following information: a. a message signaled in at least one of DPS, SPS, VPS, PPS, APS, picture header, slice header, tile group header, largest coding unit, LCU, coding unit, CU, LCU row, LCU group, TU, PU block, video coding unit; b. a location of at least one of CU, PU, TU, block, video coding unit; c. a block dimension of the current block and / or its neighboring blocks; d. a block shape of the current block and / or its neighboring blocks; e. a coding mode of the block including IBC or non-IBC inter mode or non-IBC subblock mode; f. an indication of color format including 4:2:0 and 4:4:4; g. a coding tree structure; h. a slice, tile group type and / or picture type; i. a color component including only chroma component or luma component; j. a temporal layer ID; k. a profile, level, tier of a standard.

138. The method of claim 1, wherein, The first conversion includes encoding the current video block into the bitstream.

139. The method of claim 1, wherein, The first conversion includes decoding the current video block from the bitstream.

140. The method of claim 1, wherein, The first conversion includes generating the bitstream from the current video block. The method further includes: storing the bitstream in a non-transitory computer-readable recording medium.

141. An apparatus for processing video data, comprising a processor and a non-transitory memory with instructions thereon, wherein, The instructions, when executed by the processor, cause the processor to: for a first conversion between a current video block of a video and a bitstream of the video, determine one or more normative constraints on a binary tree (BT) and / or ternary tree (TT) partition based on a merge estimation region (MER) associated with the current video block, wherein the current video block is completely within the MER or overlaps with the MER; and perform the first conversion based on the one or more normative constraints; wherein the one or more normative constraints on BT and TT partition are not applied to a block when a portion of the block is outside a picture or frame of the video, wherein a top-left luma sample, picture or frame width, and picture or frame height of the block are represented by (x0, y0), picW, and picH, respectively; wherein a portion of the block is outside the picture or frame of the video when a top-left corner of the block is within the picture or frame and a top-right corner or / and a bottom-left corner of the block is outside the picture or frame. 142.A non-transitory computer-readable medium storing instructions that cause a processor to: For a first conversion between a current video block of a video and a bitstream of the video, one or more normative constraints on a binary tree (BT) and / or a ternary tree (TT) partition are determined based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps the MER; and perform the first conversion based on the one or more normative constraints; wherein the one or more normative constraints for BT and TT partition are not applied to a block when a portion of the block is outside a picture or frame of the video, wherein a top-left luma sample, picture or frame width, and picture or frame height of the block are denoted by (x0, y0), picW, and picH, respectively; wherein a portion of the block is outside the picture or frame of the video when a top-left corner of the block is inside the picture or frame and a top-right corner or / and a bottom-left corner of the block is outside the picture or frame.

143. A non-transitory computer-readable medium storing a bitstream of a video generated by a method performed by a video processing apparatus, wherein, the method comprises: determining, for a first conversion between a current video block of a video and a bitstream of the video, one or more normative constraints for binary tree (BT) and / or ternary tree (TT) partition based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps the MER; generating the bitstream from the current video block based on the one or more normative constraints; and storing the bitstream in a non-transitory computer-readable recording medium; wherein the one or more normative constraints for BT and TT partition are not applied to a block when a portion of the block is outside a picture or frame of the video, wherein a top-left luma sample, picture or frame width, and picture or frame height of the block are denoted by (x0, y0), picW, and picH, respectively; wherein a portion of the block is outside the picture or frame of the video when a top-left corner of the block is inside the picture or frame and a top-right corner or / and a bottom-left corner of the block is outside the picture or frame. 144.A method of storing a bitstream of a video, comprising: determining, for a first conversion between a current video block of a video and a bitstream of the video, one or more normative constraints for binary tree (BT) and / or ternary tree (TT) partition based on a merge estimation region (MER) associated with the current video block, wherein the current video block is entirely within or overlaps the MER; generating the bitstream from the current video block based on the one or more normative constraints; and storing the bitstream in a non-transitory computer-readable recording medium; wherein the one or more normative constraints for BT and TT partition are not applied to a block when a portion of the block is outside a picture or frame of the video, wherein a top-left luma sample, picture or frame width, and picture or frame height of the block are denoted by (x0, y0), picW, and picH, respectively; wherein a portion of the block is outside the picture or frame of the video when a top-left corner of the block is inside the picture or frame and a top-right corner or / and a bottom-left corner of the block is outside the picture or frame.

Images