Method, apparatus and medium for video processing

Abstract

The embodiments of the present disclosure provide a solution for video processing. A method for video processing is proposed. The method includes: determining at least one history-based motion vector prediction (HMVP) table for a current video block based on at least one of a motion vector (MV) difference threshold for comparing at least two MVs of at least two HMVP candidates, a coding mode of the current video block, or a reference picture list index associated with the current video block, for conversion between a current video block of a video and a bitstream of the video; and performing conversion based on the at least one HMVP table.

Description

[Technical Field]

[0001] FIELD Embodiments of the present disclosure relate generally to video coding techniques, and more particularly to building history-based motion vector prediction (HMVP) tables and motion candidate lists. [Background technology]

[0002] Today, digital video functions are applied in various aspects of people's lives. Several types of video compression technologies have been proposed for video encoding / decoding, including MPEG-2, MPEG-4, ITU-TH.263, ITU-TH.264 / MPEG-4 Part 10 Advanced Video Coding (AVC), ITU-TH.265 high efficiency video coding (HEVC) standard, and versatile video coding (VVC) standard. However, the coding efficiency of conventional video coding technologies is generally very low, which is undesirable. Summary of the Invention

[0003] Embodiments of the present disclosure provide a solution for video processing.

[0004] In a first aspect, a method for video processing is proposed. The method includes determining at least one history-based motion vector prediction (HMVP) table for a current video block based on at least one of a motion vector (MV) difference threshold for comparing at least two MVs of at least two HMVP candidates, a coding mode of the current video block, or a reference picture list index associated with the current video block, for conversion between a current video block of a video and a bitstream of the video, and performing conversion based on the at least one HMVP table. Since the method according to the first aspect of the present disclosure determines the HMVP table based on the MV difference threshold, the coding mode, or the reference picture list index, coding efficiency and coding effectiveness can be improved.

[0005] In a second aspect, another method for video processing is proposed. The method includes determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to a motion candidate list of a current video block based on at least one comparison between the HMVP candidate and at least one candidate in a motion candidate list for conversion between a current video block of a video and a bitstream of the video, and performing the conversion based on the determination. The method according to the second aspect of the present disclosure adds the HMVP candidate from the HMVP table to the motion candidate list based on the comparison between the HMVP candidate and a candidate in the motion candidate list, thereby improving coding efficiency and coding effectiveness.

[0006] In a third aspect, another method for video processing is proposed. The method includes: determining a first candidate list for a current video block based on a maximum number of motion candidates in the first candidate list for conversion between a current video block of a video and a bitstream of the video; determining a motion candidate list for the current video block based on the first candidate list, where the motion candidate list includes at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; and performing conversion based on the motion candidate list. Since the method according to the third aspect of the present disclosure determines the IBC merge candidate list or the IBC AMVP candidate list based on the candidate list with the largest number of candidates, coding efficiency and coding effectiveness can be improved.

[0007] In a fourth aspect, another method for video processing is proposed. The method includes determining at least one maximum number of candidates of at least one candidate type in a first candidate list for a current video block for conversion between a current video block of a video and a bitstream of the video, determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type, and performing the conversion based on the first candidate list. Because the method according to the fourth aspect of the present disclosure determines the first candidate list based on the maximum number of candidates of the at least one candidate type, coding efficiency and coding effectiveness can be improved.

[0008] In a fifth aspect, another method for video processing is proposed. The method includes determining multiple candidates for a current video block of a video for conversion between the current video block and a video bitstream, where the multiple candidates are at least one candidate type; reordering the multiple candidates by performing an adaptive merge candidate reordering (ARMC) process on the multiple candidates based on the at least one candidate type; determining a motion candidate list based on the reordered multiple candidates and the at least one candidate type; and performing conversion based on the motion candidate list. Since the method according to the fifth aspect of the present disclosure determines the motion candidate list based on ARMC reordering candidates of the at least one candidate type, coding efficiency and coding effectiveness can be improved.

[0009] In a sixth aspect, another method for video processing is proposed. The method includes determining an Intra Block Copy (IBC) Advanced Motion Vector Prediction (AMVP) candidate list for a current video block for conversion between a current video block of a video and a bitstream of the video, without reordering candidates in the IBC AMVP candidate list, and performing conversion based on the IBC AMVP candidate list. Since the method according to the sixth aspect of the present disclosure determines the IBC AMVP candidate list without reordering candidates in the IBC AMVP candidate list, coding efficiency and coding effectiveness can be improved.

[0010] In a seventh aspect, another method for video processing is proposed. The method includes determining a first motion candidate list for a current video block corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block for conversion between the current video block and a bitstream of the video, and performing conversion based on the first and second motion candidate lists, where the determination of the first motion candidate list is different from the determination of the second motion candidate list. The method according to the seventh aspect of the present disclosure can improve coding efficiency and coding effectiveness by differently determining different motion candidate lists corresponding to different coding modes.

[0011] In an eighth aspect, an apparatus for video processing is proposed, the apparatus comprising a processor and a non-transitory memory having instructions thereon, the instructions, when executed by the processor, causing the processor to perform a method according to the first, second, third, fourth, fifth, sixth or seventh aspect of the present disclosure.

[0012] In a ninth aspect, a non-transitory computer-readable storage medium is proposed, the non-transitory computer-readable storage medium storing instructions for causing a processor to perform a method according to the first, second, third, fourth, fifth, sixth or seventh aspect of the present disclosure.

[0013] In a tenth aspect, another non-transitory computer-readable storage medium is proposed. The non-transitory computer-readable storage medium stores a video bitstream generated by a method performed by an apparatus for video processing. The method includes determining at least one history-based motion vector prediction (HMVP) table for a current video block of the video based on at least one of a motion vector (MV) difference threshold for comparing at least two MVs of at least two HMVP candidates, a coding mode of the current video block, or a reference picture list index associated with the current video block, and generating a bitstream based on the at least one HMVP table.

[0014] In an eleventh aspect, a method for storing a bitstream of a video is proposed, the method including: determining at least one history-based motion vector prediction (HMVP) table for a current video block of the video based on at least one of a motion vector (MV) difference threshold for comparing at least two MVs of at least two HMVP candidates, a coding mode of the current video block, or a reference picture list index associated with the current video block; generating a bitstream based on the at least one HMVP table; and storing the bitstream on a non-transitory computer-readable recording medium.

[0015] In a twelfth aspect, another non-transitory computer-readable storage medium is proposed. The non-transitory computer-readable storage medium stores a bitstream of video generated by a method performed by an apparatus for video processing. The method includes determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to a motion candidate list for a current video block of the video based on at least one comparison between the HMVP candidate and at least one candidate in a motion candidate list, and generating a bitstream based on the determination.

[0016] In a thirteenth aspect, a method for storing a bitstream of a video is proposed, the method including: determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to a motion candidate list of a current video block of the video based on at least one comparison between the HMVP candidate and at least one candidate in a motion candidate list; generating a bitstream based on the determination; and storing the bitstream on a non-transitory computer-readable recording medium.

[0017] In a fourteenth aspect, another non-transitory computer-readable storage medium is proposed. The non-transitory computer-readable storage medium stores a bitstream of video generated by a method performed by an apparatus for video processing. The method includes: determining a first candidate list for a current video block of the video based on a maximum number of motion candidates in the first candidate list; determining a motion candidate list for the current video block based on the first candidate list, where the motion candidate list includes at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; and generating a bitstream based on the motion candidate list.

[0018] In a fifteenth aspect, a method for storing a bitstream of a video is proposed, the method including: determining a first candidate list for a current video block of the video based on a maximum number of motion candidates in the first candidate list; determining a motion candidate list for the current video block based on the first candidate list, where the motion candidate list includes at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; generating a bitstream based on the motion candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

[0019] In a sixteenth aspect, another non-transitory computer-readable storage medium is proposed, the non-transitory computer-readable storage medium storing a bitstream of video generated by a method performed by an apparatus for video processing, the method including: determining at least one maximum number of candidates of at least one candidate type in a first candidate list for a current video block of the video, determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type, and generating a bitstream based on the first candidate list.

[0020] In a seventeenth aspect, a method for storing a bitstream of a video is proposed, the method including: determining at least one maximum number of candidates of at least one candidate type in a first candidate list for a current video block of the video, determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type, generating a bitstream based on the first candidate list, and storing the bitstream on a non-transitory computer-readable recording medium.

[0021] In an eighteenth aspect, another non-transitory computer-readable recording medium is proposed. The non-transitory computer-readable recording medium stores a bitstream of video generated by a method performed by an apparatus for video processing. The method includes determining a plurality of candidates for a current video block of the video, the plurality of candidates being of at least one candidate type, reordering the plurality of candidates by performing an adaptive reordering of merge candidates (ARMC) operation on the plurality of candidates based on the at least one candidate type, determining a motion candidate list based on the reordered plurality of candidates and the at least one candidate type, and generating a bitstream based on the motion candidate list.

[0022] In a nineteenth aspect, a method for storing a bitstream of a video is proposed, the method including: determining a plurality of candidates for a current video block of a video, the plurality of candidates being of at least one candidate type; reordering the plurality of candidates by performing an adaptive reordering of merge candidates (ARMC) process on the plurality of candidates based on the at least one candidate type; determining a motion candidate list based on the reordered plurality of candidates and the at least one candidate type; generating a bitstream based on the motion candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

[0023] In a twentieth aspect, another non-transitory computer-readable recording medium is proposed. The non-transitory computer-readable recording medium stores a bitstream of video generated by a method performed by an apparatus for video processing. The method includes determining an Intra Block Copy (IBC) Advanced Motion Vector Prediction (AMVP) candidate list for a current video block of the video without reordering candidates in the IBC AMVP candidate list, and generating a bitstream based on the IBC AMVP candidate list.

[0024] In a twenty-first aspect, a method for storing a bitstream of a video is proposed, the method including: determining an Intra Block Copy (IBC) Advanced Motion Vector Prediction (AMVP) candidate list for a current video block of the video without reordering candidates in the IBC AMVP candidate list; generating a bitstream based on the IBC AMVP candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

[0025] In a twenty-second aspect, another non-transitory computer-readable storage medium is proposed, the non-transitory computer-readable storage medium storing a bitstream of video generated by a method performed by an apparatus for video processing, the method including determining a first motion candidate list for a current video block of the video corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block, and generating a bitstream based on the first and second motion candidate lists, wherein the determination of the first motion candidate list is different from the determination of the second motion candidate list.

[0026] In a twenty-third aspect, a method for storing a bitstream of a video is proposed, the method including: determining a first motion candidate list for a current video block of the video corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block; generating a bitstream based on the first and second motion candidate lists; and storing the bitstream on a non-transitory computer-readable recording medium, wherein the determination of the first motion candidate list is different from the determination of the second motion candidate list.

[0027] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. [Brief explanation of the drawings]

[0028] The above and other objects, features, and advantages of exemplary embodiments of the present disclosure will become more apparent through the following detailed description taken in conjunction with the accompanying drawings, in which like reference numerals generally refer to like components.

[0029] [Figure 1] 1 shows a block diagram illustrating an example video coding system according to some embodiments of the present disclosure.

[0030] [Figure 2] 1 shows a block diagram illustrating a first exemplary video encoder according to some embodiments of the present disclosure.

[0031] [Figure 3] 1 shows a block diagram illustrating an exemplary video decoder according to some embodiments of the present disclosure.

[0032] [Figure 4] 1 illustrates an exemplary diagram showing exemplary locations of spatial merge candidates.

[0033] [Figure 5] 1 shows an exemplary diagram illustrating candidate pairs considered for redundancy checking of spatial merge candidates.

[0034] [Figure 6] 10 shows an exemplary diagram illustrating exemplary motion vector scaling for temporal merge candidates.

[0035] [Figure 7] 1 shows an exemplary diagram illustrating candidate positions C0 and C1 for temporal merge candidates.

[0036] [Figure 8] 1 shows an exemplary diagram illustrating VVC spatial neighboring blocks of a current block.

[0037] [Figure 9] 1 shows an example virtual block in the i-th search round.

[0038] [Figure 10] 1 illustrates an exemplary diagram showing spatial neighboring blocks used to derive spatial merge candidates.

[0039] [Figure 11A] SbTMVP processing in VVC. [Figure 11B] SbTMVP processing in VVC.

[0040] [Figure 12A] Shows the processing order of the current CTU and the samples available in the current and left CTUs. [Figure 12B] Shows the processing order of the current CTU and the samples available in the current and left CTUs. [Figure 12C] Shows the processing order of the current CTU and the samples available in the current and left CTUs. [Figure 12D] Shows the processing order of the current CTU and the samples available in the current and left CTUs.

[0041] [Figure 13] Indicates the neighborhood samples used to calculate the SAD.

[0042] [Figure 14] Indicates the neighboring samples used to calculate the SAD for sub-CU level motion information.

[0043] [Figure 15] 1 shows an exemplary diagram illustrating a sorting process.

[0044] [Figure 16] 1 shows an exemplary diagram illustrating the reordering process in an encoder.

[0045] [Figure 17] 1 shows an exemplary diagram illustrating the reordering process in a decoder.

[0046] [Figure 18] 10 shows an exemplary diagram illustrating template matching performed in a search area around an initial MV.

[0047] [Figure 19]1 shows an exemplary diagram illustrating template matching prediction.

[0048] [Figure 20] 1 shows an exemplary diagram illustrating the intra-template matching search area used.

[0049] [Figure 21] 1 shows an exemplary diagram illustrating a template and its reference sample used in TIMD.

[0050] [Figure 22] 1 shows an exemplary diagram illustrating a template and a reference sample of the template;

[0051] [Figure 23] 1 shows an exemplary diagram illustrating templates and reference samples of templates in Reference List 0 and Reference List 1.

[0052] [Figure 24] 10 shows an exemplary diagram illustrating a template and reference samples of a block with sub-block motion using motion information of a sub-block of a current block.

[0053] [Figure 25] 1 shows an exemplary diagram illustrating a template for a block with sub-block motion using motion information of each sub-template and a reference sample for the template;

[0054] [Figure 26] 1 shows an exemplary diagram illustrating a template and a reference sample of the template for a block using OBMC.

[0055] [Figure 27] 1 shows an exemplary diagram illustrating motion estimation of a rectangular block with hash values ​​of square sub-blocks.

[0056] [Figure 28]1 illustrates an exemplary luma mapping with chroma scaling architecture.

[0057] [Figure 29] Sorting of merge candidates. An example of pairwise sorting in ARMC-TM and additional pairwise candidates after sorting is shown.

[0058] [Figure 30A] 1 shows an exemplary diagram illustrating candidate locations for spatial candidates;

[0059] [Figure 30B] 1 shows an exemplary diagram illustrating candidate locations for temporal candidates;

[0060] [Figure 31] 10 shows an exemplary diagram illustrating deriving a motion field for a sub-CU bv from its corresponding collocated sub-CU by applying a motion shift from its spatial neighbors.

[0061] [Figure 32] 1 shows an exemplary diagram illustrating exemplary intra-template matching.

[0062] [Figure 33A] FIG. 10 is an exemplary diagram illustrating that the reference template is outside the current picture.

[0063] [Figure 33B] 10 shows an exemplary diagram illustrating clipping a BV so that the reference template is located inside the current picture.

[0064] [Figure 34] Indicates the non-adjacent locations to be used.

[0065] [Figure 35] 1 shows an exemplary diagram illustrating spatial candidates used in an IBC merge / AMVP candidate list.

[0066] [Figure 36] 1 shows an exemplary diagram illustrating a template and a reference sample of the template;

[0067] [Figure 37] 1 shows exemplary locations used by TMVP.

[0068] [Figure 38] Here is an example of generating a HAPC.

[0069] [Figure 39] 1 shows spatial neighborhoods for deriving affine merge candidates.

[0070] [Figure 40] 1 shows an example of affine merge candidates constructed from non-adjacent neighbors.

[0071] [Figure 41] 1 shows an example of an affine motion model based on control points.

[0072] [Figure 42] An example of affine MVF for each subblock is shown below.

[0073] [Figure 43] 10 illustrates an exemplary position of an inherited affine motion predictor.

[0074] [Figure 44] An example of control point motion vector inheritance is shown.

[0075] [Figure 45] 10 shows exemplary locations of candidate positions for constructed affine merge modes.

[0076] [Figure 46] An example of the use of motion vectors for the proposed combining method is given.

[0077] [Figure 47] An example of a sub-block MV VSB and a pixel Δv(i,j) (arrow) is shown.

[0078] [Figure 48] 1 shows an example of neighboring reconstructed blocks and the current predicted block.

[0079] [Figure 49] 1 shows an example of neighboring reconstructed blocks and the current predicted block.

[0080] [Figure 50A] 1 shows an exemplary reference template outside the valid IBC reference region.

[0081] [Figure 50B] An example is shown illustrating locating a reference template not by the current template but by the BV of the corresponding BV candidate for the current block.

[0082] [Figure 51] 1 illustrates a flowchart of a method for video processing according to some embodiments of the present disclosure.

[0083] [Figure 52] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0084] [Figure 53] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0085] [Figure 54] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0086] [Figure 55] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0087] [Figure 56] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0088] [Figure 57] 10 illustrates another flowchart of a method for video processing according to some embodiments of the present disclosure.

[0089] [Figure 58] FIG. 1 illustrates a block diagram of a computing device in which various embodiments of the present disclosure may be implemented.

[0090] Throughout the drawings, the same or similar reference numbers typically refer to the same or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0091] Next, the principles of the present disclosure will be described with reference to some embodiments. It should be understood that these embodiments are provided for illustrative purposes only, to help those skilled in the art understand and practice the present disclosure, and are not intended to imply any limitations on the scope of the present disclosure. The disclosure described herein can be implemented in various forms other than those described below.

[0092] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0093] References in this disclosure to "one embodiment," "embodiment," "exemplary embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments need include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an exemplary embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly stated.

[0094] Although terms such as "first" and "second" may be used herein to describe various elements, it should be understood that these elements are not limited by these terms. These terms are merely used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0095] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit example embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that as used herein, the terms "comprises," "comprising," "has," "having," "includes," and / or "including" specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0096] Example Environment 1 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure. As shown, video coding system 100 may include a source device 110 and a destination device 120. Source device 110 may also be referred to as a video encoding device, and destination device 120 may also be referred to as a video decoding device. In operation, source device 110 may be configured to generate encoded video data, and destination device 120 may be configured to decode the encoded video data generated by source device 110. Source device 110 may include a video source 112, a video encoder 114, and an input / output (I / O) interface 116.

[0097] Video source 112 may include sources such as a video capture device. Examples of a video capture device include, but are not limited to, an interface for receiving video data from a video content provider, a computer graphics system for generating video data, and / or combinations thereof.

[0098] The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bitstream. The bitstream may include a bit sequence that forms a coded representation of the video data. The bitstream may include coded pictures and associated data. A coded picture is a coded representation of a picture. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The I / O interface 116 may include a modulator / demodulator and / or transmitter. The coded video data may be transmitted directly to the destination device 120 via the I / O interface 116 over the network 130A. The coded video data may also be stored on a storage medium / server 130B for access by the destination device 120.

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

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

[0101] FIG. 2 is a block diagram illustrating an example of a video encoder 200, which may be an example of the video encoder 114 in the system 100 shown in FIG. 1, according to some embodiments of the disclosure.

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

[0103] In some embodiments, the video encoder 200 may include a division 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 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.

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

[0105] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, may be integrated, but are depicted separately in the example of FIG. 2 for ease of explanation.

[0106] Partition unit 201 may divide a picture into one or more video blocks. Video encoder 200 and video decoder 300 may support a variety of video block sizes.

[0107] The mode select unit 203 may select one of the coding modes (intra or inter) based on, for example, an error result, and provide the generated intra-coded or inter-coded blocks to the residual generation unit 207 to generate residual block data and to the reconstruction unit 212 to reconstruct coded blocks for use as reference pictures. In some examples, the mode select unit 203 may select a combination of intra and inter prediction (CIIP) mode in which prediction is performed based on an inter prediction signal and an intra prediction signal. In the case of inter prediction, the mode select unit 203 may also select a resolution of the motion vectors of the blocks (e.g., sub-pixel accuracy or integer pixel accuracy).

[0108] To perform inter prediction on the current video block, motion estimation unit 204 may 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 may determine a predicted video block for the current video block based on the motion information and decoded samples of pictures from buffer 213 other than the picture associated with the current video block.

[0109] Motion estimation unit 204 and motion compensation unit 205 may perform different operations on a current video block depending, for example, on whether the current video block is in an I slice, a P slice, or a B slice. As used herein, an "I slice" may refer to a portion of a picture composed of macroblocks, all of which are based on macroblocks within the same picture. Furthermore, as used herein, in some aspects, "P slice" and "B slice" may refer to a portion of a picture composed of macroblocks that are independent of macroblocks within the same picture.

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

[0111] Alternatively, in other examples, motion estimation unit 204 may perform bidirectional prediction on the current video block. Motion estimation unit 204 may search reference pictures in list 0 for a reference video block for the current video block and may also search reference pictures in list 1 for another reference video block for the current video block. Motion estimation unit 204 may then generate reference indexes that indicate the reference pictures in lists 0 and 1 that contain the reference video blocks, and motion vectors that indicate the spatial displacement between the reference video blocks and the current video block. Motion estimation unit 204 may output the reference index and motion vector for the current video block as motion information for the current video block. Motion compensation unit 205 may generate a predicted video block for the current video block based on the reference video block indicated by the motion information for the current video block.

[0112] In some examples, motion estimation unit 204 may output a full set of motion information for decoding processing in a decoder. Alternatively, in some embodiments, motion estimation unit 204 may signal the motion information of the current video block by reference to 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 a neighboring video block.

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

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

[0115] As mentioned above, video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by video encoder 200 include advanced motion vector prediction (AMVP) and merge mode signaling.

[0116] Intra prediction unit 206 may perform intra prediction on the current video block. When performing intra prediction on the current video block, intra prediction unit 206 may generate predictive data for the current video block based on decoded samples of other video blocks within the same picture. The predictive data for the current video block may include a predicted video block and various syntax elements.

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

[0118] In other examples, for the current video block, for example in skip mode, residual data for the current video block may not exist and residual generation unit 207 may not perform the subtraction operation.

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

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

[0121] Inverse quantization unit 210 and inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct a residual video block from the transform coefficient video block. Reconstruction unit 212 may add the reconstructed residual video block to corresponding samples from one or more predicted video blocks generated by prediction unit 202 to generate a reconstructed video block related to the current video block for storage in buffer 213.

[0122] After reconstruction unit 212 reconstructs the video blocks, it may perform a loop filtering operation to reduce video blocking artifacts in the video blocks.

[0123] The entropy encoding unit 214 may receive data from other functional components of the video encoder 200. Upon receiving the data, the entropy encoding unit 214 may perform one or more entropy encoding operations to generate entropy-encoded data and output a bitstream that includes the entropy-encoded data.

[0124] FIG. 3 is a block diagram illustrating an example of a video decoder 300, which may be an example of the video decoder 124 in the system 100 shown in FIG. 1, according to some embodiments of the disclosure.

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

[0126] 3, video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. Video decoder 300 may, in some examples, perform a decoding path that is generally the reverse of the encoding path described with respect to video encoder 200.

[0127] The entropy decoding unit 301 may retrieve an encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 may decode the entropy-coded video data, and from the entropy-decoded video data, the motion compensation unit 302 may determine motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 302 may determine such information, for example, by performing AMVP and merge mode. AMVP involves deriving multiple most probable candidates based on data from neighboring PB and reference pictures. The motion information typically includes horizontal and vertical motion vector displacement values, one or two reference picture indexes, and, in the case of prediction regions in B slices, identification of which reference picture list is associated with each index. As used herein, in some aspects, "merge mode" may refer to deriving motion information from spatially or temporally neighboring blocks.

[0128] The motion compensation unit 302 generates motion-compensated blocks and may optionally perform interpolation based on an interpolation filter, the identifier of which may be included in a syntax element to be used with sub-pixel precision.

[0129] Motion compensation unit 302 may calculate sub-integer pixel interpolated values ​​of the reference block using the interpolation filters used by video encoder 200 during encoding of the video block. Motion compensation unit 302 may determine the interpolation filters used by video encoder 200 according to received syntax information and generate the predictive block using the interpolation filters.

[0130] The motion compensation unit 302 may use at least a portion of the syntax information to determine the size of the blocks used to encode the frame(s) and / or slice(s) of the coded video sequence, partition information describing how each macroblock of a picture of the coded video sequence is divided, a mode indicating how each division is coded, one or more reference frames (and reference frame lists) for each inter-coded block, and other information for decoding the coded video sequence. As used herein, in some aspects, a "slice" may refer to a data structure that can be decoded independently from other slices of the same picture in terms of entropy coding, signal prediction, and residual signal reconstruction. A slice can be either an entire picture or a region of a picture.

[0131] The intra prediction unit 303 may form a prediction block from spatially adjacent blocks, for example, using an intra prediction mode received in the bitstream. The inverse quantization unit 304 inverse quantizes, or dequantizes, the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 305 applies an inverse transform.

[0132] Reconstruction unit 306 may obtain decoded blocks, for example, by summing residual blocks with corresponding prediction blocks generated by motion compensation unit 302 or intra prediction unit 303. If desired, a deblocking filter may be applied to filter the decoded blocks to remove blockiness artifacts. The decoded video blocks are stored in buffer 307 to provide reference blocks for subsequent motion compensation / intra prediction and to generate decoded video for presentation on a display device.

[0133] Some exemplary embodiments of the present disclosure are described in detail below. Section headings are used herein for ease of understanding and should not be construed as limiting the embodiments disclosed in a section to that section alone. Furthermore, while some embodiments are described with reference to Versatile Video Coding or other specific video codecs, the disclosed techniques are applicable to other video coding techniques. Furthermore, while some embodiments describe video coding steps in detail, it should be understood that the corresponding decoding steps that undo the coding are performed by a decoder. Furthermore, the term video processing encompasses video coding or compression, video decoding or decompression, and video transcoding, which involves representing video pixels from one compressed format to another or at a different compressed bit rate. 1. Overview The present disclosure relates to video coding techniques, particularly to IBC prediction and related techniques in video coding, which can be applied to existing video coding standards such as HEVC and VVC, as well as to future video coding standards or video codecs. 2. Introduction Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, while ISO / IEC developed MPEG-1 and MPEG-4 Visual. The two organizations jointly developed H.262 / MPEG-2 Video, H.264 / MPEG-4 Advanced Video Coding (AVC), and H.265 / HEVC. Video coding standards from H.262 onward are based on a hybrid video coding architecture employing temporal prediction and transform coding. To explore future video coding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. JVET meetings are held quarterly. At the April 2018 JVET meeting, the new video coding standard was officially named Versatile Video Coding (VVC) and the first version of the VVC Test Model (VTM) was released. Since then, the VVC working documents and test model VTM have been updated at each meeting. The VVC project achieved technical completion (FDIS) at the July 2020 meeting. 2.1. Enhanced Merge Prediction VVC creates a merge candidate list by including the following five candidates in order: 1) Spatial MVP from spatially nearby CUs, 2) Temporal MVP from juxtaposed CUs; 3) History-based MVP from FIFO tables, 4) Pairwise average MVP, 5) Zero's music video. The size of the merge list is signaled in the sequence parameter set header, and the maximum allowed size of the merge list is 6. For each CU code in merge mode, the index of the best merge candidate is coded using truncated unary binarization (TU). The first bin of the merge index is coded with context, and bypass coding is used for the other bins. The derivation process of merge candidates for each category is provided in this section. Similar to HEVC, VVC also supports parallel derivation of merge candidate lists for all CUs within a certain size region. 2.1.1. Spatial Candidate Derivation The derivation of spatial merge candidates in VVC is the same as that in HEVC, except that the positions of the first two merge candidates are swapped. Figure 4 shows an example diagram 400 illustrating example positions of spatial merge candidates. Up to four merge candidates are selected from the candidates at the positions depicted in Figure 4. The derivation order is B1, A1, B0, A0, and B2. Position B2 is considered only if one or more CUs at positions B0, A0, B1, and A1 are unavailable (e.g., because they belong to another slice or tile) or are intra-coded. After the candidate at position A1 is added, the addition of the remaining candidates undergoes a redundancy check that ensures that candidates with the same motion information are removed from the list, so as to improve coding efficiency. Figure 5 shows an example diagram 500 illustrating candidate pairs considered for redundancy check of spatial merge candidates. To reduce computational complexity, the aforementioned redundancy check does not consider all possible candidate pairs. Instead, only pairs linked by arrows in FIG. 5 are considered, and candidates are added to the list only if the corresponding candidates used for redundancy checking do not have the same motion information. 2.2.2. Temporal Candidate Derivation In this step, only one candidate is added to the list. In particular, in deriving this temporal merge candidate, a scaled motion vector is derived based on the co-located CU belonging to the co-located reference picture. The reference picture list used to derive the co-located CU is explicitly signaled in the slice header. Figure 6 shows an example diagram 600 illustrating example motion vector scaling for a temporal merge candidate. The scaled motion vector of the temporal merge candidate is obtained as shown by the dotted line in Figure 6 and is scaled from the motion vector of the co-located CU using POC distances tb and td, where tb is defined as the POC difference between the reference picture of the current picture and the current picture, and td is defined as the POC difference between the reference picture of the co-located picture and the co-located picture. The reference picture index of the temporal merge candidate is set equal to 0. 7 shows an example diagram 700 illustrating candidate positions for temporal merge candidates C0 and C1. As shown in FIG. 7, the position of the temporal candidate is selected between candidates C0 and C1. If the CU at position C0 is unavailable, intra-coded, or outside the current row of the CTU, then position C1 is used. Otherwise, position C0 is used to derive the temporal merge candidate. 2.1.3. History-Based Merge Candidate Deriving History-based MVP (HMVP) merge candidates are added to the merge list after spatial MVP and TMVP. In this method, the motion information of previously coded blocks is stored in a table and used as the MVP for the current CU. The table with multiple HMVP candidates is maintained throughout the encoding / decoding process. When a new CTU row is found, the table is reset (emptied). Every time there is a non-subblock inter-coded CU, the associated motion information is added as a new HMVP candidate to the last entry in the table. The size of the HMVP table, S, is set to 6, indicating that up to six history-based MVP (HMVP) candidates can be added to the table. When inserting a new motion candidate into the table, a constrained first-in-first-out (FIFO) rule is utilized, where a redundancy check is first applied to detect whether there is an identical HMVP in the table. If found, the identical HMVP is removed from the table and all subsequent HMVP candidates are promoted. HMVP candidates can be used in the merge candidate list construction process. The most recent HMVP candidates in the table are examined in order and inserted into the candidate list after the TMVP candidate. Redundancy checks are applied to HMVP candidates for spatial or temporal merge candidates. To reduce the number of redundancy check operations, the following simplification operations are introduced: 1. The number of HMPV candidates used to generate the merge list is set as (N<=4)?M:(8-N), where N is the number of existing candidates in the merge list and M is the number of HMVP candidates available in the table. 2. When the total number of available merge candidates reaches the maximum allowed number of merge candidates minus one, the process of building a merge candidate list from HMVP ends. 2.1.4. Deriving Pairwise Average Merge Candidates Pairwise average candidates are generated by averaging predefined pairs of candidates in the existing merge candidate list. The predefined pairs are defined as {(0,1),(0,2),(1,2),(0,3),(1,3),(2,3)}, where the numbers indicate the merge index into the merge candidate list. The averaged motion vector is calculated separately for each reference list. If both motion vectors are available in one list, these two motion vectors are averaged even if they point to different reference pictures. If only one motion vector is available, that one is used directly. If no motion vectors are available, this list is kept invalid. If adding pairwise average merge candidates does not fill up the merge list, a zero MVP is inserted at the end until the maximum number of merge candidates is reached. 2.2. New Merge Candidates 2.2.1 Deriving Non-adjacent Merge Candidates 8 shows an example diagram 800 illustrating VVC spatial neighbors of a current block. In VVC, the five spatial neighbors and one temporal neighbor shown in FIG. 8 are used to derive merge candidates. Using the same pattern as VVC, we propose to derive additional merge candidates from positions that are not adjacent to the current block. To achieve this, in each search round i, we generate a virtual block based on the current block as follows: First, the relative position of the virtual block to the current block is calculated by: Offsetx=-i×gridX,Offsety=-i×gridY where Offsetx and Offsety represent the offset of the top left corner of the virtual block relative to the top left corner of the current block, and gridX and gridY are the width and height of the search grid. The width and height of the virtual block are then calculated by: newWidth=i×2×gridX+currWidth newHeight=i×2×gridY+currHeight where currWidth and currHeight are the width and height of the current block, and newWidth and newHeight are the width and height of the new virtual block. gridX and gridY are currently set to currWidth and currHeight respectively. 9 shows an example diagram 900 illustrating the virtual blocks in the i-th search round. FIG. 9 illustrates the relationship between the virtual blocks and the current block. After generating the virtual blocks, block A i ,B i ,C i ,D i and E i can be considered as the VVC spatial neighbors of the virtual block, and their positions are obtained in the same pattern as VVC. When search round i is 0, the virtual block is obviously the current block. In this case, block A i,B i ,C i ,D i and E i are the spatial neighboring blocks used in VVC merge mode. When constructing the merge candidate list, pruning is performed to ensure that each element in the merge candidate list is unique. The maximum search rounds is set to 1, which means that 5 non-adjacent spatial blocks are utilized. Non-adjacent spatial merge candidates are inserted into the merge list after the temporal merge candidates in the order B1->A1->C1->D1->E1. 2.2.2 Non-adjacent spatial candidates Non-adjacent spatial merge candidates are inserted into the regular merge candidate list after TMVP. Figure 10 shows an example diagram 1000 illustrating spatial neighboring blocks used to derive spatial merge candidates. The spatial merge candidate pattern is shown in Figure 10. The distance between non-adjacent spatial candidates and the current coding block is based on the width and height of the current coding block. No line buffer limitations apply. 2.2.3 STMVP It is proposed to derive an average candidate as an STMVP candidate using three spatial merging candidates and one temporal merging candidate. The STMVP is inserted before the top-left spatial merge candidate. The STMVP candidate is pruned along with all previous merge candidates in the merge list. For spatial candidates, the first three candidates in the current merge candidate list are used. For temporal candidates, the same positions as in VTM / HEVC collocation positions are used. For spatial candidates, we denote the first, second, and third candidates inserted into the current merge candidate list before STMVP as F, S, and T. The temporal candidate at the same position as the collocation position in VTM / HEVC used in TMVP is denoted as Col. The motion vector (denoted as mvLX) for the prediction direction X of the STMVP candidate is derived as follows: 1) If the reference indices of the four merge candidates are all valid and all equal to zero in the prediction direction X (X=0 or 1), mvLX=(mvLX_F+mvLX_S+mvLX_T+mvLX_Col)>>2. 2) If the reference indices of three of the four merge candidates are valid and equal to zero in the prediction direction X (X=0 or 1), mvLX = (mvLX_F × 3 + mvLX_S × 3 + mvLX_Col × 2) >> 3 or mvLX = (mvLX_F × 3 + mvLX_T × 3 + mvLX_Col × 2) >> 3 or mvLX=(mvLX_S×3+mvLX_T×3+mvLX_Col×2)>>3. 3) If the reference indices of two of the four merge candidates are valid and equal to zero in the prediction direction X (X=0 or 1), mvLX=(mvLX_F+mvLX_Col)>>1 or mvLX=(mvLX_S+mvLX_Col)>>1 or mvLX=(mvLX_T+mvLX_Col)>>1. NOTE: If no temporal candidates are available, STMVP mode is turned off. 2.2.4 Merge List Size When considering both non-adjacent and STMVP merge candidates, the size of the merge list is signaled in the sequence parameter set header, and the maximum allowed size of the merge list is increased (e.g., to 8). 2.3. Sub-block-based Temporal Motion Vector Prediction (SbTMVP) VVC supports the Subblock-based Temporal Motion Vector Prediction (SbTMVP) method. Similar to HEVC's Temporal Motion Vector Prediction (TMVP), SbTMVP uses motion fields in co-located pictures to improve the motion vector prediction and merge mode of CUs in the current picture. SbTMVP uses the same co-located pictures used by TMVP. SbTMVP differs from TMVP in two main ways: - TMVP predicts movements at the CU level, while SbTMVP predicts movements at the sub-CU level; - While TMVP fetches temporal motion vectors from the adjacent block of the adjacent picture (the adjacent block is the bottom right or center block with respect to the current CU), SbTMVP applies a motion shift before fetching temporal motion information from the adjacent picture, and the motion shift is obtained from a motion vector from one of the spatial neighboring blocks of the current CU. The process of SbTMVP is shown in Figures 11A and 11B. SbTMVP predicts the motion vectors of sub-CUs within the current CU in two steps. Figure 11A shows the spatial neighborhood blocks used by SbTMVP. In the first step, the spatial neighborhood A1 in Figure 11A is examined. If A1 has a motion vector that uses a co-located picture as its reference picture, this motion vector is selected as the motion shift to be applied. If no such motion vector is identified, the motion shift is set to (0,0). FIG. 11B illustrates deriving a sub-CU motion field by applying a motion shift from a spatial neighbor and scaling the motion information from the corresponding co-located sub-CU. In the second step, the motion shift identified in step 1 is applied (i.e., added to the coordinates of the current block) to obtain sub-CU-level motion information (motion vectors and reference indices) from the co-located picture, as shown in FIG. 11B. In the example of FIG. 11B, assume that the motion shift is set to the motion of block A1. Then, for each sub-CU, the motion information of the corresponding block (the smallest motion grid covering the center sample) in the co-located picture is used to derive the sub-CU's motion information. After the motion information of the co-located sub-CU is identified, it is converted into the motion vector and reference indices of the current sub-CU in a manner similar to the TMVP processing of HEVC. Here, temporal motion scaling is applied to align the reference picture of the temporal motion vector with that of the current CU. In VVC, a combined subblock-based merge list containing both SbTMVP candidates and affine merge candidates is used to signal the subblock-based merge mode. SbTMVP mode is enabled / disabled by a sequence parameter set (SPS) flag. When SbTMVP mode is enabled, the SbTMVP predictor is added as the first entry in the list of subblock-based merge candidates, followed by the affine merge candidates. The size of the subblock-based merge list is signaled in the SPS, and the maximum allowed size of a subblock-based merge list is 5 in VVC. The size of the sub-CUs used in SbTMVP is fixed to 8x8, and similar to the affine merge mode, SbTMVP mode only applies to CUs whose width and height are both greater than or equal to 8. The coding logic of the additional SbTMVP merge candidate is the same as other merge candidates, that is, for each CU of a P or B slice, an additional RD check is performed to determine whether to use the SbTMVP candidate. 2.4. Intra-Block Copy (IBC) Intra Block Copy (IBC) is a tool employed in the HEVC extension to SCC. It is well known for significantly improving the coding efficiency of screen content material. Since IBC mode is implemented as a block-level coding mode, block matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to a reference block already reconstructed within the current picture. The luma block vectors of IBC-coded CUs are integer-precision. Chroma block vectors are also rounded to integer precision. When combined with AMVR, IBC mode can switch between 1-pel and 4-pel motion vector precision. IBC-coded CUs are treated as a third prediction mode other than intra or inter prediction modes. IBC mode applies to CUs whose width and height are both 64 luma samples or less. On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs an RD check for blocks whose either width or height is not larger than 16 luma samples. In non-merge mode, the block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a block-matching-based local search is performed. In hash-based search, hash key matching (32-bit CRC) between the current block and the reference block is extended to all allowed block sizes. The hash key calculation for each location in the current picture is based on 4x4 sub-blocks. For larger-sized current blocks, the hash key is determined to match the hash key of the reference block when the hash keys of all 4x4 sub-blocks match the hash key of the corresponding reference location. If the hash keys of multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matched reference block is calculated and the one with the smallest cost is selected. In a block match search, the search range is set to cover both the previous and current CTUs. At the CU level, the IBC mode is signaled with a flag and can be signaled as IBC AMVP mode or IBC skip / merge mode as follows: - IBC skip / merge mode: The merge candidate index is used to indicate which block vector from neighboring candidate IBC coded blocks in the list is used to predict the current block. The merge list consists of spatial, HMVP, and pairwise candidates. - IBC AMVP mode: Block vector differentials are coded in the same way as motion vector differentials. Block vector prediction uses two candidates as predictors, one from the left neighbor and one from the above neighbor (if IBC coded). If neither neighbor is available, a default block vector is used as the predictor. A flag is signaled indicating the block vector predictor index. 2.4.1 Simplifying IBC Vector Prediction The BV predictors for merge and AMVP modes in IBC share a common predictor list consisting of the following elements: Two spatially nearby locations (A0, B0 in Figure 4), 5 HMVP entries, · Vectors are zero by default. In merge mode, up to the first 6 entries of this list are used, and in AMVP mode, the first 2 entries of this list are used, and the list conforms to the requirements of a shared merge list area (sharing the same list within the SMR). 2.4.2 IBC Reference Area To reduce memory consumption and decoder complexity, IBC in VVC only allows reconstructing parts of a predefined region that includes the region of the current CTU and some regions of the left CTU. Figures 12A-12D show exemplary diagrams 1210, 1230, 1250, and 1270 illustrating the processing order of the current CTU and the samples available in the current CTU and the left CTU. Figures 12A-12D show reference regions for IBC mode, where each block represents a 64x64 luma sample unit. Depending on the position of the current coding CU within the current CTU, the following applies: - If the current block is the top-left 64x64 block of the current CTU, in addition to the already reconstructed samples in the current CTU, it can also refer to the reference samples in the bottom-right 64x64 block of the left CTU using CPR mode.The current block can also refer to the reference samples in the bottom-left 64x64 block of the left CTU and the reference samples in the top-right 64x64 block of the left CTU using CPR mode. - If the current block corresponds to the top right 64x64 block of the current CTU, in addition to the already reconstructed samples in the current CTU, if the luma position (0,64) for the current CTU has not yet been reconstructed, the current block can also refer to reference samples in the bottom left 64x64 block and bottom right 64x64 block of the left CTU using CPR mode; otherwise, the current block can also refer to reference samples in the bottom right 64x64 block of the left CTU. - If the current block corresponds to the bottom-left 64x64 block of the current CTU, in addition to the already reconstructed samples in the current CTU, if the luma position (64,0) for the current CTU has not yet been reconstructed, the current block can also refer to reference samples in the top-right 64x64 block and bottom-right 64x64 block of the left CTU using CPR mode. Otherwise, the current block can also refer to reference samples in the bottom-right 64x64 block of the left CTU using CPR mode. - If the current block falls within the bottom right 64x64 block of the current CTU, the CPR mode can be used to refer only to already reconstructed samples within the current CTU. Due to this restriction, IBC mode can be implemented using local on-chip memory in hardware implementations. 2.4.3 Interaction of IBC with other coding tools The interaction of IBC mode with other inter-coding tools in VVC, such as pairwise merge candidates, history-based motion vector predictor (HMVP), combined intra / inter prediction mode (CIIP), merge mode with motion vector difference (MMVD), and geometric partitioning mode (GPM), is as follows: - IBC can be used with pairwise merge candidates and HMVP. A new pairwise IBC merge candidate can be generated by averaging two IBC merge candidates. In the case of HMVP, the IBC motion is inserted into a history buffer for future reference. - IBC cannot be used in combination with the following intertools: Affine Motion, CIIP, MMVD, GPM. - IBC cannot be used for chroma coding blocks when using DUAL_TREE splitting. Unlike the HEVC Screen Content Coding extension, reference picture list 0 for IBC prediction no longer includes the current picture as one of the reference pictures. The motion vector derivation process for IBC mode excludes all neighboring blocks in inter mode and vice versa. The following IBC design aspects apply: - IBC shares the same process as regular MV merging, including pairwise merge candidates and history-based motion predictors, but TMVP and zero vectors are not allowed as they are invalid in IBC mode. - Separate HMVP buffers (5 candidates each) are used for conventional MV and IBC. - Block vector constraints are implemented in the form of bitstream conformance constraints, where the encoder must ensure that there are no invalid vectors in the bitstream, and if a merge candidate is invalid (out of range or 0), no merging will be used. Such bitstream conformance constraints are expressed in terms of virtual buffers, as described below. - For deblocking purposes, IBC is treated as inter mode. - If the current block is coded using IBC prediction mode, the AMVR does not use quarter-pels. Instead, the AMVR is signaled to indicate only whether the MV is inter-pel or 4 integer-pels. - The number of IBC merging candidates can be signaled in the slice header separately from the number of normal, sub-block, and geometric merging candidates. The concept of a virtual buffer is used to describe the allowable reference area and valid block vectors for the IBC prediction mode. If the CTU size is ctbSize, the width of the virtual buffer ibcBuf is wIbcBuf = 128x128 / ctbSize, and the height is hIbcBuf = ctbSize. For example, if the CTU size is 128x128, the size of ibcBuf is also 128x128; if the CTU size is 64x64, the size of ibcBuf is 256x64; and if the CTU size is 32x32, the size of ibcBuf is 512x32. The size of the VPDU is min(ctbSize,64) in each dimension. v =min(ctbSize,64). The virtual IBC buffer ibcBuf is maintained as follows: - Refresh the entire ibcBuf with an invalid value of -1 at the start of decoding each CTU row. - When starting decoding the VPDU (xVPDU, yVPDU) for the top left corner of the picture, set ibcBuf[x][y]=-1, where x=xVPDU%wIbcBuf,...,xVPDU%wIbcBuf+W v-1;y=yVPDU%ctbSize,...,yVPDU%ctbSize+W v -1. - After decoding the CU containing (x, y) based on the top left corner of the image, set it as follows: - ibcBuf[x%wIbcBuf][y%ctbSize]=recSample[x][y]. For a block covering coordinates (x,y), it is valid if the following is true for the block vector bv=(bv[0],bv[1]), otherwise it is invalid: ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] is not equal to -1. 2.4.4 IBC Virtual Buffer Test The luma block vector bvL (1 / 16 fractional sample precision luma block vector) must obey the following constraints: - -CtbSizeY is greater than or equal to ((yCb+(bvL[1]>>4))&(CtbSizeY-1))+cbHeight. - IbcVirBuf[0][(x+(bvL[0]>>4))&(IbcBufWidthY-1)][(y+(bvL[1]>>4)&(CtbSizeY-1)] shall not be equal to -1 when x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1. Otherwise, the bvL is considered an invalid bv. Samples are processed in CTB units. The width and height array size of each luma CTB is CtbSizeY in samples. (xCb,yCb) is the luma position of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture. - cbWidth specifies the width of the current coding block in luma samples. - cbHeight specifies the height of the current coding block in luma samples. 2.5. Template Matching-Based Adaptive Merge Candidate Reordering To improve coding efficiency, after the merge candidate list is constructed, the order of each merge candidate is adjusted according to the template matching cost. The merge candidates are arranged in the list in ascending order of template matching cost, which is operated in the form of subgroups. FIG. 13 shows an exemplary diagram 1300 illustrating neighboring samples used to calculate SAD. FIG. 14 shows an exemplary diagram 1400 illustrating neighboring samples used to calculate SAD for sub-CU level motion information. The template matching cost is measured by the SAD (sum of absolute differences) between neighboring samples of the current CU and their corresponding reference samples. If a merge candidate contains bi-predictive motion information, the corresponding reference sample is the average of the corresponding reference sample in reference list 0 and the corresponding reference sample in reference list 1, as shown in FIG. 13. If a merge candidate contains sub-CU level motion information, the corresponding reference sample is composed of neighboring samples of the corresponding reference sub-block, as shown in FIG. 14. Figure 15 shows an example diagram 1500 illustrating the sorting process. The sorting process operates in subgroups as shown in Figure 15. The first three merge candidates are sorted together. The next three merge candidates are sorted together. The template size (width of the left template or height of the top template) is 1. The subgroup size is 3. 2.6. Adaptive Merge Candidate Lists We can assume that the number of merge candidates is 8. The first 5 merge candidates are the first subgroup, and the next 3 merge candidates are the second subgroup (i.e., the last subgroup). 16 shows an example diagram 1600 illustrating the reordering process in the encoder. In the encoder, after the merge candidate list is constructed in block 1602, several merge candidates are adaptively reordered in ascending order of the cost of the merge candidates, as shown in FIG. More specifically, in block 1604, the template matching costs of the merge candidates in all subgroups except the last subgroup are calculated, then in block 1606, the merge candidates in each subgroup except the last subgroup are sorted, and finally, in block 1608, the final merge candidate list is obtained. Figure 17 shows an example diagram 1700 illustrating the reordering process in a decoder. In the decoder, after the merge candidate list is constructed, some merge candidates are adaptively reordered / no merge candidates are adaptively reordered in ascending order of merge candidate cost, as shown in Figure 17. In Figure 17, the subgroup in which the selected (signaled) merge candidate is located is called the selected subgroup. More specifically, if the selected merge candidate is located in the last subgroup in block 1702, the merge candidate list construction process ends after the selected merge candidate is derived in block 1704, and no reordering is performed and no changes are made to the merge candidate list in block 1706. Otherwise, the execution process is as follows: In block 1708, after all merge candidates in the selected subgroup are derived, the merge candidate list construction process ends, in block 1710, the template matching costs of the merge candidates in the selected subgroup are calculated, in block 1712, the merge candidates in the selected subgroup are sorted, and finally in block 1714, a new merge candidate list is obtained. For both the encoder and decoder, the template matching cost is derived as a function of T and RT, where T is the sample set within the template and RT is the reference sample set for the template. When deriving the reference samples for the merge candidate template, the motion vectors of the merge candidate are rounded to integer pixel precision, and can also be derived using an 8-tap or 12-tap luma interpolation filter. The reference sample (RT) of the template for bidirectional prediction is derived as follows by the weighted average of the reference sample (RT0) of the template in reference list 0 and the reference sample (RT1) of the template in reference list 1:

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

Claims

1. 1. A method for video processing, comprising: for converting between a current video block of a video and a bitstream of said video, a motion vector (MV) difference threshold for comparing at least two MVs of at least two history-based motion vector prediction (HMVP) candidates; the coding mode of the current video block, or a reference picture list index associated with the current video block; determining at least one HMVP table for the current video block based on at least one of: and performing said conversion based on said at least one HMVP table.

2. The method of claim 1 , wherein the at least one HMVP table includes a plurality of HMVP tables, the plurality of HMVP tables being determined for different coding modes.

3. The method of claim 2 , wherein the plurality of HMVP tables have different table sizes.

4. The method of any one of claims 1 to 3, wherein a single HMVP table is associated with multiple coding modes.

5. The method of any one of claims 1 to 4, wherein the at least one HMVP table includes more than two HMVP tables.

6. Determining the at least one HMVP table comprises: determining whether a difference between a first motion candidate to be added to a target HMVP table of the at least one HMVP table and a second motion candidate in the target HMVP table is less than the MV difference threshold; and updating the target HMVP table based on the determination.

7. updating the target HMVP table based on the determination, adding the first motion candidate to the head or tail of the target HMVP table in response to determining that the difference is less than the MV difference threshold; and removing the second motion candidate from the target HMVP table.

8. The method of claim 6 , in response to determining that the difference is less than the MV difference threshold, the first motion candidate is not added to the target HMVP table.

9. The difference is a first difference between a first MV of the first motion candidate and a second MV of the second motion candidate; a second difference between a first block vector (BV) of the first motion candidate and a second BV of the second motion candidate; a third difference between a first set of corner position MVs (CPMVs) of the first motion candidate and a second set of CPMVs of the second motion candidate; or a fourth difference between a portion of the first set of CPMVs and a portion of the second set of CPMVs; The method according to any one of claims 6 to 8, comprising one of the following:

10. Determining a difference between the first and second motion candidates includes: The method of claim 9 , comprising determining the difference from the first, second, third and fourth differences based on a motion type of the first and second motion candidates.

11. The movement type is: Inter motion candidate type, Intra block copy (IBC) motion candidate type, or Affine motion candidate type, The method of claim 10, comprising one of:

12. The method of claim 10 or 11, further comprising determining the MV difference threshold based on the motion type.

13. the coding mode associated with the target HMVP table; or the accuracy of the MVs of the first and second motion candidates; The method of any one of claims 6 to 12, further comprising determining the MV difference threshold based on at least one of:

14. The coding mode is Template Matching (TM) merge mode, Affine merge mode, Normal merge mode, Intra-Block Copy (IBC) merge mode, or Adaptive Decoder Side Motion Vector Refinement (ADMVR) mode, The method of claim 13, comprising one of:

15. The method of claim 13 or 14, wherein the precision of the MV indicates the fractional bits of the MV.

16. the at least one HMVP table includes an adaptive decoder-side motion vector refinement (ADMVR) HMVP table; Determining the at least one table includes:

16. The method of claim 1, further comprising adding a first motion candidate to the ADMVR HMVP table in response to a determination that the first motion candidate satisfies a decoder-side motion vector refinement (DMVR) condition.

17. The conditions of the DMVR are: the first motion candidate includes bi-predictive motion; a first reference picture of the first motion candidate is in the past with respect to a current picture, and a second reference picture of the first motion candidate is in the future with respect to the current picture; a first distance between the first reference picture and the current picture and a second distance between the second reference picture and the current picture are equal; the first and second reference pictures being short-term reference pictures; or the first and second reference pictures are non-scaled reference pictures; 17. The method of claim 16, comprising at least one of:

18. The method of claim 17 , wherein the first or second distance comprises a picture order count (POC) difference.

19. The method of any one of claims 1 to 18, wherein the at least one HMVP table comprises a target HMVP table corresponding to a target reference picture list.

20. The target HMVP table includes: determining, based on the bidirectional motion candidates, a unidirectional motion candidate corresponding to the target reference picture list; adding the unidirectional motion candidate to the target HMVP table; 20. The method of claim 19, wherein the

21. Determining the unidirectional motion candidates includes: determining a first MV of the bidirectional motion candidate as a second MV of the unidirectional motion candidate, the first MV being associated with the target reference picture list; 21. The method of claim 20, comprising: determining a first reference picture index of the bidirectional motion candidate as a second reference picture index of the unidirectional motion candidate, the first reference picture index being associated with the target reference picture list.

22. Determining the unidirectional motion candidates includes: adding a zero MV as a fourth MV of the unidirectional motion candidate in response to determining that a third MV of the bidirectional motion candidate is associated with a further reference picture list different from the target reference picture list; and and determining minus 1 as the reference picture index of the unidirectional motion candidate.

23. The target HMVP table includes: adding the first unidirectional motion candidate to the target HMVP table in response to determining that the first unidirectional motion candidate includes valid motion information corresponding to the target reference picture list; or in response to determining that a second unidirectional motion candidate includes valid motion information corresponding to a further reference picture list different from the target reference picture list, not adding the second unidirectional motion candidate to the target HMVP table; The method according to any one of claims 19 to 22, wherein the method is determined by at least one of the following:

24. The method of any one of claims 19 to 23, further comprising using the target HMVP table corresponding to the target reference picture list in a bilateral matching advanced motion vector prediction (AMVP) merge mode.

25. 1. A method for video processing, comprising: determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to a motion candidate list based on at least one comparison between an HMVP candidate and at least one candidate in a motion candidate list of the current video block for conversion between a current video block of a video and a bitstream of the video; and performing said transformation based on said determining.

26. The method of claim 25 , wherein the determination is made based on a coding mode associated with the HMVP candidate.

27. the at least one candidate includes a portion of candidates in the motion candidate list based on an ordering of the candidates in the motion candidate list; or The method of claim 25 or 26, wherein the at least one candidate comprises all candidates in the motion candidate list.

28. The method of any one of claims 25 to 27, wherein the at least one comparison comprises comparing the HMVP candidate with the at least one candidate based on at least one motion vector (MV) difference threshold.

29. The at least one comparison comprises: in response to determining that a first MV difference threshold of the at least one MV difference threshold is less than a second MV difference threshold, comparing the HMVP candidate with all candidates in the motion candidate list, wherein the first MV difference threshold is used to determine the HMVP table and the second MV difference threshold is used to determine the motion candidate list; or responsive to determining that the first MV difference threshold is greater than or equal to the second MV difference threshold, comparing the HMVP candidate to a portion of candidates in the motion candidate list based on an ordering of the candidates in the motion candidate list; 30. The method of claim 28, comprising at least one of:

30. 30. The method of claim 27 or 29, wherein the number of candidates in the portion of candidates is based on a total number of candidates in the motion candidate list before adding the HMVP candidate.

31. 31. The method of claim 28, wherein a first MV difference threshold for a first comparison of the at least one comparison is the same as a second MV difference threshold for a second comparison of the at least one comparison.

32. 31. The method of any one of claims 28 to 30, wherein a first MV difference threshold for a first comparison of the at least one comparison is different from a second MV difference threshold for a second comparison of the at least one comparison.

33. 33. The method of claim 32, wherein the first MV difference threshold is used to compare the HMVP candidate to a portion of candidates in the motion candidate list, and the second MV difference threshold is used to compare the HMVP candidate to the remaining candidates in the motion candidate list.

34. 34. The method of claim 32 or 33, wherein the first MV difference threshold is less than the second MV difference threshold.

35. The third MV difference threshold for comparison between two HMVP candidates is: a fourth MV difference threshold for comparing the HMVP candidate with a further motion candidate of a different motion type than the HMVP; or a fifth MV difference threshold for comparison between motion candidates of at least one motion type different from HMVP; The method according to any one of claims 28 to 34, which is different from at least one of

36. the third MV difference threshold is greater than at least one of the fourth or fifth MV difference thresholds; or 36. The method of claim 35, wherein the third MV difference threshold is less than at least one of the fourth or fifth MV difference thresholds.

37. a coding mode of the current video block; a block size of the current video block; a candidate type of a candidate in the motion candidate list; or MV accuracy, The method of any one of claims 28 to 38, further comprising determining the at least one MV difference threshold based on at least one of:

38. The coding mode is Template Matching (TM) merge mode, Affine merge mode, Normal merge mode, Intra-Block Copy (IBC) merge mode, or Adaptive Decoder Side Motion Vector Refinement (ADMVR) mode, 38. The method of claim 37, comprising at least one of:

39. 39. The method of claim 37 or 38, wherein the precision of the MV indicates the fractional bits of the MV.

40. The candidate types are: Neighborhood spatial candidate types, Adjacent temporal candidate types, Non-adjacent spatial candidate types, Non-adjacent temporal candidate types, HMVP candidate type, Pairwise candidate type, or Spatial-temporal motion vector prediction (STMVP) candidate types, The method according to any one of claims 37 to 39, comprising at least one of the following:

41. The method of any one of claims 28 to 38, wherein said at least one MV difference threshold is fixed.

42. The method of any one of claims 28 to 41, further comprising including said at least one MV difference threshold in said bitstream.

43. The method of any one of claims 25 to 42, wherein the at least one candidate is at least one location of the current video block.

44. The at least one location may be: The spatial neighborhood above, Left spatial neighbourhood, The upper right spatial neighborhood, the lower left spatial neighbour, or Top left spatial neighborhood, 44. The method of claim 43, comprising at least one of:

45. 1. A method for video processing, comprising: determining a first candidate list based on a maximum number of motion candidates in a first candidate list of a current video block of a video for conversion between the current video block and a bitstream of the video; determining a motion candidate list for the current video block based on the first candidate list, the motion candidate list including at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; performing the transformation based on the motion candidate list; 13. A method for video processing comprising:

46. 46. ​​The method of claim 45, wherein the candidates in the first candidate list are unique.

47. 47. The method of claim 45 or 46, wherein candidates in the first candidate list are pruned completely.

48. The method of any one of claims 45 to 47, further comprising reordering candidates in the first candidate list.

49. Determining the motion candidate list includes:

49. The method of claim 48, comprising adding a first number of candidates in the first candidate list to the motion candidate list based on an ordering of the first candidate list.

50. 50. The method of claim 49, wherein the first number is six.

51. 51. The method of claim 49 or 50, wherein an order of the first number of candidates is maintained while the first number of candidates are being added to the motion candidate list.

52. The motion candidate list includes: Regular merge candidate list, AMVP candidate list, or Affine merge candidate list, The method according to any one of claims 45 to 51, comprising one of the following:

53. The method of any one of claims 45 to 52, wherein the maximum number of motion candidates in the first candidate list is twenty.

54. 1. A method for video processing, comprising: determining at least one maximum number of candidates of at least one candidate type in a first candidate list of a current video block of a video for conversion between the current video block and a bitstream of the video; determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type; performing the conversion based on the first candidate list; 13. A method for video processing comprising:

55. The at least one maximum number is a first maximum number of history-based motion vector prediction (HMVP) candidates, or HMVP table size, 55. The method of claim 54, comprising one of:

56. 56. The method of claim 55, wherein the first maximum number or the HMVP table size is 25.

57. The method of any one of claims 54 to 56, wherein the at least one maximum number includes a second maximum number of history-based motion vector prediction (HMVP) candidates, the HMVP candidates being unique.

58. 58. The method of claim 57, wherein the second maximum number is fifteen.

59. The method of any one of claims 54 to 58, wherein the at least one maximum number includes a third maximum number of adjacent spatial candidates, the adjacent spatial candidates being unique.

60. 60. The method of claim 59, wherein the third maximum number is four.

61. The method of any one of claims 54 to 60, wherein the at least one maximum number comprises a fourth maximum number of pairwise average candidates, the pairwise average candidates being unique.

62. 62. The method of claim 61 , wherein the fourth maximum number is one.

63. A method according to any one of claims 54 to 62, wherein a fifth number of positions for pairwise candidates are reserved in the first candidate list.

64. 64. The method of claim 63, wherein the fifth number is one.

65. The method of any one of claims 54 to 64, wherein the maximum number of motion candidates in the first candidate list is twenty.

66. reordering at least one candidate in the first candidate list; determining a motion candidate list by adding a target number of candidates from the first candidate list to the motion candidate list based on the reordering; The method of any one of claims 54 to 65, further comprising:

67. The at least one candidate is all candidates in the first candidate list, or A portion of the candidates in the first candidate list; 67. The method of claim 66, comprising one of the following:

68. 68. The method of claim 66 or 67, wherein the target number is six.

69. 1. A method for video processing, comprising: determining a plurality of candidates for a current video block of a video for conversion between the current video block and a bitstream of the video, the plurality of candidates being at least one candidate type; reordering the plurality of candidates by performing an Adaptive Reordering of Merge Candidates (ARMC) process on the plurality of candidates based on the at least one candidate type; determining a motion candidate list based on the sorted plurality of candidates and the at least one candidate type; performing the transformation based on the motion candidate list; 13. A method for video processing comprising:

70. Determining the motion candidate list includes:

70. The method of claim 69, comprising adding a sorted first number of candidates of a first candidate type to the motion candidate list based on a cost of candidates of the first candidate type of the at least one candidate type.

71. the first candidate type, or a coding mode of the current video block; 71. The method of claim 70, further comprising determining the first number based on at least one of:

72. 72. The method of claim 70 or 71, wherein the first candidate type is a spatially adjacent candidate type and the first number is four.

73. 72. The method of claim 70 or 71, wherein the first candidate type is a history-based motion vector prediction (HMVP) candidate type and the first number is fifteen.

74. 72. The method of claim 70 or 71, wherein the first candidate type is a pairwise average candidate type and the first number is one.

75. Sorting the plurality of candidates includes: A method according to any one of claims 69 to 74, comprising sorting together the candidates of a set of candidate types.

76. The set of candidate types includes: Neighborhood spatial candidate types, History-based motion vector prediction (HMVP) candidate type, or Pairwise average candidate type, 76. The method of claim 75, comprising at least one of:

77. Determining the motion candidate list includes:

77. The method of claim 75 or 76, comprising adding a sorted second number of candidates of the set of candidate types to the motion candidate list based on costs of candidates of the set of candidate types.

78. the set of candidate types; or a coding mode of the current video block; 78. The method of claim 77, further comprising determining the second number based on at least one of:

79. 79. The method of claim 77 or 78, wherein the second number is six.

80. Determining the motion candidate list includes: determining a third number of history-based motion vector prediction (HMVP) candidates from the reordered candidates; and reordering a group of candidates, the group of candidates including at least one of a set of adjacent spatial candidates or a set of pairwise candidates and the third number of HMVP candidates; and adding the reordered fourth number of candidate groups to the motion candidate list.

81. Determining the motion candidate list includes: determining a fifth number of history-based motion vector prediction (HMVP) candidates from a HMVP table based on a first motion vector difference threshold; determining a sixth number of HMVP candidates from the fifth number of HMVP candidates by permuting the fifth number of HMVP candidates; determining a motion candidate group based on a second MV difference threshold, the motion candidate group including at least one of the sixth number of HMVP candidates, a set of adjacent spatial candidates, or a set of pair-wise candidates; The method of any one of claims 69 to 79, comprising determining a seventh number of motion candidates from said group of motion candidates by ordering said group of motion candidates.

82. 82. The method of claim 81, wherein the first and second MV difference thresholds are the same.

83. 83. The method of claim 81 or 82, further comprising determining the first MV difference threshold based on a block size of the current video block.

84. The block size is the block width of the current video block; the block height of the current video block, or the product of the block width and the block height; 84. The method of claim 83, comprising at least one of:

85. the coding mode of the current video block; the block size of the current video block, or MV accuracy, 83. The method of claim 81 or 82, further comprising determining the first MV difference threshold based on at least one of:

86. The coding mode is Template Matching (TM) merge mode, Affine merge mode, Normal merge mode, Intra-Block Copy (IBC) merge mode, or Adaptive Decoder Side Motion Vector Refinement (ADMVR) mode, 86. The method of claim 85, comprising one of:

87. 87. The method of claim 85 or 86, wherein the precision of the MV indicates the fractional bits of the MV.

88. 88. The method of any one of claims 69 to 87, wherein if the current video block candidate is permuted multiple times, permutation criteria of the candidate is reused for the multiple permutations.

89. 90. The method of claim 88, wherein the sorting criteria comprises a template matching cost of the candidates.

90. 1. A method for video processing, comprising: determining an intra block copy (IBC) advanced motion vector prediction (AMVP) candidate list for conversion between a current video block of a video and a bitstream of the video without reordering candidates in the IBC AMVP candidate list of the current video block; and performing the conversion based on the IBC AMVP candidate list.

91. Determining the IBC AMVP candidate list includes: determining an IBC merge candidate list for the current video block; determining the IBC AMVP candidate list based on the IBC merge candidate list without reordering candidates in the IBC merge candidate list.

92. 1. A method for video processing, comprising: determining a first motion candidate list for a current video block of a video corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block for conversion between a current video block of a video and a bitstream of the video; performing the transformation based on the first and second motion candidate lists; A method for video processing, wherein the determination of the first motion candidate list is different from the determination of the second motion candidate list.

93. 93. The method of claim 92, wherein a first motion vector (MV) difference threshold for the first motion candidate list is different from a second MV difference threshold for the second motion candidate list.

94. 94. The method of claim 92 or 93, wherein a first motion vector (MV) difference threshold for a first motion candidate type is different from a second MV difference threshold for a second motion candidate type.

95. A method according to any one of claims 92 to 94, wherein a first motion vector (MV) difference threshold for a first block size is different to a second MV difference threshold for a second block size.

96. A method according to any one of claims 92 to 94, wherein a first motion vector (MV) difference threshold for a first MV having a first fractional bit is different from a second MV difference threshold for a second MV having a second fractional bit.

97. The method of any one of claims 1 to 96, wherein the converting comprises encoding the current video block into the bitstream.

98. The method of any one of claims 1 to 96, wherein the converting comprises decoding the current video block from the bitstream.

99. 1. An apparatus for processing video data comprising a processor and a non-transitory memory having instructions thereon, Apparatus for processing video data, wherein the instructions, when executed by the processor, cause the processor to perform a method according to any preceding claim.

100. A non-transitory computer readable storage medium storing instructions that cause a processor to perform the method of any one of claims 1 to 98.

101. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: a motion vector (MV) difference threshold for comparing at least two MVs of at least two history-based motion vector prediction (HMVP) candidates; a coding mode of a current video block of the video; or a reference picture list index associated with the current video block; determining at least one HMVP table for the current video block based on at least one of: generating the bitstream based on the at least one HMVP table; A non-transitory computer-readable recording medium comprising:

102. 1. A method for storing a video bitstream, comprising: a motion vector (MV) difference threshold for comparing at least two MVs of at least two history-based motion vector prediction (HMVP) candidates; a coding mode of a current video block of the video; or a reference picture list index associated with the current video block; determining at least one HMVP table for the current video block based on at least one of: generating the bitstream based on the at least one HMVP table; and storing the bitstream on a non-transitory computer-readable recording medium.

103. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to the motion candidate list based on at least one comparison between the HMVP candidate and at least one candidate in a motion candidate list for a current video block of the video; and generating the bitstream based on the determination.

104. 1. A method for storing a video bitstream, comprising: determining whether to add a history-based motion vector prediction (HMVP) candidate from an HMVP table to the motion candidate list based on at least one comparison between the HMVP candidate and at least one candidate in a motion candidate list for a current video block of the video; generating the bitstream based on the determination; and and storing the bitstream on a non-transitory computer-readable recording medium.

105. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining a first candidate list based on a maximum number of motion candidates in a first candidate list for a current video block of the video; determining a motion candidate list for the current video block based on the first candidate list, the motion candidate list including at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; and generating the bitstream based on the motion candidate list.

106. 1. A method for storing a video bitstream, comprising: determining a first candidate list based on a maximum number of motion candidates in a first candidate list for a current video block of the video; determining a motion candidate list for the current video block based on the first candidate list, the motion candidate list including at least one of an intra block copy (IBC) merge candidate list or an IBC advanced motion vector prediction (AMVP) candidate list; generating the bitstream based on the motion candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

107. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining at least one maximum number of candidates of at least one candidate type in a first candidate list for a current video block of the video; determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type; and generating the bitstream based on the first candidate list.

108. 1. A method for storing a video bitstream, comprising: determining at least one maximum number of candidates of at least one candidate type in a first candidate list for a current video block of the video; determining the first candidate list based on the at least one maximum number of candidates of the at least one candidate type; generating the bitstream based on the first candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

109. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining a plurality of candidates for a current video block of the video, the plurality of candidates being at least one candidate type; reordering the plurality of candidates by performing an Adaptive Reordering of Merge Candidates (ARMC) process on the plurality of candidates based on the at least one candidate type; determining a motion candidate list based on the sorted plurality of candidates and the at least one candidate type; and generating the bitstream based on the motion candidate list.

110. 1. A method for storing a video bitstream, comprising: determining a plurality of candidates for a current video block of the video, the plurality of candidates being at least one candidate type; reordering the plurality of candidates by performing an Adaptive Reordering of Merge Candidates (ARMC) process on the plurality of candidates based on the at least one candidate type; determining a motion candidate list based on the sorted plurality of candidates and the at least one candidate type; generating the bitstream based on the motion candidate list; storing the bitstream on a non-transitory computer readable recording medium; A method for storing a bitstream of a video, comprising:

111. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining an intra block copy (IBC) advanced motion vector prediction (AMVP) candidate list without reordering candidates in an IBC AMVP candidate list for a current video block of the video; and generating the bitstream based on the IBC AMVP candidate list.

112. 1. A method for storing a video bitstream, comprising: determining an intra block copy (IBC) advanced motion vector prediction (AMVP) candidate list without reordering candidates in an IBC AMVP candidate list for a current video block of the video; generating the bitstream based on the IBC AMVP candidate list; and storing the bitstream on a non-transitory computer-readable recording medium.

113. 1. A non-transitory computer-readable recording medium storing a video bitstream generated by a method executed by a video processing device, the method comprising: determining a first motion candidate list for a current video block of the video corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block; generating the bitstream based on the first and second motion candidate lists; The determination of the first motion candidate list is different from the determination of the second motion candidate list.

114. 1. A method for storing a video bitstream, comprising: determining a first motion candidate list for a current video block of the video corresponding to a first coding mode and a second motion candidate list for the current video block corresponding to a second coding mode of the current video block; generating the bitstream based on the first and second motion candidate lists; storing the bitstream on a non-transitory computer-readable recording medium; 11. A method of storing a video bitstream, wherein the decisions of the first motion candidate list are different from the decisions of the second motion candidate list.

Images