Method and device for video processing and medium

Abstract

The embodiment of the invention provides a scheme for video processing. A method for video processing is presented. The method comprises: during a transition between a target block of video and a bitstream of the target block, deriving a motion vector predictor for the target block from a parameter table storing a set of affine parameters from at least one previous coded block, the target block being a non-affine coded block; and performing the conversion based on the motion vector predictor.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to video coding techniques, and more particularly, to signaling of information related to combined inter-intra prediction (CIIP) enhancement mode. Background Art

[0002] Nowadays, digital video capabilities are being applied to all aspects of people's lives. Various video compression technologies, such as MPEG-2, MPEG-4, ITU-TH.263, ITU-TH.264 / MPEG-4 Part 10 Advanced Video Codec (AVC), ITU-TH.265 High Efficiency Video Codec (HEVC) standard, and Versatile Video Codec (VVC) standard have been proposed for video encoding / decoding. However, the encoding and decoding efficiency of traditional video encoding and decoding technologies is generally low, which is not ideal. Summary of the invention

[0003] The 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 comprises: during conversion between a target block of a video and a bitstream of the target block, deriving a motion vector predictor for the target block from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; and performing conversion based on the motion vector predictor. Compared with conventional solutions, the proposed method can advantageously improve coding efficiency and performance.

[0005] In a second aspect, another method for video processing is proposed. The method comprises: during conversion between a target block of a video and a bitstream of the target block, determining at least one motion vector predictor derived using an affine model for the target block; inserting the motion vector predictor into at least one position in a candidate list; and performing the conversion based on the candidate list. Compared with conventional solutions, the proposed method can advantageously improve codec efficiency and performance.

[0006] In a third aspect, a device for processing video data is provided. The video data processing device comprises a processor and a non-volatile memory having instructions thereon. The instructions, when executed by the processor, cause the processor to perform the method according to the first aspect.

[0007] In a fourth aspect, an apparatus for processing video data is presented. A non-transitory computer readable storage medium stores instructions for causing a processor to perform the method according to the second aspect.

[0008] In a fifth aspect, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a video processing device. The method includes: deriving a motion vector predictor for a target block of the video from a parameter table, the parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; and generating a bitstream of the target block based on the motion vector predictor.

[0009] In a sixth aspect, another method for video processing is provided. A motion vector predictor for a target block of the video is derived from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; a bit stream of the target block is generated based on the motion vector predictor; and the bit stream is stored in a non-transitory computer-readable recording medium.

[0010] In a seventh aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a video processing device. The method includes: determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; and generating a bitstream of the target block based on the candidate list.

[0011] In an eighth aspect, another method for video processing is provided. The method includes determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; generating a bitstream for the target block based on the candidate list; and storing the bitstream in a non-transitory computer-readable recording medium.

[0012] This summary is provided to introduce some concepts in a simplified form, which are further described in the following 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 DESCRIPTION OF THE DRAWINGS

[0013] The above and other purposes, features and advantages of the embodiments of the present disclosure will become more apparent through the following detailed description and with reference to the accompanying drawings. In the embodiments of the present disclosure, the same reference numerals generally refer to the same components.

[0014] Figure 1 A block diagram showing an example video encoding and decoding system according to some embodiments of the present disclosure is shown;

[0015] Figure 2 A block diagram illustrating a first example video encoder according to some embodiments of the present disclosure is shown;

[0016] Figure 3 A block diagram of an example video decoder according to some embodiments of the present disclosure is shown;

[0017] Figure 4 Sub-block based prediction is shown;

[0018] Figure 5a-5b shows a simplified affine motion model where Figure 5a shows a 4-parameter affine model, Figure 5b A 6-parameter affine model is shown;

[0019] Figure 6 The affine MVF of each sub-block is shown;

[0020] Figure 7a-7b The candidates for AF_MERGE are shown;

[0021] Figure 8 Candidate positions of the affine merge pattern are shown;

[0022] Fig. 9 Candidate positions of the affine merge pattern are shown;

[0023] Figure 10a-10b A diagram showing the partitioning of a CU into two triangular prediction units (two partitioning modes) is shown, where Fig.10a shows a 135 degree split type, while Fig.10b A 45 degree split pattern is shown;

[0024] Fig.11 is a graph representing the locations of adjacent blocks;

[0025] Fig.12 An example of a CU to which a first set of weighting factors is applied is shown;

[0026] Fig.13 is a diagram showing an example of motion vector storage;

[0027] Fig.14 shows a decoding flow chart using the proposed HMVP method;

[0028] Fig.15 An example of updating a table in the proposed HMVP method is shown;

[0029] Fig.16 The UMVE search process is shown;

[0030] Fig.17 UMVE search points are shown;

[0031] Fig.18 A distance index and distance offset map are shown;

[0032] Fig.19 An example of deriving a CPMV from the MVs of neighboring blocks and a set of parameters stored in a buffer is shown;

[0033] Fig. 20 is a diagram showing examples of possible locations of co-location blocks;

[0034] Fig.21 is a graph representing the positions within a 4×4 basic block;

[0035] Fig. 22 It is shown that the sub-blocks at the right and bottom borders are shaded;

[0036] Figures 23a-23d Possible locations for deriving MVs stored in sub-blocks at the right and bottom boundaries are shown;

[0037] Fig.24 Possible locations for deriving MV predictions are shown;

[0038] Fig.25 is a diagram showing an example of HPAC;

[0039] Fig.26 A flowchart of a method according to an exemplary embodiment of the present disclosure is shown;

[0040] Fig. 27 A flowchart showing a method according to an example embodiment of the present disclosure; and

[0041] Fig.28 shows a block diagram of a computing device in which various embodiments of the present disclosure may be implemented;

[0042] Throughout the drawings, same or similar reference numbers generally refer to same or similar elements. DETAILED DESCRIPTION

[0043] The principle of the present invention is now described in conjunction with some embodiments. It should be understood that these embodiments are described only for illustrative purposes to help those skilled in the art understand and implement the present invention, and do not constitute any limitation to the scope of the present invention. The disclosure described herein can be implemented in various ways except for the way described below.

[0044] In the following description and claims, unless defined otherwise, 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.

[0045] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment include the particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example, it is considered to be within the knowledge of those skilled in the art to affect embodiments related to such features, structures, or characteristics, whether or not explicitly described.

[0046] It should be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as 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.

[0047] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an", and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "comprise", "include", "have", "have", "include" and / or "include", when used herein, 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. Example Environment

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

[0049] Video source 112 may include a source 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.

[0050] 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 related data. The coded representation of the picture is a coded representation of the picture. The associated data may include sequence parameter sets, picture parameter sets, and other grammatical structures. The I / O interface 116 may include a modulator / demodulator and / or a transmitter. The encoded video data may be directly transmitted to the destination device 120 via the network 130A via the I / O interface 116. The encoded video data may also be stored on a storage medium / server 130B for access by the destination device 120.

[0051] 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, with destination device 120 configured to interface with an external display device.

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

[0053] Figure 2 is a block diagram showing an example of a video encoder 200 according to some embodiments of the present disclosure, which may be Figure 1 An example of a video encoder 114 in the system 100 is shown.

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

[0055] In some embodiments, the video encoder 200 may include a partition unit 201, a prediction unit 202, the prediction unit 202 may include a mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205 and an intra-frame prediction unit 206, a residual generation unit 207, a transform unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transform unit 211, a reconstruction unit 212, a buffer 213 and an entropy coding unit 214.

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

[0057] Furthermore, although some components, such as the motion estimation unit 204 and the motion compensation unit 205, may be integrated, for the purpose of explanation, the components are described in detail in the following. Figure 2 are represented individually in the examples.

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

[0059] The mode selection unit 203 may select one of the coding modes, intra or inter, for example based on the error result, and provide the resulting intra-coded or inter-coded block to the residual. The generation unit 207 generates residual block data and transmits it to the reconstruction unit 212 to reconstruct the coded block for use as a reference image. In some examples, the mode selection unit 203 may select a combination of intra and inter prediction (CIIP) modes, where the prediction is based on an inter prediction signal and an intra prediction signal. In the case of inter prediction, the mode selection unit 203 may also select the resolution of the motion vector of the block (e.g., sub-pixel or integer pixel precision).

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

[0061] The motion estimation unit 204 and the motion compensation unit 205 may perform different operations on the current video block, for example, depending 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 consisting of macroblocks, all of which are based on macroblocks within the same picture. Furthermore, as used herein, in some aspects, a "P slice" and a "B slice" may refer to a portion of a picture consisting of macroblocks that are not dependent on macroblocks in the same picture.

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

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

[0064] In some examples, motion estimation unit 204 may output a complete set of motion information for use in a decoding process by a decoder. Indeed, in some embodiments, motion estimation unit 204 may signal motion information for a current video block with reference to motion information of another video block. For example, motion estimation unit 204 may determine that motion information for a current video block is sufficiently similar to motion information for a neighboring video block.

[0065] 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.

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

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

[0068] The intra prediction unit 206 may perform intra prediction on the current video block. When the intra prediction unit 206 performs intra prediction on the current video block, the intra prediction unit 206 may generate prediction data for the current video block based on decoded samples of other video blocks in the same image. The prediction data for the current video block may include a prediction video block and various syntax elements.

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

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

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

[0072] 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.Current Video Block.

[0073] Inverse quantization unit 210 and inverse transform unit 211 may apply inverse quantization and inverse transform to the transform coefficient video block, respectively, 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 prediction video blocks generated by prediction unit 202 to generate a reconstructed video block associated with the current video block for storage in buffer 213.

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

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

[0076] Figure 3 is a block diagram showing an example of a video decoder 300 according to some embodiments of the present disclosure, which may be Figure 1 An example of a video decoder 124 in the system 100 is shown.

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

[0078] exist Figure 3 In the example of , the 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. In some examples, the video decoder 300 can perform a decoding process that is generally opposite to the encoding process described with respect to the video encoder 200.

[0079] The entropy decoding unit 301 can obtain an encoded bitstream. The encoded bitstream may include entropy encoding and decoding of video data (e.g., an encoded block of video data). The entropy decoding unit 301 can decode the entropy decoded video data, and the motion compensation unit 302 can determine motion information, including motion vectors, motion vector precision, reference image list indexes, and other motion information, based on the entropy decoded video data. The motion compensation unit 302 can determine such information, for example, by performing AMVP and merge mode. Using AMVP, it includes deriving several most likely candidates based on the data and reference pictures of adjacent PBs. The motion information typically includes horizontal and vertical motion vector displacement values, one or two reference image indexes, and, in the case of a prediction area in a B slice, an identification of which reference image list is associated with each index. As used herein, in some aspects, "merge mode" may refer to deriving motion information from spatially or temporally adjacent blocks.

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

[0081] The motion compensation unit 302 may calculate interpolation of sub-integer pixels of a reference block using an interpolation filter used by the video encoder 200 during encoding of the video block. The motion compensation unit 302 may determine the interpolation filter used by the video encoder 200 according to received syntax information and use the interpolation filter to generate a prediction block.

[0082] The motion compensation unit 302 may use at least part of the syntax information to determine the size of the blocks used to encode the frames and / or slices of the coded video sequence, partition information describing how each macroblock of the image is encoded. Partitions of the coded video sequence, a mode indicating how each partition is encoded, one or more reference frames (and a list of reference frames) 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 of other slices of the same picture in terms of entropy coding and decoding, signal prediction, and residual signal reconstruction. A slice may be an entire picture or a region of a picture.

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

[0084] The reconstruction unit 306 may obtain a decoded block, for example, by summing the residual block with the corresponding prediction block generated by the motion compensation unit 302 or the intra prediction unit 303. If necessary, a deblocking filter may also be applied to filter the decoded block to remove block artifacts. The decoded video block is then stored in a buffer 307, which provides reference blocks for subsequent motion compensation / intra prediction and also generates a decoded video for presentation on a display device.

[0085] Some exemplary embodiments of the present disclosure will be described in detail below. It should be understood that the section titles used in this document are for ease of understanding and do not limit the embodiments disclosed in the section to only that section. In addition, although certain embodiments are described with reference to general video codecs or other specific video codecs, the disclosed technology is also applicable to other video codec technologies. In addition, although some embodiments describe the video codec steps in detail, it should be understood that the corresponding decoding steps of the undo codec will be implemented by the decoder. In addition, the term video processing covers video codecs or compression, video decoding or decompression, and video transcoding, in which video pixels are represented from one compression format to another compression format or at different compression bit rates. 1. Summary of the invention The present disclosure relates to video / image coding technology. Specifically, it is related to affine prediction in video / image coding. It can be applied to existing video coding standards, such as HEVC and VVC. It may also be applicable to future video / image coding standards or video / image codecs. 2. Background technology Video codec standards have been developed mainly through the development of the well-known ITU-T and ISO / IEC standards. ITU-T produced H.261 and H.263, ISO / IEC produced MPEG-1 and MPEG-4 Visual (Visual), and the two organizations jointly produced H.264 / MPEG-2 Video and H.264 / MMPEG-4 Advanced Video Codec (AVC) and H.265 / HEVC (H.265 / HEVC, https: / / www.itu.int / rec / T-REC-H.265) standards. Since H.262, video codec standards are based on a hybrid video codec structure that utilizes temporal prediction plus transform coding. In order to explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many of the new methods and put them into a reference software called Joint Exploration Model (JEM) (JEM-7.0: https: / / jvet.hhi.fraunhofer.de / svn / svn_HMJE-MSoftware / tags / HM-16.6-JEM-7.0) (VTM-2.0.1: https: / / vcgit.hhi.fra-nhofer.de / jvet / VVCSoftware_VTM / tags / VTM-2.0.1.) In April 2018, the Joint Video Experts Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) was created to work on the VVC standard with the goal of a 50% bitrate reduction compared to HEVC. The latest version of the VVC draft, Generic Video Codec (Draft 2), can be found at: http: / / phenix.it-sudparis.eu / jvet / doc_end_user / documents / 11_Ljubljana / wg11 / JVET-K1001-v7.zip The latest reference software for VVC, called VTM, can be found at: https: / / vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM / tags / VTM-2.1 Sub-block based prediction was first introduced to the video coding standard by HEVC Annex I (3D-HEVC) (H.265 / HEVC, https: / / www.itu.int / rec / T-REC-H.265). For sub-block based prediction, a block such as a coding unit (CU) or a prediction unit (PU) is divided into several non-overlapping sub-blocks. Different sub-blocks can be assigned different motion information, such as reference indexes or motion vectors (MVs), and motion compensation (MC) is performed separately for each sub-block. Figure 4 The concept of sub-block based prediction is demonstrated. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods (J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, J. Boyce, "Algorithmic Description of the Joint Exploration Test Model 7 (JEM7)", JVET-G1001, August 2017) and put them into a new framework called Joint Exploration Model (JEM) (JEM-7.0: https: / / jvet.hhi.fraunhofer.de / svn / svn_HMJE-MSoftware / tags / HM-16.6-JEM-7.0). In JEM, sub-block based prediction is adopted by various codec tools, such as affine prediction, alternative temporal motion vector prediction (ATMVP), spatiotemporal motion vector prediction (STMVP), bidirectional optical flow (BIO), and frame rate up-conversion (FRUC). Affine prediction is also used in VVC. 2.1 Affine Prediction In HEVC, only the translation motion model is applied for motion compensation prediction (MCP). In the real world, there are many kinds of motion, such as zooming in / out, rotation, perspective motion, and other irregular motions. In VVC, a simplified affine transformation motion compensation prediction is applied. Figures 5a to 5b As shown, the affine motion field of a block is described by two (in a 4-parameter affine model) or three (in a 6-parameter affine model) control point motion vectors. The motion vector field (MVF) of a block is described by the following equations: the 4-parameter affine model (where the 4 parameters are defined as variables a, b, e, f) is described in equation (1) and the 6-parameter affine model (where the 4 parameters are defined as variables a, b, c, d, e and f) is described in equation (2): Where (mvh0, mvh0) is the motion vector of the upper left control point, (mvh1, mvh1) is the motion vector of the upper right control point and (mvh2, mvh2) is the motion vector of the lower left control point. These three motion vectors are called control point motion vectors (CPMV), and (x, y) represents the coordinates of the representative point relative to the top pass sample in the current block. The CP motion vector can be sent by signal (such as in affine AMVP mode) or dynamically derived (such as in affine merge mode). w and h are the width and height of the current block. In practice, division is implemented by right shift and rounding operations. In VTM, the representative point is defined as the center position of the sub-block. For example, when the coordinates of the upper left corner of the sub-block relative to the top pass sample in the current block are (xs, ys), the coordinates of the representative point are defined as (xs+2, ys+2). In the pointless design, (1) and (2) are implemented as For the 4-parameter affine model shown in (1): For the 6-parameter affine model shown in (2): at last, Off=1<<(S-1) (7) Where S represents the calculation precision. For example, in VVC, S = 7. In VVC, the MV of the sub-block for the top channel sample at (xs, ys) in MC is calculated by (6), where x = xs + 2 and y = ys + 2. In order to derive the motion vector of each 4×4 sub-block, the motion vector of the center sample of each sub-block is calculated according to equation (1), as follows: Figure 6 As shown in (1) or (2), and rounded to 1 / 16 fractional precision. A motion compensated interpolation filter is then applied to generate a prediction for each sub-block with a derived motion vector. The affine model can be inherited from spatially adjacent affine coded blocks, such as left, top, top right, bottom left and top left adjacent blocks, as shown in Figure 7(a). For example, if the adjacent bottom left block A in Figure 7(a) is coded and decoded in affine mode, as shown in A0 in Figure 7(b), the control point (CP) motion vectors mv0N, mv1N and mv2N of the top left, top right and bottom left corners of the adjacent CU / PU containing block A are obtained. And the motion vectors mv0C, mv1C, mv2C of the top left / top right / bottom left corners of the current CU / PU are calculated based on mv0N, mv1N, mv2N (only for 6-parameter affine model). It should be noted that in VTM-2.0, if the current block is affine coded and decoded, the sub-block (e.g., 4×4 block in VTM) LT stores mv0 and RT stores mv1. If the current block is encoded and decoded using a 6-parameter affine model, LB stores mv2; otherwise (using a 4-parameter affine model), LB stores mv2'. The other sub-blocks store the MV for MC. It should be noted that when the CU is encoded and decoded in affine merge mode, that is, in affine merge mode, it obtains the first block encoded and decoded in affine mode from the valid neighboring reconstructed blocks. The selection order of candidate blocks is from left, top, top right, bottom left to top left, as shown in Figure 7(a). The CP MVs mv0C, mv1C, and mv2C derived from the current block can be used as CP MVs in the affine merge mode. Or they can be used as MVPs for the affine inter mode in VVC. It should be noted that for the merge mode, if the current block is an affine mode that has been encoded and decoded, after deriving the CP MV of the current block, the current block can be further divided into multiple sub-blocks, and each block will derive information whose motion is based on the CP MV derived from the current block. 2.2 Separate list of affine candidates for AF_MERGE mode. Different from VTM where only one affine space neighboring block can be used to derive the affine motion of a block, in JVET-K0186, it is proposed to build a separate list of affine candidates for AF_MERGE mode. 1) Insert the inherited affine candidate into the candidate list Inherited affine candidates means that the candidates are derived from the valid neighbor reconstructed blocks in affine mode after encoding and decoding. like Figure 8 As shown, the scanning order of candidate blocks is A1, B1, B0, A0 and B2. When a block is selected (for example, A1), a two-step process is applied: a) First, use the three corner point motion vectors of the CU covering the block to derive two / three control points of the current block; b) The sub-block motion of each sub-block within the current block is derived based on the control points of the current block. 2) Insert the constructed affine candidate If the number of candidates in the affine merge candidate list is less than MaxNumAffineCand, the constructed affine candidate is inserted into the candidate list. Constructing affine candidates means constructing candidates by combining the neighboring motion information of each control point. The motion information of the control point is first obtained from Figure 8 The kth control point is derived from the specified spatial and temporal neighbors shown in Figure 1. CPk (k = 1, 2, 3, 4) represents the kth control point. A0, A1, A2, B0, B1, B2 and B3 are the spatial positions used to predict CPk (k = 1, 2, 3); T is the temporal position for predicting CP4. The coordinates of CP1, CP2, CP3 and CP4 are (0, 0), (W, 0), (H, 0) and (W, H), respectively, where W and H are the width and height of the current block. The motion information of each control point is obtained in the following order of priority: - For CP1, the priority of checking is B2->B3->A2. If available, use B2. Otherwise, if B2 is available, use B3. If neither B2 nor B3 is available, use A2. If none of the three candidates are available, the motion information of CP1 cannot be obtained. -For CP2, check priority is B1->B0; -For CP3, check priority is A1->A0; -For CP4, use T. Secondly, the motion model is constructed using the combination of control points. The motion vectors of three control points are required to calculate the transformation parameters in the six-parameter affine model. The three control points can be selected from one of the following four combinations ({CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4}). For example, a six-parameter affine motion model is constructed using CP1, CP2, and CP3 control points, denoted as Affine(CP1, CP2, CP3). The motion vectors of two control points are needed to calculate the transformation parameters in the four-parameter affine model. The two control points can be selected from one of the following six combinations ({CP1, CP4}, {CP2, CP3}, {CP1, CP2}, {CP2, CP4}, {CP1, CP3}, {CP3, CP4}). For example, the 4-parameter affine motion model is constructed using the CP1 and CP2 control points, denoted as Affine(CP1, CP2). The combinations of constructed affine candidates are inserted into the candidate list in the following order: {CP1,CP2,CP3},{CP1,CP2,CP4},{CP1,CP3,CP4},{CP2,CP3,CP4},{CP1,CP2},{CP1,CP3},{CP2,CP3},{CP1,CP4},{CP2,CP4},{CP3,CP4}. 3) Insert zero motion vector If the number of candidates in the affine merge candidate list is less than MaxNumAffineCand, zero motion vectors are inserted into the candidate list until the list is full. 2.3 Affine Merge Candidate List 2.3.1 Affine Merge Mode In the affine merge mode of VTM-2.0.1, only the first available affine neighbor can be used to derive the motion information of the affine merge mode. In JVET-L0366, a candidate list of the affine merge mode is constructed by searching for valid affine neighbors and combining the neighbor motion information of each control point. The steps to construct the affine merge candidate list are as follows: 1) Insert inherited affine candidates Inheriting affine candidates means that the candidates are derived from the affine motion models of their valid neighbor affine encoded blocks. In public libraries, such as Fig. 9 As shown, the scanning order of candidate positions is: A1, B1, B0, A0 and B2. After the candidates are derived, a full pruning process is performed to check if the same candidate has been inserted into the list. If the same candidate exists, the derived candidate is discarded. 2) Insert the constructed affine candidate If the number of candidates in the affine merge candidate list is less than MaxNumAffineCand (set to 5 in this contribution), the constructed affine candidate is inserted into the candidate list. Constructing affine candidates means constructing candidates by combining neighboring motion information of each control point. The motion information of the control point is first obtained from Fig. 9 The specified spatial neighbors and temporal neighbors are derived from the shown. CPk (k = 1, 2, 3, 4) represents the kth control point. A0, A1, A2, B0, B1, B2, B3 are the predicted spatial positions of CPk (k = 1, 2, 3); T is the predicted temporal position of CP4. The coordinates of CP1, CP2, CP3 and CP4 are (0,0), (W,0), (H,0) and (W,H), respectively, where W and H are the width and height of the current block. The motion information of each control point is obtained in the following order of priority: For CP1, the priority of checking is B2->B3->A2. If B2 is available, use B2. Otherwise, if B2 is available, use B3. If neither B2 nor B3 is available, use A2. If all three candidates are unavailable, the motion information of CP1 cannot be obtained. For CP2, the checking priority is B1->B0. For CP3, the checking priority is A1->A0. For CP4, use T. Second, combinations of control points are used to construct affine merge candidates. Constructing the 6-parameter affine candidate points requires the motion information of three control points. The three control points can be selected from one of the following four combinations ({CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4}). The combination {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4} will be converted into a 6-parameter motion model represented by the top left, top right and bottom left control points. Constructing 4-parameter affine candidate points requires motion information of two control points. The two control points can be selected from one of the following six combinations ({CP1,CP4}, {CP2,CP3}, {CP1,CP2}, {CP2,CP4}, {CP1,CP3}, {CP3,CP4}). The combination {CP1,CP4}, {CP2,CP3}, {CP2,CP4}, {CP1,CP3}, {CP3,CP4} will be converted into a 4-parameter motion model point represented by the upper left and upper right controls. The combinations of constructed affine candidates are inserted into the candidate list in the following order: {CP1,CP2,CP3},{CP1,CP2,CP4},{CP1,CP3,CP4},{CP2,CP3,CP4},{CP1,CP2},{CP1,CP3},{CP2,CP3},{CP1,CP4},{CP2,CP4},{CP3,CP4}. For a combined reference list X (X is 0 or 1), the reference index with the highest usage rate among the control points is selected as the reference index of list X, and the motion vector points of the difference reference picture are scaled. After the candidates are derived, a full pruning process is performed to check if the same candidate has been inserted into the list. If the same candidate exists, the derived candidate is discarded. 3) Fill with zero motion vectors If the number of candidates in the affine merge candidate list is less than 5, zero motion vectors with zero reference index are inserted into the candidate list until the list is full. 2.3.2 Affine Merge Mode It proposes the following simplifications to the affine merge mode in JVET-L0366: 1) The pruning process of inherited affine candidates is simplified by comparing codec units covering neighboring positions instead of comparing affine candidates derived in VTM-2.0.1. At most 2 inherited affine candidates are inserted into the affine merge list. The pruning process of constructing affine candidates is completely removed. 2) The MV scaling operation in the constructed affine candidate is removed. If the reference index of the control point is different, the constructed motion model is discarded. 3) The number of constructed affine candidates is reduced from 10 to 6. 4) It is also proposed to put other merge candidates with sub-block predictions such as ATMVP into the affine merge candidate list. In this case, the affine merge candidate list can be renamed to some other names, such as sub-block merge candidate list. 2.4 Control point MV offset in affine merge mode Generate new affine merge candidates based on the CPMV offset of the first affine merge candidate. If the first affine merge candidate has the 4-parameter affine model enabled, the 2 CPMVs of each new affine merge candidate are derived by offsetting the 2 CPMVs of the first affine merge candidate; otherwise (the 6-parameter affine model is enabled), the 3 CPMVs of each new affine merge candidate are derived by offsetting the 3 CPMVs of the first affine merge candidate. In unidirectional prediction, the CPMV offset is applied to the CPMV of the first candidate. In common prediction where list 0 and list 1 are in the same direction, the CPMV offset is applied to the first candidate as follows: MV 新(L0)，i =MV 旧(L0) +MV 偏移(i) MV 新(L1)，i =MV 旧(L1) +MV 偏移(i) . In the struct predictions for list 0 and list 1 in opposite directions, the CPMV offset is applied to the first candidate as follows: MV 新(L0)，i =MV 旧(L0) +MV 偏移(i) MV 新(L1)，i =MV 旧(L1) -MV 偏移(i) . In this contribution, different offset directions with different offset magnitudes are used to generate new affine merge candidates. Two implementations are tested: (1) Generate 16 new affine merge candidates with 8 different offset directions and 2 different offset magnitudes, as shown in the following offset set: Offset settings = {(4,0),(0,4),(-4,0),(0,-4),(-4,-4),(4,-4),(4,4),(-4,4),(8,0),(0,8),(-8,0),(0,-8),(-8,-8),(8,-8),(8,8),(-8,8)}. For this design, the affine merge list increases to 20. The number of potential affine merge candidates is 31 in total. (2) Generate 4 new affine merge candidates with 4 different offset directions and 1 offset magnitude, as shown in the following offset set: Offset set = {(4,0),(0,4),(-4,0),(0,-4)}. The list of affine merges remains the same as VTM2.0.1, with a value of 5. Four temporal constructed affine merge candidates are deleted to keep the number of potential affine merge candidates unchanged, i.e., 15 in total. Assume that the coordinates of CPMV1, CPMV2, CPMV3, and CPMV4 are (0,0), (W,0), (H,0), and (W,H). Note that CPMV4 is derived from the temporal MV, as Fig. 9 The removed candidates are the affine merged candidates of the following four time-dependent constructions: {CP2, CP3, CP4}, {CP1, CP4}, {CP2, CP4}, {CP3, CP4}. 2.5 Generalized Audience Prediction Improvement The generalized cellular prediction improvement (GBi) proposed in JVET-L0646 was adopted by VTM-3.0. GBi was proposed in JVET-C0047. JVET-K0248 (J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, J. Boyce, "Algorithmic Description of Joint Exploration Test Model 7 (JEM7)", JVET-G1001, August 2017) GBi's gain-complexity trade-off was proposed and adopted by BMS2.1. BMS2.1 GBi applies unequal weights to predictors from L0 and L1 in grouped prediction mode. In inter prediction mode, multiple weight pairs including equal-weight pairs (1 / 2, 1 / 2) are evaluated based on rate-distortion optimization (RDO), and the GBi index of the selected weight pair is signaled to the decoder. In merge mode, the GBi index is inherited from the neighboring CU. In BMS2.1 GBi, the predictor generation in the dual-layer prediction mode is shown in formula (1). PGBi=(w0*PL0+w1*PL1+RoundingOffsetGBi)>>shift-NumGBi, where PGBi is the final predictor of GBi. w0 and w1 are the selected GBi weight pairs, applied to the predictors of list 0 (L0) and list 1 (L1), respectively. RoundingOffsetGBi and shiftNumGBi are used to normalize the final predictor in GBi. The supported w1 weight sets are {-1 / 4, 3 / 8, 1 / 2, 5 / 8, 5 / 4}, where 5 weights correspond to 1 equal-weighted pair and 4 unequal-weighted pairs. The blending gain, which is the sum of w1 and w0, is fixed to 1.0. Therefore, the corresponding w0 weight set is {5 / 4, 5 / 8, 1 / 2, 3 / 8, -1 / 4}. The selection of weight pairs is at the CU level. For non-low-latency images, the weight set size is reduced from 5 to 3, where the w1 weight set is {3 / 8, 1 / 2, 5 / 8} and the w0 weight set is {5 / 8, 1 / 2, 3 / 8}. The weight set size reduction for non-low-latency images is applied to BMS2.1 GBi and all GBi tests in this contribution. In JVET-L0646, a combined solution based on JVET-L0197. and JVET-L0296. is proposed to further improve GBi performance. Specifically, the following modifications are applied on top of the existing GBi design in BMS2.1. 2.5.1GBi encoder bug fix To reduce GBi encoding time, in the current encoder design, the encoder will store the unidirectional prediction motion vectors estimated from GBi weights equal to 4 / 8 and reuse them for unidirectional prediction search for other GBi weights. This fast encoding method is applicable to both translational motion models and affine motion models. A 6-parameter affine model and a 4-parameter affine model are adopted in VTM2.0. The BMS2.1 encoder does not distinguish between a 4-parameter affine model and a 6-parameter affine model when storing unidirectional prediction affine MVs when GBi weights equal to 4 / 8. Therefore, after encoding with GBi weights 4 / 8, a 4-parameter affine MV may be overwritten by a 6-parameter affine MV. The stored 6-parameter affine MV can be used for 4-parameter affine MEs for other GBi weights, or the stored 4-parameter affine MV can be used for 6-parameter affine MEs. The proposed GBi encoder bug fix is ​​to store 4-parameter and 6-parameter affine MVs separately. When GBi weights equal to 4 / 8, the encoder stores affine MVs based on affine model type and reuses the corresponding affine MVs based on affine model type for other GBi weights. CU size limit of 2.5.2GBi In this method, GBi is disabled for small CUs. In inter prediction mode, if structure prediction is used and the CU area is smaller than 128 samples, GBi is disabled without any signaling. 2.5.3 Merge Mode with GBi In merge mode, the GBi index is not signaled. Instead, it is inherited from the neighboring block it is merged into. When a TMVP candidate is selected, GBi is turned off in that block. 2.5.4 GBi Affine Prediction GBi can be used when the current block is affine predicted. For affine inter mode, the GBi index is signaled. For affine merge mode, the GBi index is inherited from the neighboring block being merged into. If building an affine model is chosen, GBi is turned off in this block. 2.6 Triangle Prediction Model The concept of triangular prediction mode (TPM) is to introduce a new triangular partition for motion compensation prediction. Figure 10a-10b As shown, it splits the CU into two triangular prediction units along the diagonal or counter-diagonal direction. Each triangular prediction unit in the CU uses its own unidirectional prediction motion vector and reference frame index derived from the unidirectional prediction candidate list for inter-frame prediction. After predicting the triangular prediction unit, the diagonal edges are adaptively weighted. Then, the transformation and quantization process is applied to the entire CU. It should be noted that this mode is only applicable to skip and merge modes. 2.6.1TPM One-Way Prediction Candidate List The unidirectional prediction candidate list consists of five unidirectional prediction motion vector candidates. It is derived from seven neighboring blocks, including five spatial neighboring blocks (1 to 5) and two temporal co-located blocks (6 to 7). Fig.11 As shown. The motion vectors of the seven adjacent blocks are collected into a unidirectional prediction candidate list in the order of unidirectional prediction motion vector, L0 motion vector of user prediction motion vector, and L1 motion vector of user prediction motion vector, and the motion vector of L0 and L1 motion vector of terminal prediction motion vector is averaged. If the number of candidates is less than five, zero motion vector is added to the list. The motion candidates added to this list are called TPM motion candidates. More specifically, the following steps are involved: 1) Obtain motion candidate Col2 (corresponding to Fig.11 Blocks 1-7) in the example do not have any pruning operations. 2) Set the variable numCurrMergeCand = 0. 3) For each motion candidate derived from A1, B1, B0, A0, B2, Col, and Col2 and numCurrMergeCand is less than 5, if the motion candidate is uni-predicted (from list 0 or list 1), it is added to the merge list and numCurrMergeCand is increased by 1. This added candidate motion is called the "original uni-predicted candidate". Use comprehensive pruning. 4) For each motion candidate derived from A1, B1, B0, A0, B2, Col and Col2 and numCurrMergeCand is less than 5, if the motion candidate is a directional prediction, the motion information in List 0 is added to the merge list (i.e., modified to a unidirectional prediction in List 0), and numCurrMergeCand is increased by 1. This added candidate motion is called a "truncated list 0 prediction candidate". Use comprehensive pruning. 5) For each motion candidate derived from A1, B1, B0, A0, B2, Col and Col2 and numCurrMergeCand is less than 5, if the motion candidate is bidirectionally predicted, the motion information in List 1 is added to the merge list (i.e., modified to unidirectional prediction in List 1), and numCurrMergeCand is increased by 1. This added candidate motion is called "a candidate with truncated List 1 prediction". Use comprehensive pruning. 6) For each motion candidate derived from A1, B1, B0, A0, B2, Col and Col2 and numCurrMergeCand is less than 5, if the motion candidate is an individual prediction, – If the slice QP of List 0 reference picture is less than the slice QP of List 1 reference picture, the motion information of List 1 is first scaled to List 0 reference picture, and the average of two MVs (one from the original List 0) and the other is the scaled MV from List 1) is added to the merge list, that is, the average of the unidirectional predictions from List 0 motion candidates, and numCurrMergeCand is increased by 1. – Otherwise, first scale the motion information of List 0 to the List 1 reference picture, and add the average of the two MVs (one from the original List 1 and the other one from the scaled MV from List 0) to the merge list, which is the average of the unidirectional predictions of the List 1 candidate motions, and increase numCurrMergeCand by 1. Use comprehensive pruning. 7) If numCurrMergeCand is less than 5, add zero motion vector candidates. 2.6.1.1 Adaptive Weighting Process After predicting each triangle prediction unit, an adaptive weighting process is applied to the diagonal edges between two triangle prediction units to derive the final prediction for the entire CU. Two groups of weight factors are defined as follows: 1 st Weight factor groups: {7 / 8, 6 / 8, 4 / 8, 2 / 8, 1 / 8} and {7 / 8, 4 / 8, 1 / 8} for luma and chroma samples, respectively; 2 nd Set of weighting factors: {7 / 8, 6 / 8, 5 / 8, 4 / 8, 3 / 8, 2 / 8, 1 / 8} and {6 / 8, 4 / 8, 2 / 8} for luma and chroma samples respectively. The weighting factor set is selected based on the comparison of the motion vectors of the two triangle prediction units. When the reference pictures of the two triangle prediction units are different from each other or the difference of their motion vectors is greater than 16 pixels, the second and weighting factor sets are used. Otherwise, 1 is used. st Weighting factor group. Fig.12 Shows application 1 st Example of a CU of a weighting factor group. 2.6.1.2 Motion Vector Storage The motion vector of the triangle prediction unit ( Fig.13 Mv1 and Mv2 in CU are stored in 4×4 grids. For each 4×4 grid, a unidirectional prediction or power prediction motion vector is stored according to the position of the 4×4 grid in the CU. Fig.13 As shown, for a 4×4 grid located in a non-weighted area (i.e., not located at a diagonal edge), a unidirectional prediction motion vector Mv1 or Mv2 is stored. On the other hand, a universal prediction motion vector is stored for a 4×4 grid located in a weighted area. The universal prediction motion vector is derived from Mv1 and Mv2 according to the following rules: 1) In the case where Mv1 and Mv2 have motion vectors from different directions (L0 or L1), Mv1 and Mv2 are simply combined to form the universal prediction motion vector. 2) When both Mv1 and Mv2 come from the same L0 (or L1) direction, – If the reference picture of Mv2 is the same as the picture in the L1 (or L0) reference picture list, Mv2 is scaled to that picture. Mv1 and the scaled Mv2 are combined to form a per-share prediction motion vector. – If the reference picture of Mv1 is the same as the picture in the L1 (or L0) reference picture list, Mv1 is scaled to that picture. The scaled Mv1 and Mv2 are combined to form the endpoint prediction motion vector. – Otherwise, just store Mv1 as the weighted region. 2.7 History-based Motion Vector Prediction A history-based MVP (HMVP) method is proposed, in which the HMVP candidate is defined as the motion information of the previously coded block. A table with multiple HMVP candidates is maintained during the encoding / decoding process. When a new slice is encountered, the table is cleared. Whenever there is an inter-frame coded non-affine block, the associated motion information is added to the last entry of the table as a new HMVP candidate. The entire encoding and decoding process is as follows Fig.14 shown. Fig.15 An example of updating a table in the proposed HMVP method is shown. In this contribution, the table size S is set to 6, which indicates that at most 6 HMVP candidates can be added to the table. When a new motion candidate is inserted into the table, a constrained FIFO rule is utilized, where a redundancy check is first applied to find if the same HMVP exists in the table. If found, the same HMVP is deleted from the table, and then all HMVP candidates are moved forward, i.e., the index is reduced by 1. HMVP candidates can be used in the merge candidate list construction process. The latest few HMVP candidates in the table are checked in order and inserted into the candidate list after the TMVP candidate. Pruning is applied to the HMVP candidates to exclude spatial or temporal merge candidates of sub-block motion candidates (ie, ATMVP). To reduce the number of pruning operations, three simplifications are introduced: 1) The number of HMPV candidates to be checked represented by L is set as follows: L=(N<=4)?M:(8-N) (1) Where N indicates the number of non-sub-block merging candidates available in the table, and M indicates the number of available HMVP candidates. 2) Additionally, once the total number of available merge candidates reaches the signaled maximum allowed merge candidate minus 1, the process of constructing the merge candidate list from the HMVP list is terminated. 3) In addition, the number of pairs used for combined bi-predictive merging candidate derivation is reduced from 12 to 6. Similarly, HMVP candidates can also be used in the AMVP candidate list construction process. The motion vector of the last KHMVP candidate in the table is inserted after the TMVP candidate. Only HMVP candidates with the same reference picture as the AMVP target reference picture are used to build the AMVP candidate list. Pruning is applied to HMVP candidates. In this contribution, K is set to 4, while the AMVP list size remains unchanged, that is, equal to 2. 2.8 Final Motion Vector Expression (UMVE) In this paper, Ultimate Motion Vector Expression (UMVE) is proposed. UMVE is also called Merge with MVD (MMVD) in VVC. UMVE is used for skip or merge mode by the proposed motion vector expression method. UMVE reuses the merge candidates, the same as used in VVC. Among the merge candidates, one candidate can be selected and further extended by the proposed motion vector expression method. UMVE provides a new motion vector expression with simplified signal transmission. The expression method includes starting point, motion amplitude, and motion direction. Fig.16 An example of a UMVE search process is shown. Fig.17 An example of a UMVE search point is shown. This technique uses the merge candidate list as is. However, the UMVE extension only considers candidates of the default merge type (MRG_TYPE_DEFAULT_N). The base candidate index defines the starting point. The base candidate index represents the best candidate among the candidates in the list, as shown below. Table 1 Basic candidate IDX Basic Candidate IDX 0 1 2 3 <![CDATA[N 第 MVP]]> <![CDATA[1 st MVP]]> <![CDATA[2 和 MVP]]> <![CDATA[3 rd MVP]]> <![CDATA[4 第 MVP]]> If the number of basic candidates is equal to 1, the basic candidate IDX is not signaled. The distance index is the motion amplitude information. The distance index represents the predefined distance from the starting point information. The predefined distance is as follows. Table 2. Distance IDX The direction index indicates the direction of the MVD relative to the starting point. The direction index can represent four directions as shown below. Table 3. Direction IDX Directions to IDX 00 01 10 11 x-axis + – not applicable not applicable y-axis not applicable not applicable + – The UMVE flag is signaled immediately after the Skip flag and the Merge flag are sent. If the Skip and Merge flags are true, the UMVE flag is parsed. If the UMVE flag is equal to 1, the UMVE syntax is parsed. However, if it is not 1, the AFFINE flag is parsed. If the AFFINE flag is equal to 1, it is in affine mode, however, if it is not 1, the Skip / Merge index is parsed as the Skip / Merge mode of the VTM. No need for extra line buffering due to UMVE candidates. Because software's skip / merge candidates are used directly as base candidates. Using the input UMVE index, the complement of the MV is decided before motion compensation. No need for long queue buffering for this. 2.9 Inter-Intra Mode With inter-intra mode, multi-hypothesis prediction combines one intra prediction and one merge index prediction. In the merged CU, a flag for merge mode is signaled to select the intra mode from the intra candidate list when the flag is true. For the luma component, the intra candidate list is derived from 4 intra prediction modes including DC, planar, horizontal and vertical modes, and the size of the intra candidate list can be 3 or 4, depending on the block shape. When the CU width is greater than twice the CU height, the horizontal mode is not included in the intra mode list; when the CU height is greater than twice the CU width, the vertical mode is removed from the intra mode list. Weighted averaging is used to combine one intra prediction mode selected by the intra mode index and one merge index prediction selected by the merge index. For chroma components, DM is always applied without additional signaling. The weights of the combined prediction are described as follows. When DC or planar mode is selected or the CB width or height is less than 4, equal weights are applied. For CBs with CB width and height greater than or equal to 4, when horizontal / vertical mode is selected, one CB is first split vertically / horizontally into four equal-area regions. Each weight set, denoted as (w_intra i ,w_inter i ), where i ranges from 1 to 4, and (w_intra1, w_inter1) = (6, 2), (w_intra2, w_inter2) = (5, 3), (w_intra3, w_inter3) = (3, 5) and (w_intra4, w_inter4) = (2, 6) will be applied to the corresponding areas. (w_intra1, w_inter1) is used for the area closest to the reference sample, and (w_intra4, w_inter4) is used for the area farthest from the reference sample. Then, the combined prediction can be calculated by adding the two weighted predictions and shifting right by 3 bits. In addition, the intra prediction mode of the intra-frame hypothesis of the predictor can also be saved for subsequent reference by neighboring CUs. 2.10 Affine Merge Mode with Prediction Offset The proposed method selects the first available affine merge candidate as the base predictor. Then, it applies the motion vector offset to the motion vector value of each control point from the base predictor. If there is no available affine merge candidate, this proposed method is not used. The inter prediction direction of the selected base predictor, the reference index for each direction remains unchanged. In the current implementation, assuming that the affine model of the current block is a 4-parameter model, only 2 control points need to be derived. Therefore, only the first 2 control points of the base predictor will be used as the control point predictor. For each control point, the zero_MVD flag is used to indicate whether the control point of the current block has the same MV value as the corresponding control point predictor. If the Zero_MVD flag is true, no additional signaling is required for the control point. Otherwise, the distance index and offset direction index of the control point are signaled. Use a distance offset table of size 5 as shown in the following table. Send out a distance index signal to indicate which distance offset to use. The mapping of distance index and distance offset value is as follows Fig.18 shown. Table 4 Distance offset table Distance from IDX 0 1 2 3 4 Distance Offset 1 / 2 pixel 1 pixel 2 pixels 4 pixels 8 pixels The direction index can represent four directions as shown below, where only the x or y direction can have MV differences, but not both directions. Offset direction IDX 00 01 10 11 x-direction factor +1 –1 0 0 Y-direction factor 0 0 +1 –1 Table 5 If the inter prediction is uni-prediction, the signaled distance offset is applied to the offset direction of each control point predictor. The result will be the MV value for each control point. For example, when the basic predictor is uni-prediction, the motion vector value of the control point is MVP(vpx, vpy). When the distance offset and direction index are signaled, the motion vector of the corresponding control point of the current block is calculated as follows. MV(vx,vy)=MVP(vpx,vpy)+MV(x-dir-factor*distance offset, y-direction factor*distance offset); If inter prediction is global prediction, the signaled distance offset is applied to the L0 motion vector of the control point predictor in the signaled offset direction; the L1 motion vector of the control point predictor applies the same distance offset in the opposite direction. The result will be the MV value of each control point in each inter prediction direction. For example, when the base predictor is bidirectional prediction, the motion vector value of the control point on L0 is MVP L0 (v0px, v0py), and the motion vector of the control point on L1 is MVP L1 (v1px,v1py). When the distance offset and direction index are signaled, the motion vector of the corresponding control point of the current block is calculated as follows. MV L0 (v0x,v0y)=MVP L0 (v0px,v0py)+MV(x-direction factor*distance offset, y-direction factor*distance offset); MV L1 (v0x,v0y)=MVP L1 (v0px,v0py)+MV(-x direction factor*distance offset,-y direction factor*distance offset); A simplified method is proposed to reduce the signaling overhead by signaling the distance offset index and offset direction index for each block. The same offset will be applied to all available control points in the same way. In this method, the number of control points is determined by the affine type of the basic predictor, 3 control points for the 6-parameter type and 2 control points for the 4-parameter type. The distance offset table and offset direction table are the same as in 2.1. Since all control points of the block are signaled simultaneously, the Ze-ro_MVD flag is not used in this method. 2.11 Representation of Affine Motion Data It is proposed to store affine parameters instead of CPMV to predict the affine model of subsequent encoded blocks. 2.12 Merge List Design VVC supports three different merge list construction processes: 1) Sub-block merge candidate list: includes ATMVP and affine merge candidates. Affine mode and ATMVP mode share a merge list construction process. Here, ATMVP and affine merge candidates can be added in sequence. The sub-block merge list size is marked in the stripe header, and the maximum value is 5. 2) Unidirectional prediction TPM merge list: For triangular prediction mode, even though the two partitions can choose their own merge candidate indexes, one merge list construction process is shared for the two partitions. When building this merge list, the spatial neighboring blocks and two temporal blocks of the block are checked. The motion information derived from the spatial neighbors and temporal blocks are called regular motion candidates in our IDF. These regular motion candidates are further used to derive multiple TPM candidates. Note that the transformation is performed at the whole block level, even though the two partitions can use different motion vectors to generate their own prediction blocks. The unidirectional prediction TPM merge list size is fixed to 5. 3) Regular merge list: For the remaining codec blocks, a merge list construction process is shared. Here, spatial / temporal / HMVP, paired combination of death prediction merge candidates and zero motion candidates can be inserted in order. The regular merge list size is indicated in the slice header, and the maximum value is 6. 2.12.1 Sub-block Merging Candidate List It is proposed to put all sub-block related motion candidates into a separate merge list in addition to the regular merge list for non-sub-block merge candidates. Motion candidates associated with sub-blocks are put into a separate merge list, called "sub-block merge candidate list". In one example, the sub-block merge candidate list includes affine merge candidates, ATMVP candidates and / or sub-block based STMVP candidates. 2.12.2 Affine Merge Candidate List In this contribution, the ATMVP merge candidate in the normal merge list is moved to the first position of the affine merge list, so that all merge candidates in the new list (ie, the sub-block based merge candidate list) are based on the sub-block codec tool. The steps to construct the affine merge candidate list are as follows: Insert inherited affine candidates Inherited affine candidates means that the candidate is derived from the affine motion model of its valid neighbor affine coded block. Up to two inherited affine candidates are derived from the affine motion models of neighboring blocks and inserted into the candidate list. For the left predictor, the scanning order is {A0,A1}; for the above predictors, the scanning order is {B0,B1,B2}. Insert the constructed affine candidate If the number of candidates in the affine merge candidate list is less than MaxNumAffineCand (set to 5), the constructed affine candidate is inserted into the candidate list. Constructing an affine candidate means constructing a candidate by combining the neighboring motion information of each control point. The motion information of the control point is first obtained from Fig. 9 The specified spatial neighbors and temporal neighbors are derived from the shown. CPk (k = 1, 2, 3, 4) represents the kth control point. A0, A1, A2, B0, B1, B2, B3 are the predicted spatial positions of CPk (k = 1, 2, 3); T is the predicted temporal position of CP4. The coordinates of CP1, CP2, CP3 and CP4 are (0,0), (W,0), (H,0) and (W,H), respectively, where W and H are the width and height of the current block. The motion information of each control point is obtained in the following order of priority: For CP1, the priority of checking is B2->B3->A2. If B2 is available, use B2. Otherwise, if B2 is available, use B3. If neither B2 nor B3 is available, use A2. If all three candidates are unavailable, the motion information of CP1 cannot be obtained. For CP2, the checking priority is B1->B0. For CP3, the checking priority is A1->A0. For CP4, use T. Second, combinations of control points are used to construct affine merge candidates. Constructing the 6-parameter affine candidate points requires the motion information of three control points. The three control points can be selected from one of the following four combinations ({CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4}). The combination {CP1, CP2, CP3}, {CP2, CP3, CP4}, {CP1, CP3, CP4} will be converted into a 6-parameter motion model represented by the top left, top right and bottom left control points. Constructing the 4-parameter affine candidate points requires motion information of two control points. The two control points can be selected from one of two combinations ({CP1, CP2}, {CP1, CP3}). These two combinations will be converted into a 4-parameter motion model represented by the top left and top right control points. The combinations of constructed affine candidates are inserted into the candidate list in the following order: {CP1, CP2, CP3}, {CP1, CP2, CP4}, {CP1, CP3, CP4}, {CP2, CP3, CP4}, {CP1, CP2}, {CP1, CP3}. Only when the CPs have the same reference index, available combinations of motion information of the CPs are added to the affine merge list. 4) Fill with zero motion vectors If the number of candidates in the affine merge candidate list is less than 5, zero motion vectors with zero reference index are inserted into the candidate list until the list is full. 2.12.3 Shared Merge List It is proposed that all leaf CUs of an ancestor node in a CU split tree share the same merge candidate list to enable parallel processing of small skipped / merged coded CUs. The ancestor node is called a merge shared node. The shared merge candidate list is generated at the merge shared node, assuming that the merge shared node is a leaf CU. 2.13 Historical Affine Prediction History-based affine parameter inheritance 1. The affine encoded blocks in the definition of parameters a, b, c, d, e and f in equation (2) can be stored in a buffer (a buffer can be a table, a lookup table, a first-in-first-out (FIFO) table, or a stack, or a queue, or a list, or a link, or an array, or any other storage with any data structure) or a constrained FIFO table, where each affine model is unique. In the following discussion, an entry in the buffer is represented as H[i], where i is the index referencing the entry. a. a, b, c, and d defined in formula (2) can be stored in the buffer; in this case, e and f are no longer stored. b. Formulaically, if the 4-parameter affine mode is used for encoding and decoding, a and b defined in equation (1) can be stored in the buffer; ca,b,e and f defined in equation (1) can be stored in the buffer if it is a 4-parameter affine mode that has been encoded; d. Parameters a, b, c, d, e and f defined in Eq (2) are always stored in the buffer, but with the restriction that c = -b, d = a if it is a 4-parameter affine model that is encoded and decoded. e. The parameters a, b, c and d defined in equation (2) are always stored in the buffer, but are subject to the restriction that c = -b, d = a if encoded and decoded using the 4-parameter affine model. f. For 4-parameter and 6-parameter affine models, the same number of parameters may be stored, such as a, b, c, d [store, e, and f. In another example, store a, b, c, and d. g. In practice, 4-parameter and 6-parameter affine models can store different numbers of parameters, and can also store the affine model type (i.e., 4-parameter or 6-parameter). h. Which parameters are stored in the buffer may depend on affine mode, inter or merge mode, block size, image type, etc. i. Side information associated with the affine parameters may also be stored in the buffer together with the affine parameters, such as the inter prediction direction (list 0 or list 1, or Bi), and the reference index of list 0 and / or list 1. In the present disclosure, when talking about a set of affine parameters stored in a buffer, the associated side information may also be included. i. If the affine coded block is bi-directionally predicted, the affine parameter set to be stored includes the parameters for list 0 and the parameters for list 1. (a) The parameters of two reference lists (List0 and List1) are stored. (b) In one example, the parameters of the two reference lists are stored independently (in two different buffers); (c) First, the parameters of the two reference lists can be stored by predicting from one to the other. j. As an alternative storage method, the affine-encoded CPMV {MV0, MV1} or {MV0, MV1, MV2} is stored in the buffer instead of the parameters. The parameters of the new block can be calculated based on {MV0, MV1} or {MV0, MV1, MV2} when needed. i. The width of the affine encoded block may be stored in a buffer along with the CPMV. ii. The height of the affine encoded block may be stored in a buffer along with the CPMV. iii. The top left corner coordinate of the affine encoded block may be stored in a buffer together with the CPMV. k. In one example, the basic Stored with parameters a and b. i. In one example, the coordinates of the location of the base MV are also stored along with the parameters a and b. l. In one example, the basic With parameters a, b, c and d are stored together. i. In one example, the coordinates of the location of the base MV are also stored, with parameters a, bc and d]. m. In one example, if a set of stored parameters and its base MV refer to the same reference picture list, they should refer to the same reference picture. n. A buffer used to store encoded / decoded affine related information, such as CPMV, affine parameters, base point position coordinates, block width and height, also referred to as "affine HMVP buffer" in this document. 2. In one example, the parameters stored in the buffer can be calculated as follows a. b. c. d. ec=-b is used for 4-parameter affine prediction. fd=a is used for 4-parameter affine prediction. g. h. i. (e, f) = (mvx, mvy), where (mvx, mvy) can be any MV used to encode or decode a block. 3. It is proposed that the affine model parameters can be calculated without division operation. Assume that the width and height of the current block are recorded as w and h, which are equal to 2 WB and 2 HB . P is an integer that defines the calculation precision, for example, P is set to 7. a. b. c. d. 4. The affine model parameters can be further pruned before being stored in the buffer. a. In one example, assume that parameter x (eg, x=a or b or c or d) is stored K bits, then x = Clip3 (-2 K-1 ,2 K-1 -1,x). b. For example, a=Clip(-128,127,a), then a is stored as an 8-bit signed integer. 5. Affine model parameters can be pruned (eg, to derive MVs of sub-blocks) before being used for encoding / decoding an affine-encoded block. a. In one example, a=Clip3(Min_a, Max_a,a), b=Clip3(Min_b, Max_b,b), c=Clip3(Min_c, Max_c,c), d=Clip3(Min_d, Max_d,d) where Min_a / b / c / d and Max_a / b / c / d are called clipping boundaries. b. In one example, the clipping boundary may depend on the precision (eg, bit depth) of the affine parameters. c. In one example, the clipping boundary may depend on the width and height of the block. d. In one example, clip boundaries may be signaled, for example, in a VPS / SPS / PPS / picture header / slice header / tile group header. e. In one example, the clipping boundaries may depend on the profile and / or level of the standard. 6. The affine model parameters of each affine encoded block may be stored in a buffer after decoding or encoding the block. a. Whether to store the affine model parameters of an affine encoded block may depend on the encoded affine mode (eg, affine AMVP or affine merge), the number of affine encoded blocks, the affine encoding of the block, the block dimension, and the like. b. In one example, the affine model parameters of each K affine coded blocks are stored in a buffer after decoding or encoding each K affine coded blocks. That is, the affine model parameters of each first, second, ... The (K-1)th affine coded block is not stored in the buffer. iK is a number, such as 2 or 4. ii. K can be signaled from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile. 7. The buffer used to store affine parameters can have a maximum capacity. a. The buffer can store at most M sets of affine parameters, that is, for H[i], i>=0 and i <M。 iM is an integer, such as 8 or 16. ii.M can be signaled from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU line / CTU. iii. M may be different for different standard profiles / levels / tiers. 8. When the affine parameter storage buffer is not full (ie, the number of stored affine parameter groups S is less than the maximum capacity M), a new set of affine parameters needs to be stored in the buffer, and H[S-1] is used to store the new parameters, then S=S+1. 9. When the buffer is full (i.e., the number of stored affine parameter sets S is equal to the maximum capacity M), when a new set of affine parameters needs to be stored in the buffer, one or more of the following strategies can be adopted: a. The new set of affine parameters cannot be stored in the buffer; b. An existing entry in the buffer is deleted and the new set of affine parameters is stored in the buffer. i. In one example, the oldest entry stored in the buffer, eg, H[0] is removed from the buffer. ii. In one example, the last entry stored in the buffer, eg, H[M-1] is removed from the buffer. iii. In one example, any entry stored in the buffer, such as H[T], is removed from the buffer, T>=0 and T <M。 iv. If H[T] is deleted, the new set of affine parameters will be stored as H[T]. v. If H[T] is deleted, all entries after H[T] will be moved forward. For example, for X in ascending order from T to M-1, H[X] = H[X+1]. Then the new affine parameter set is placed in the last entry in the buffer, such as H[M-1]; vi. If H[T] is deleted, all entries before H[T] are moved backwards. For example, H[X] = H[X-1], where X is sorted in descending order from T to 1. Then the new affine parameter set is placed in the first entry in the buffer, such as H[0]; 10. When a new set of affine parameters needs to be stored in the buffer, it can be compared with all or some of the affine parameter sets already in the buffer. If it is judged to be the same or similar to at least one set of affine parameters already in the buffer, it should not be stored in the buffer. This process is called "pruning". a. For a reference picture list (a prediction direction), the affine parameters {a,b,c,d} or {a,b,c,d,e,f} and the affine parameters {a',b',c',d'} or {a',b',c',d',e',f'} are considered to be the same or similar if ia == a' in one example. ii. In one example, b == b'. iii. In one example, c == c'. iv. In one example, d == d'. v. In one example, a == a' and b == b'. vi. In one example, c == c' and d == d'. vii. a == a' and b == b' and c == c' in one example. viii. a == a' and b == b' and c == c' in one example, and d == d'. ix. |a - a'| < delta0 in one example. x. |b - b'| < delta0 in one example. xi. |c - c'| < delta0 in one example. xii. |d - d'| < delta0 in one example. xiii. |a - a'| < delta0 and |b - b'| < delta1 in one example. xiv. |c - c'| < delta0 and |d - d'| < delta1 in one example. xv. |a - a'| < delta0 and |b - b'| < delta1 and |c - c'| < delta2 in one example. xvi. |a - a'| < delta0 and |b - b'| < delta1 and |c - c'| < delta2 and |d - d'| < delta3 in one example. xvii. The variables (e.g., delta0, delta1, delta2, delta3) can be predefined numbers, or it can depend on encoding / decoding information such as block width / height. For different standard profiles / levels / layers, it may vary. It can be signaled from the encoder to the decoder in the VPS / SPS / PPS / slice header / tile group header / tile / CTU row / CTU. b. Two sets of affine parameters are considered different or dissimilar if the following conditions are met: i. They are associated with different inter - prediction directions (list 0 or list 1, or Bi), ii. When list 0 is one of the prediction directions in use, they are associated with different reference indices in list 0. iii. When list 1 is one of the prediction directions in use, they are associated with different reference indices in list 1. iv. They have different numbers of affine parameters or use different affine models. c. If both sets of affine parameters are associated from capacity prediction, they are judged to be the same (or similar) if the parameters of list 0 are judged to be the same (or similar) and the parameters of list 1 are also judged to be the same (or similar). d. The new set of affine parameters can be compared with each set of affine parameters already in the buffer. i. However, the new affine parameter set is only compared with some of the affine parameter sets that are already in the buffer. For example, it is compared with the first W entries, such as H[0]...H[W-1]. In another example, it is compared with the last W entries, such as H[MW], H[M-1]. In another example, it is compared with one entry in each of the W entries, such as H[0], H[W], H[2*W]. e. If an entry in the buffer (denoted as H[T]) is found to be the same or similar to the set of new affine parameters and needs to be stored in the buffer, then iH[T] is deleted and the new set of affine parameters is stored as H[T]. ii. H[T] is deleted, and then all entries after H[T] are moved forward. For example, for X in ascending order from T to M-1, H[X] = H[X+1]. The new affine parameter set is then placed in the last entry in the buffer, for example H[M-1]. iii. H[T] is deleted, and then all entries before H[T] are moved backwards. For example, H[X] = H[X-1], where X is sorted in descending order from T to 1. Then the new affine parameter set is placed in the first entry in the buffer, such as H[0]. 11. The buffer storing the affine parameters can be flushed. a. The buffer will be cleared when refreshing. b. Clear the buffer when refreshing and put one or more default affine parameters into the buffer when refreshing. i. For different sequences, the default affine parameters can be different; ii. The default affine parameters of different images can be different; iii. The default affine parameters of different slices can be different; iv. The default affine parameters of different tiles can be different; v. For different CTU (also called LCU) lines, the default affine parameters can be different; vi. For different CTUs, the default affine parameters can be different; vii. Default affine parameters may be signaled from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile / CTU line / CTU. c. Buffer refresh i. Start encoding / decoding the first block of the picture; ii. Start encoding / decoding the first block of the strip; iii. Start encoding / decoding the first block of the tile; iv. Start encoding / decoding the first block of a CTU (also called LCU) row; v. Start encoding / decoding the first block of CTU; 12. The affine model parameters stored in the buffer can be used to derive the affine prediction of the current block. a. In one example, the parameters stored in the buffer can be used for motion vector prediction or motion vector encoding and decoding of the current block. b. In one example, the parameters stored in the buffer may be used to derive the control point MV (CPMV) of the current affine encoded block. c. In one example, the parameters stored in the buffer may be used to derive the MV used in motion compensation of a sub-block of the current affine encoded block. d. In one example, the parameters stored in the buffer can be used to derive a prediction of the CPMV of the current affine encoded block. When the CPMV needs to be encoded, the CPMV prediction can be used to predict the CPMV of the current block. i. In one example, if the current block is encoded and decoded using a 4-parameter affine model, a higher priority is assigned to the 4-parameter affine model, and a lower priority is assigned to the 6-parameter affine model. ii. In one example, if the current block is encoded and decoded using a 6-parameter affine model, a higher priority is assigned to the 6-parameter affine model, and a lower priority is assigned to the 4-parameter affine model. 13. The motion information of the adjacent M×N unit blocks (e.g., 4×4 blocks in VTM) and the set of affine parameters stored in the buffer can be used together to derive the affine model of the current block. For example, they can be used to derive the CPMV or MV of the sub-block used in motion compensation. Fig.19 An example of deriving the CPMV from the MVs of neighboring blocks and a set of parameters stored in a buffer is shown. a. Assume that the MV stored in the cell block is (mvh0,mv v 0), coordinates derived MV(mvh(x,y),mv v(x,y)) is represented as (x,y)). Assuming the coordinates of the upper left corner of the current block are (x0',y0'), and the width and height of the current block are w and h, then i. To derive CPMV, (x,y) can be (x0',y0'), or (x0'+w,y0'), or (x0',y0'+h), or (x0'+w,y0'+h). ii. To derive the MV of the sub-block of the current block, (x, y) can be the center of the sub-block. Assuming (x00, y00) is the top left corner of the sub-block and the sub-block size is M×N, then (a)xm=x00+M / 2, ym=y00+N / 2; (b)xm=x00+M / 2-1, ym=y00+N / 2-1; (c)xm=x00+M / 2-1, ym=y00+N / 2; (d)xm=x00+M / 2, ym=y00+N / 2-1; iii. In one example, If the parameters in the buffer come from a decoded block with a 4-parameter affine model. iv. In one example, If the parameters in the buffer come from an affine module with 6 parameters The decoded block of the formula. v.In one example, Whether the parameters in the buffer come from a 4-parameter affine model or a 6 Parameters of the affine mode of the encoded block. b. In one example, the CPMV of the current block is derived from the motion vectors and parameters stored in the buffer, and these CPMVs are used as MVPs for the signaled CPMV of the current block. c. In one example, the CPMV of the current block is derived from the motion vectors and parameters stored in the buffer, and these CPMVs are used to derive the MV of each sub-block used for motion compensation. d. In one example, if the current block is affine merge coded, the MV of each sub-block used for motion compensation is derived from the motion vectors and parameters stored in the neighboring blocks. e. In one example, the motion vector of the neighboring unit block and the parameter set used to derive the CPMV or MV of the sub-block used in motion compensation of the current block should follow some or all of the following constraints: i. They are associated with the same inter prediction direction (list 0 or list 1, or Bi). ii. When list 0 is the one prediction direction in use, they are associated with the same reference index of list 0. iii. When List 1 is the one prediction direction in use, they are associated with the same reference index of List 1. 14. The affine model of the current block derived from the set of affine parameters stored in the buffer can be used to generate affine merge candidates. a. In one example, side information such as inter prediction direction and reference index of list0 / list1 associated with the stored parameters is inherited by the generated affine merge candidate. b. Affine merge candidates derived from the set of affine parameters stored in the buffer may be inserted into the affine merge candidate list, after the affine merge candidates inherited from the neighboring blocks and before the constructed affine merge candidates; c. Affine merge candidates derived from the set of affine parameters stored in the buffer may be inserted after the constructed affine merge candidates and before the padding candidates in the affine merge candidate list. d. Affine merge candidates derived from the set of affine parameters stored in the buffer can be inserted into the affine merge list after the affine merge candidates constructed without using temporal motion prediction ( Fig. 9 block T in , before the affine merge candidate constructed using temporal motion prediction. Temporal motion prediction ( Fig. 9 Block T in ); e. Affine merge candidates derived from the set of affine parameters stored in the buffer may be inserted into the affine merge candidate list, and they may be interleaved with the constructed affine merge candidates and / or padding candidates. 15. The affine parameters stored in the buffer can be used to generate affine AMVP candidates. a. In one example, the stored parameters used to generate the affine AMVP candidate should reference the same reference picture as the target reference picture of the affine AMVP coded block. i. In one example, the reference picture list associated with the stored parameters should be the same as the target reference picture list. ii. In one example, the reference index associated with the stored parameters should be the same as the target reference index. b. The affine AMVP candidate derived from the set of affine parameters stored in the buffer can be inserted into the affine AMVP candidate list, after the affine AMVP candidate inherited from the neighboring block and before the constructed affine AMVP candidate; c. The affine AMVP candidate derived from the set of affine parameters stored in the buffer may be inserted into the affine AMVP candidate list, after the constructed affine AMVP candidate and before the HEVC-based affine AMVP candidate. d. Affine AMVP candidates derived from the set of affine parameters stored in the buffer may be inserted into the affine AMVP candidate list after the HEVC-based affine AMVP candidates and before the padding affine AMVP candidates. e. Affine AMVP candidates derived from the set of affine parameters stored in the buffer can be inserted into the affine AMVP list after the affine AMVP candidates constructed without using temporal motion prediction ( Fig. 9 Block T in , before the affine AMVP candidate constructed using temporal motion prediction. Temporal motion prediction ( Fig. 9 Block T in ); f. In one example, if the current block is encoded and decoded using a 4-parameter affine model, a higher priority is assigned to the 4-parameter affine model, and a lower priority is assigned to the 6-parameter affine model. g. In one example, if the current block is encoded and decoded using a 6-parameter affine model, a higher priority is assigned to the 6-parameter affine model, and a lower priority is assigned to the 4-parameter affine model. 16. It is possible to pre-define how many sets of affine model parameters in the buffer are added to the candidate list (denoted by N). aN may be signaled from the encoder to the decoder in VPS / SPS / PPS / slice header / tile group header / tile. bN may depend on the block size, the encoded mode information (eg, AMVP / Merge), etc. cN may depend on the standard profile / level / tier. dN may depend on the candidates available in the list. iN may depend on a certain type of available candidates (eg, inherited affine motion candidates). 17. How to select a portion of all affine model parameter sets in the buffer (eg, N as in bullet point 15) to be inserted into the candidate list may be pre-defined. a. In one example, the latest few groups in the buffer (eg, the last N entries). b. It may depend on the index of the affine model parameter group in the buffer. 18. When you need to insert multiple sets of affine model parameters into the candidate list, you can add them in ascending order of index. a. Place of entrepreneurship can be added in descending order of index. b. Entrepreneurial location, the rule for determining the insertion order is based on the number of available candidates in the candidate list, and then adding the candidates in the buffer. 19. The set of affine parameters stored in the buffer, their associated base MVs and the locations of the base MVs can be used together to derive the affine model of the current block. For example, they can be used to derive the CPMV or MV of the sub-blocks used in motion compensation. a. Assume that the associated base MV is (mvh0,mv v 0) and the coordinates of the position to derive MV(mvh(x,y), mv v (x,y)) is represented as (x,y). Assuming the coordinates of the upper left corner of the current block are (x0',y0'), and the width and height of the current block are w and h, then i. To derive CPMV, (x,y) can be (x0',y0'), or (x0'+w,y0'), or (x0',y0'+h), or (x0'+w,y0'+h). ii. To derive the MV of a sub-block of the current block, (x, y) may be the center of the sub-block. iii. Assume that (xm, ym) is the coordinate of the location (base location) where the base MV is stored. iv. In one example, If the parameters in the buffer come from an affine module with 4 parameters The decoded block of the formula. v.In one example, If the parameters in the buffer come from an affine module with 6 parameters The decoded block of the formula. vi. In one example, Whether the parameters in the buffer come from a 4-parameter affine model or a 6 Parameters of the affine mode of the encoded block. b. In one example, the CPMV of the current block is derived from the motion vectors and parameters stored in the buffer, and these CPMVs are used as MVPs for the signaled CPMV of the current block. c. In one example, the CPMV of the current block is derived from the associated base MVs and parameters stored in a buffer, and these CPMVs are used to derive the MVs of each sub-block used for motion compensation. d. In one example, if the current block is affine-merging coded, the MV of each sub-block used for motion compensation is derived from the associated base MV and parameters stored in neighboring blocks. 20. The motion information of spatially adjacent / discontinuous M×N unit blocks (e.g., 4×4 blocks in VTM) and the set of affine parameters stored in the buffer can be used together to derive the affine model of the current block. For example, they can be used to derive the CPMV or MV of the sub-block used in motion compensation. a. Assume that the MV stored in the cell block is (mvh0,mv v 0), coordinates derived MV(mvh(x,y),mv v (x,y)) is represented as (x,y)). Assuming the coordinates of the upper left corner of the current block are (x0',y0'), and the width and height of the current block are w and h, then i. To derive CPMV, (x,y) can be (x0',y0'), or (x0'+w,y0'), or (x0',y0'+h), or (x0'+w,y0'+h). ii. To derive the MV of a sub-block of the current block, (x, y) may be the center of the sub-block. iii. Assuming (x00, y00) is the upper left corner position of the spatially adjacent M×N unit block, the base position (xm, ym) can be derived as: (a)xm=x00+M / 2, ym=y00+N / 2; (b)xm=x00+M / 2-1, ym=y00+N / 2-1; (c)xm=x00+M / 2-1, ym=y00+N / 2; (d)xm=x00+M / 2, ym=y00+N / 2-1; iv. In one example, If the parameters in the buffer come from a decoded block with a 4-parameter affine model. v.In one example, If the parameters in the buffer come from a decoded block with a 6-parameter affine model. vi. In one example, Regardless of whether the parameters in the buffer come from the 4-parameter affine mode or the 6-parameter affine mode, the block is encoded and decoded. b. In one example, the CPMV of the current block is derived from the motion vectors of spatial neighboring unit blocks and parameters stored in the buffer, and these CPMVs are used as the MVP of the signaled CPMV of the current block. c. In one example, the CPMV of the current block is derived from the motion vectors of spatially neighboring unit blocks and parameters stored in a buffer, and these CPMVs are used to derive the MV of each sub-block for motion compensation. d. In one example, if the current block is affine merge-encoded, the MV of each sub-block used for motion compensation is derived from the motion vectors of spatial neighboring unit blocks and the parameters stored in the neighboring blocks. e. In one example, the motion vectors of the spatial neighboring unit blocks and the parameter set used to derive the CPMV or MV of the sub-block used in motion compensation of the current block should follow some or all of the following constraints: i. They are associated with the same inter prediction direction (list 0 or list 1, or Bi). ii. When list 0 is the one prediction direction in use, they are associated with the same reference index of list 0. iii. When List 1 is the one prediction direction in use, they are associated with the same reference index of List 1. f. In one example, if the MV of the spatially neighboring M×N unit block and the stored affine parameters refer to different reference pictures, the MV of the spatially neighboring M×N unit block is scaled to refer to the same reference picture as the stored affine parameters to derive the affine model of the current block. 21. It is suggested that temporal motion vector prediction (TMVP) can be used with the affine parameters stored in the buffer. For example, they can be used to derive the CPMV or MV of the sub-block used in motion compensation. Fig. 20 Examples of possible locations of co-location blocks are shown. a. The motion information of the co-located M×N unit block (e.g., 4×4 block in VTM) in the co-located picture and the set of affine parameters stored in the buffer can be used together to derive the affine model of the current block. For example, they can be used to derive the CPMV or MV of the sub-block used in motion compensation. i. Fig. 22 Examples of possible locations of co-location cell blocks are shown. (A1-A4, B1-B4, ... F1-F4, J1-J4, K1-K4, and L1-L4. b. Assume that the MV stored in the same unit block is (mvh0,mv v 0), and derive MV(mvh(x,y),mv v The coordinates of the position (x, y)) are expressed as (x, y). Assuming that the coordinates of the upper left corner of the current block are (x0', y0'), and the width and height of the current block are w and h, then i. To derive CPMV, (x,y) can be (x0',y0'), or (x0'+w,y0'), or (x0',y0'+h), or (x0'+w,y0'+h). ii. To derive the MV of a sub-block of the current block, (x, y) may be the center of the sub-block. iii. Assuming (x00, y00) is the upper left corner position of the same M×N unit block, the base position (xm, ym) can be derived as: (a)xm=x00+M / 2, ym=y00+N / 2; (b)xm=x00+M / 2-1, ym=y00+N / 2-1; (c)xm=x00+M / 2-1, ym=y00+N / 2; (d) xm=x00+M / 2, ym=y00+N / 2-1. iv. In one example, If the parameters in the buffer come from a decoded block with a 4-parameter affine model. v.In one example, If the parameters in the buffer come from a decoded block with a 6-parameter affine model. vi. In one example, Regardless of whether the parameters in the buffer come from the 4-parameter affine mode or the 6-parameter affine mode, the block is encoded and decoded. c. In one example, the CPMV of the current block is derived from the motion vectors of temporally neighboring blocks and parameters stored in the buffer, and these CPMVs are used as MVPs for the signaled CPMV of the current block. d. In one example, the CPMV of the current block is derived from the motion vectors of temporally neighboring blocks and parameters stored in a buffer, and these CPMVs are used to derive the MV of each sub-block for motion compensation. e. In one example, if the current block is affine merge coded, the MV of each sub-block used for motion compensation is derived from the motion vectors of temporal neighboring blocks and the parameters stored in the neighboring blocks. f. In one example, the motion vectors of the temporal neighboring unit blocks and the parameter set used to derive the CPMV or MV of the sub-blocks used in motion compensation of the current block should follow some or all of the following constraints: i. They are associated with the same inter prediction direction (list 0 or list 1, or Bi). ii. When list 0 is the one prediction direction in use, they are associated with the same reference index of list 0. iii. When List 1 is the one prediction direction in use, they are associated with the same reference index of List 1. g. In one example, if the MV of the temporally adjacent M×N unit block and the stored affine parameters refer to different reference pictures, the MV of the spatial-temporal M×N unit block is scaled to refer to the same reference picture as the stored affine parameters to derive the affine model of the current block. i. For example, the POC of the same-position picture is POCx; the POC of the reference picture referred to by the MV of the temporally adjacent M×N unit block is POCy; the POC of the current picture is POCz; the stored affine parameter referred to by the POC of the reference picture is POCw, then (mvh0,mv v 0) Scale to mvh0=mvh0×(POCw-POCz) / (POCy-POCx) and mvv0=mvv0×(POCw-POCz) / (POCy-POCx). 22. The affine merge candidate derived from the parameters stored in the buffer and one or more spatially adjacent / non-contiguous unit blocks may be placed into an affine merge candidate list. a. In one example, these candidates are placed after the inherited affine merge candidates. b. In one example, these candidates are placed after the first constructed affine merge candidate. c. In one example, these candidates are placed after the first affine merged candidates constructed from spatially neighboring blocks. d. In one example, these candidates are placed after all constructed affine merge candidates. e. In one example, these candidates are placed before all zero affine merge candidates. f. In one example, if another affine merge candidate is inherited from a spatial neighboring unit block, the spatial neighboring unit block is not used to derive an affine merge candidate using parameters stored in a buffer. g. In one example, a spatial neighboring unit block can be used to derive an affine merge candidate using only a set of parameters stored in a buffer. In other words, if a spatial neighboring unit block and a set of parameters stored in a buffer have derived an affine merge candidate, it cannot be used to derive another affine merge candidate with another set of parameters stored in a buffer. h. In one example, at most N affine merge candidates derived from the parameters stored in the buffer can be put into the affine merge candidate list. N is an integer, such as 3. i. In one example, if the current block selects an affine merge candidate derived from parameters stored in the buffer and spatial neighboring unit blocks, the GBI index of the current block is inherited from the GBI index of the spatial neighboring blocks. j. In one example, affine merge candidates derived from parameters stored in the buffer block and spatial neighboring blocks are sequentially placed into an affine merge candidate list. i. For example, a two-level nested loop method is used to search for available affine merge candidates derived from parameters stored in the buffer block and spatial neighboring blocks, and put them into an affine merge candidate list. (a) In the first level loop, each set of parameters stored in the buffer is accessed sequentially. They can be accessed from the beginning to the end of the table, or from the end to the beginning of the table, or in any other predefined or adaptive order. a. In the example, some parameter groups stored in the buffer are skipped in the first cycle. For example, the first N groups or the last N groups in the table are skipped. In fact, if k%S==0, H[k]s is skipped. In fact, if k%S!=0, H[k]s is skipped. (b) For each set of parameters stored in the buffer, a second level loop is applied. In the second level loop, each spatially neighboring block is visited sequentially. For example, accessing Fig. 9 Blocks A1, B1, B0, A0, B2 are shown. In a pseudo-codec implementation, the nested loop can be described as: a. In one example, the second ring may include only one spatially adjacent block, for example, only A1. b. Using the set of parameters given in the first-level loop and the spatially neighboring blocks given in the second-level loop, if all or part of the following conditions are met, an affine merge candidate is generated and placed into the affine merge candidate list. i. Spatial adjacent blocks are available; ii. The spatial neighboring blocks are inter-coded; iii. The spatial neighboring blocks are not outside the current CTU row. iv. The inter-frame prediction of this set of parameters (list 0, list1 or bi) is the same as the prediction of the spatial neighboring blocks; v. The reference index of the parameter list 0 is the same as the reference index of the spatial neighboring block; vi. The reference index of the set of parameter list 1 is the same as the reference index of the spatial neighboring block; vii. The POC of the reference picture of list 0 of the set of parameters is the same as the POC of one of the reference pictures of the spatial neighboring block. viii. The POC of the reference picture of List 1 of the set of parameters is the same as the POC of one of the reference pictures of the spatial neighboring block. c. In one example, if a neighboring block has been used to derive an inherited affine merge candidate, it is skipped in the second loop and not used to derive an affine merge candidate with stored affine parameters. d. In one example, if a neighboring block has been used to derive an affine merge candidate with a set of stored affine parameters, it is skipped in the second loop and not used to derive an affine merge candidate with another set of stored affine parameters. Parameters. e. In one example, if a neighboring block is used to derive an affine merge candidate, all other neighboring blocks after the neighboring block are skipped, and the second loop is interrupted and returns to the first loop. The set of next parameters is accessed in the first loop. 23. Affine merge candidates derived from the parameters stored in the buffer and one or more time unit blocks may be placed into an affine merge candidate list. a. In one example, these candidates are placed after the inherited affine merge candidates. b. In one example, these candidates are placed after the first constructed affine merge candidate. c. In one example, these candidates are placed after the first affine merged candidates constructed from spatially neighboring blocks. d. In one example, these candidates are placed after all constructed affine merge candidates. e. In one example, these candidates are placed after all affine merge candidates derived from parameters stored in the buffer and spatial neighboring blocks. f. In one example, these candidates are placed before all zero affine merge candidates. g. In one example, at most N affine merge candidates derived from the parameters stored in the buffer can be put into the affine merge candidate list. N is an integer, such as 3. h. In one example, if the current block selects an affine merge candidate derived from parameters stored in the buffer and temporal neighboring blocks, the GBI index of the current block is inherited from the GBI index of the temporal neighboring blocks. i. In one example, affine merge candidates derived from parameters stored in the buffer block and the temporal neighboring blocks are sequentially put into an affine merge candidate list. i. For example, a two-level nested loop method is used to search for available affine merging candidates derived from parameters stored in the buffer block and the temporal neighboring blocks, and put them into an affine merging candidate list. (a) In the first level loop, each set of parameters stored in the buffer is accessed sequentially. They can be accessed from the beginning to the end of the table, or from the end to the beginning of the table, or in any other predefined or adaptive order. a. In the example, some parameter groups stored in the buffer are skipped in the first cycle. For example, the first N groups or the last N groups in the table are skipped. In fact, if k%S==0, H[k]s is skipped. In fact, if k%S!=0, H[k]s is skipped. (b) For each set of parameters stored in the buffer, a second level loop is applied. In the second level loop, each temporally adjacent block is accessed sequentially. For example, Fig. 20 Blocks L4 and E4 are shown. In a pseudo-codec implementation, the nested loops can be described as: a. In one example, the second loop may include only one temporally adjacent block, for example, only L4. b. Using the set of parameters given in the first-level loop and the neighboring blocks given in the second-level loop, if all or part of the following conditions are met, an affine merge candidate is generated and placed in the affine merge candidate list. i. Neighboring blocks are available; ii. The neighboring block is inter-coded; iii. The neighboring block is not outside the current CTU row. iv. The parameter set is the same as the inter-frame prediction (list 0, list1 or bi) of the adjacent block; v. The reference index of the parameter list 0 is the same as the reference index of the adjacent block; vi. The reference index of the set of parameter list 1 is the same as the reference index of the adjacent block; vii. The POC of the reference picture of list 0 of the set of parameters is the same as the POC of one of the reference pictures of the neighboring block. viii. The POC of the reference picture of List 1 of the set of parameters is the same as the POC of one of the reference pictures of the neighboring block. c. In one example, if a neighboring block has been used to derive an inherited affine merge candidate, it is skipped in the second loop and not used to derive an affine merge candidate with stored affine parameters. d. In one example, if a neighboring block has been used to derive an affine merge candidate with a set of stored affine parameters, it is skipped in the second loop and not used to derive an affine merge candidate with another set of stored affine parameters. Parameters. e. In one example, if a neighboring block is used to derive an affine merge candidate, all other neighboring blocks after the neighboring block are skipped, and the second loop is interrupted and returns to the first loop. The set of next parameters is accessed in the first loop. 24. Affine AMVP candidates derived from the parameters stored in the buffer and one or more spatially adjacent / non-contiguous unit blocks may be placed into an affine AMVP candidate list. a. In one example, these candidates are placed after the inherited affine AMVP candidates. b. In one example, these candidates are placed after the first constructed AMVP merge candidate. c. In one example, these candidates are placed after the first affine AMVP candidates constructed from spatially neighboring blocks. d. In one example, these candidates are placed after all constructed affine AMVP candidates. e. In one example, these candidates are placed after the first translation affine AMVP candidate. f. In one example, these candidates are placed after all translational affine AMVP candidates. g. In one example, these candidates are placed before all zero-affine AMVP candidates. h. In one example, if another affine AMVP candidate is inherited from a spatial neighboring unit block, the spatial neighboring unit block is not used to derive the affine AMVP candidate using parameters stored in the buffer. i. In one example, a spatial neighboring unit block can be used to derive an affine AMVP candidate using only a set of parameters stored in a buffer. In other words, if a spatial neighboring unit block and a set of parameters stored in a buffer have already derived an affine AMVP candidate, it cannot be used to derive another affine AMVP candidate using another set of parameters stored in a buffer. j. In one example, at most N affine AMVP candidates and spatial neighboring unit blocks derived from the parameters stored in the buffer can be put into the affine AMVP candidate list. N is an integer, such as 1. k. In one example, the affine AMVP candidates derived from the parameters stored in the buffer block and the spatial neighboring blocks are sequentially placed into the affine AMVP candidate list. i. For example, a two-level nested loop method is used to search for available affine AMVP candidates derived from parameters stored in the buffer block and the spatial neighboring blocks, and put them into the affine AMVP candidate list. (a) In the first level loop, each set of parameters stored in the buffer is accessed sequentially. They can be accessed from the beginning to the end of the table, or from the end to the beginning of the table, or in any other predefined or adaptive order. a. In the example, some parameter groups stored in the buffer are skipped in the first cycle. For example, the first N groups or the last N groups in the table are skipped. In fact, if k%S==0, H[k]s is skipped. In fact, if k%S!=0, H[k]s is skipped. (b) For each set of parameters stored in the buffer, a second-level loop is applied. In the second-level loop, each spatially neighboring block is accessed sequentially. For example, Fig. 9 Blocks A1, B1, B0, A0, B2 are shown. In a pseudo-codec implementation, the nested loop can be described as: a. In one example, the second ring may include only one spatially adjacent block, for example, only A1. b. Using the set of parameters given in the first-level loop and the spatially neighboring blocks given in the second-level loop, if all or part of the following conditions are met, an affine AMVP candidate is generated and placed in the affine AMVP candidate list. i. Spatial adjacent blocks are available; ii. The spatial neighboring blocks are inter-coded; iii. The spatial neighboring blocks are not outside the current CTU row. iv. The reference index of the parameter list 0 is the same as the reference index of the spatial neighboring block; v. The reference index of the set of parameter list 1 is the same as the reference index of the spatial neighboring block; vi. The reference index of List 0 of the set of parameters is equal to the reference index of List 0 signaled by AMVP. vii. The reference index of parameter group list 1 is equal to the AMVP signal reference index of list 1. viii. The reference index of List 0 of the spatial neighboring block is equal to the reference index signaled by the AMVP of List 0. ix. The reference index of List 1 of the spatial neighboring blocks is equal to the reference index signaled by AMVP of List 1. x. The POC of the reference picture of list 0 of the set of parameters is the same as the POC of one of the reference pictures of the spatial neighboring block. xi. The POC of the reference picture of List 1 of the set of parameters is the same as the POC of one of the reference pictures of the spatial neighboring block. xii. The POC of the reference picture signaled by AMVP of List 0 is the same as the POC of one of the reference pictures of the spatial neighboring block. xiii. The POC of the reference picture signaled by AMVP of List 0 is the same as the POC of one of the reference pictures of the set of parameters. c. In one example, if a neighboring block has been used to derive an inherited affine AMVP candidate, it is skipped in the second loop and not used to derive an affine AMVP candidate with stored affine parameters. d. In one example, if a neighboring block has been used to derive an affine AMVP candidate with a set of stored affine parameters, it is skipped in the second loop and not used to derive an affine AMVP candidate with another set of stored affine parameters. Parameters. e. In one example, if a neighboring block is used to derive an affine AMVP candidate, all other neighboring blocks after the neighboring block are skipped, and the second loop is interrupted and returns to the first loop. The set of next parameters is accessed in the first loop. 25. Affine AMVP candidates derived from the parameters stored in the buffer and one or more time unit blocks may be placed into an affine AMVP candidate list. a. In one example, these candidates are placed after the inherited affine AMVP candidates. b. In one example, these candidates are placed after the first constructed AMVP merge candidate. c. In one example, these candidates are placed after the first affine AMVP candidates constructed from spatially neighboring blocks. d. In one example, these candidates are placed after all constructed affine AMVP candidates. e. In one example, these candidates are placed after the first translation affine AMVP candidate. f. In one example, these candidates are placed after all translational affine AMVP candidates. g. In one example, these candidates are placed before all zero-affine AMVP candidates. h. In one example, these candidates are placed after all affine AMVP candidates derived from parameters stored in the buffer and spatial neighboring cell blocks. i. In one example, at most N affine AMVP candidates and temporal neighboring unit blocks derived from the parameters stored in the buffer can be put into the affine merge candidate list. N is an integer, such as 1. j. In one example, the affine AMVP candidates derived from the parameters stored in the buffer block and the temporal neighboring blocks are sequentially placed into the affine AMVP candidate list. i. For example, a two-level nested loop method is used to search for available affine AMVP candidates derived from parameters stored in the buffer block and the temporal neighboring blocks, and put them into the affine AMVP candidate list. (a) In the first level loop, each set of parameters stored in the buffer is accessed sequentially. They can be accessed from the beginning to the end of the table, or from the end to the beginning of the table, or in any other predefined or adaptive order. a. In the example, some parameter groups stored in the buffer are skipped in the first cycle. For example, the first N groups or the last N groups in the table are skipped. In fact, if k%S==0, H[k]s is skipped. In fact, if k%S!=0, H[k]s is skipped. (b) For each set of parameters stored in the buffer, a second level loop is applied. In the second-level loop, each temporally adjacent block is accessed sequentially. For example, Fig. 9 Blocks A1, B1, B0, A0, B2 are shown. In a pseudo-codec implementation, the nested loop can be described as: a. In one example, the second loop may include only one temporally adjacent block, for example, only A1. b. Using the set of parameters given in the first-level loop and the temporal neighboring blocks given in the second-level loop, if all or part of the following conditions are met, an affine AMVP candidate is generated and placed in the affine AMVP candidate list. i. Time-adjacent blocks are available; ii. The temporal neighboring blocks are inter-coded; iii. The temporal neighboring blocks are not outside the current CTU row. iv. The reference index of list 0 of the set of parameters is the same as the reference index of the temporal neighboring block; v. The reference index of list 1 of the set of parameters is the same as the reference index of the temporal neighboring block; vi. The reference index of List 0 of the set of parameters is equal to the reference index of List 0 signaled by AMVP. vii. The reference index of parameter group list 1 is equal to the AMVP signal reference index of list 1. viii. The reference index of List 0 of the temporal neighboring block is equal to the reference index signaled by the AMVP of List 0. ix. The reference index of List 1 of the temporal neighboring blocks is equal to the reference index signaled by the AMVP of List 1. x. The POC of the reference picture of list 0 of this set of parameters is the same as the POC of one of the reference pictures of the temporally neighboring block. xi. The POC of the reference picture of List 1 of the set of parameters is the same as the POC of one of the reference pictures of the temporally neighboring block. xii. The POC of the reference picture signaled by AMVP of List 0 is the same as the POC of one of the reference pictures of the temporally neighboring block. xiii. The POC of the reference picture signaled by AMVP of List 0 is the same as the POC of one of the reference pictures of the set of parameters. c. In one example, if a neighboring block has been used to derive an inherited affine AMVP candidate, it is skipped in the second loop and not used to derive an affine AMVP candidate with stored affine parameters. d. In one example, if a neighboring block has been used to derive an affine AMVP candidate with a set of stored affine parameters, it is skipped in the second loop and not used to derive an affine AMVP candidate with another set of stored affine parameters. Parameters. e. In one example, if a neighboring block is used to derive an affine AMVP candidate, all other neighboring blocks after the neighboring block are skipped, and the second loop is interrupted and returns to the first loop. The set of the following parameters is accessed in the first loop. 26. It is recommended to use the affine merge candidate buffer derived from the affine HMVP, put it into the affine merge list / sub-block merge list, and the inherited affine merge candidate can be deleted from the list. a. In one example, affine merge candidates derived from the affine HMVP buffer are put into an affine merge list / sub-block merge list, and inherited affine merge candidates are excluded from the list. b. In an alternative example, affine merge candidates derived from the affine HMVP buffer are put into the affine merge list / sub-block merge list, and affine merge candidates inherited from blocks in the current CTU row are removed from the list. i. For example, affine merge candidates derived from the affine HMVP buffer are put into the affine merge list / sub-block merge list after affine merge candidates inherited from blocks in a CTU row different from the current CTU row. c. Prototypically, whether to add inherited affine merge candidates may depend on the affine HMVP buffer. i. In one example, an affine merge candidate derived from an affine HMVP buffer may be inserted before the inherited affine merge candidate in the candidate list. ii. In one example, when the affine HMVP buffer is empty, the inherited affine merge candidate may be added; otherwise (if the affine HMVP buffer is not empty), the inherited affine merge candidate may be excluded. d. Entrepreneurially, whether to apply the proposed method may depend on the block size. 27. It is recommended to use the affine AMVP candidate buffer derived from the affine HMVP, put it into the affine AMVP list, and the inherited affine AMVP candidate can be deleted from the list. a. In one example, affine AMVP candidates derived from an affine HMVP buffer are put into an affine AMVP list, and inherited affine AMVP candidates are excluded from the list. b. In an alternative example, affine AMVP candidates derived from those stored in the affine HMVP buffer are placed into the affine AMVP list, and affine AMVP candidates inherited from blocks in the current CTU row are removed from the list. i. For example, affine AMVP candidates derived from an affine HMVP buffer are placed in an affine AMVP list after affine AMVP candidates inherited from blocks in a CTU row different from the current CTU row. c. Prototypically, whether to add an inherited affine AMVP candidate may depend on the affine HMVP buffer. d. Entrepreneurially, whether to apply the proposed method may depend on the block size. 28. In one example, if an affine merge candidate derived from the parameters stored in the buffer can be put into the list, the size of the affine merge candidate list is increased by N (eg, N=1). 29. In one example, if an affine AMVP candidate derived from the parameters stored in the buffer can be put into the list, the size of the affine AMVP candidate list is increased by N (eg, N=1). 30. The virtual affine model can be derived from multiple existing affine models stored in the buffer. Assume that the buffer contains multiple affine models, the i-th candidate is denoted as Candi, and the parameters are (ai, bi, ci, di, ei, fi). a. In one example, the parameters of Candi and Candj can be combined to form a virtual affine model by taking some parameters from Candi] and the remaining parameters from Candj. An example of a virtual affine model is (ai,bi,cj,dj,ei,fi). b. In one example, the parameters Candi and Candj can be used jointly to generate a virtual affine model with a function such as an average. An example of a virtual affine model is ((ai+aj) / 2,(bi+bj) / 2,(ci+cj) / 2,(di+dj) / 2,(ei+ej) / 2,(fi+fj) / 2). c. The virtual affine model can be used in a similar manner to the stored affine model, for example using the bullet points mentioned above. 31. It is proposed to not put the affine merge candidates inherited from spatial neighboring blocks into the sub-block based merge candidate list, and to put the disclosed history-based affine merge candidates into the sub-block based merge candidate list. a. In one example, the disclosed history-based affine merge candidate is placed in the sub-block based merge candidate list immediately after the ATMVP candidate. b. In one example, the disclosed history-based affine merge candidates are put into the sub-block based merge candidate list before the constructed affine merge candidates. c. It is proposed that whether the affine merging candidates inherited from the spatial neighboring blocks are put into the sub-block based merging candidate list may depend on the positions of the spatial neighboring blocks. i. In one example, if the spatial neighboring block is in the same CTU or CTU row as the current block, the affine merge candidate inherited from the spatial neighboring block is put into the sub-block based merge candidate list. Otherwise, it is not put into the list. ii. If the spatial neighboring block is not in the same CTU or CTU row as the current block, the affine merge candidate inherited from the spatial neighboring block is put into the sub-block based merge candidate list; otherwise, it is not put into the list. 32. It is proposed to not put the affine AMVP candidates inherited from spatial neighboring blocks into the affine MVP candidate list, and put the disclosed history-based affine MVP candidates into the affine MVP candidate list. a. In one example, the disclosed history-based affine MVP candidates are first put into an affine MVP candidate list. b. Proposing Affine AMVP candidates inherited from spatially neighboring blocks Whether to be put into the affine MVP candidate list may depend on the positions of the spatially neighboring blocks. i. In one example, if the spatial neighboring block is in the same CTU or CTU row as the current block, the affine AMVP candidate inherited from the spatial neighboring block is put into the affine MVP candidate list. Otherwise, it is not put into the list. First, if the spatial neighboring block is not in the same CTU or CTU row as the current block, the affine AMVP candidate inherited from the spatial neighboring block is put into the affine MVP candidate list; otherwise, it is not put into the list. 33. Multiple affine HMVP buffers are used to store different categories of affine parameters or CPMVs. a. For example, two buffers are used to store the affine parameters in reference list 0 and reference list 1 respectively. i. In one example, after decoding an affine coded CU, the CPMV or parameters of reference list 0 are used to update the HMVP buffer of reference list 0. ii. In one example, after decoding the affine coded CU, the CPMV or parameters of reference list 1 are used to update the HMVP buffer of reference list 1. iii. In one example, if the motion information of spatially adjacent / discontinuous M×N unit blocks (e.g., 4×4 blocks in VTM) and a set of affine parameters stored in a buffer are used together, the following affine model can be derived: for the current block, the MV of the spatially adjacent / discontinuous unit blocks of reference list X is combined with the affine parameters stored in the buffer of reference list X. X=0 or 1. iv. In one example, if the motion information of a temporally neighboring M×N unit block (e.g., a 4×4 block in a VTM) and a set of affine parameters stored in a buffer are used together to derive an affine model of the current block, the MV of the temporally neighboring unit block of reference list X is combined with the affine parameters stored in the buffer of reference list X. X=0 or 1. b. For example, N (eg, N=6) buffers are used to store affine parameters that refer to different reference indices in different reference lists. In the following discussion, "reference K" means that the reference index of the reference picture is K. i. In one example, after decoding an affine coded CU, the CPMV or parameters of reference K in list X are used to update the HMVP buffer of reference K in list X. X=0 or 1. K can be 0, 1, 2, etc. ii. In one example, after decoding the affine encoded CU, the CPMV or parameters of reference K (where K>=L) in list X are used to update the HMVP buffer of reference L in list X. X=0 or 1. M can be 1, 2, 3, etc. iii. In one example, if the motion information of spatially adjacent / discontinuous M×N unit blocks (e.g., 4×4 blocks in VTM) and the set of affine parameters stored in the buffer are used together, the following affine model can be derived: current block, MV of spatially adjacent / discontinuous unit blocks of reference K in reference list X is combined with affine parameters stored in the buffer of reference K in reference list X. X=0 or 1. K can be 0, 1, 2, etc. iv. In one example, if the motion information of a temporally neighboring M×N unit block (e.g., a 4×4 block in a VTM) and a set of affine parameters stored in a buffer are used together to derive an affine model of the current block, the MV of the temporally neighboring unit block of reference K in reference list X is combined with the affine parameters in the buffer of reference K stored in reference list X. X=0 or 1. K can be 0, 1, 2, etc. v. In one example, if the motion information of spatially adjacent / discontinuous M×N unit blocks (e.g., 4×4 blocks in VTM) and the set of affine parameters stored in the buffer are used together, the following affine model can be derived: for the current block, the MV of the spatially adjacent / discontinuous unit blocks of reference K in list X is combined with the affine parameters stored in the buffer of reference L in reference list X. X=0 or 1. L can be 1, 2, 3, etc. vi. In one example, if the motion information of a temporally neighboring M×N unit block (e.g., a 4×4 block in a VTM) and a set of affine parameters stored in a buffer are used together to derive an affine model of the current block, the MV of the temporally neighboring unit block of reference K (where K>=L) in list X is combined with the affine parameters in the buffer of reference L stored in reference list X. X=0 or 1. L can be 1, 2, 3, etc. c. The size of the affine HMVP buffer for each class may be different. i. In one example, the size may depend on the reference picture index. For example, the size of the affine HMVP buffer of reference 0 is 3, the size of the affine HMVP buffer of reference 1 is 2, and the size of the affine HMVP buffer of reference 2 is 1. 34. Whether and / or how to update the affine HMVP buffer may depend on the codec mode and / or other codec information of the current CU. a. For example, if a CU is encoded and decoded in affine merge mode, and the merge candidate is derived from the affine HMVP buffer, the HMVP buffer is not updated after decoding the CU. i. Update the affine HMVP buffer by deleting the associated affine parameters of the last entry of the affine HMVP buffer. b. In one example, the affine HMVP buffer may be updated each time a block is encoded and decoded in affine mode. c. In one example, when a block is encoded in affine merge mode and the block uses a shared merge list, the update of the affine HMVP buffer is skipped. 35. In one example, the affine HMVP buffer can be divided into M (M>1) sub-buffers: HB 0 HB 1 ,...HB M-1 . a. On the surface, multiple affine HMVP buffers (ie, multiple affine HMVP tables) can be allocated, and each affine HMVP buffer can correspond to one of the above-mentioned sub-buffers HB i . b. In one example, an operation on one sub-buffer (eg, an update process of a sub-buffer, use of a sub-buffer) may not affect other sub-buffers. c. In one example, M is predefined, such as 10. d. In one example, the first M0 buffers are associated with storage of affine parameters of reference picture list X, and the remaining (M-M0) buffers are associated with storage of affine parameters of reference picture list Y, where Y=1-X and X is 0 or 1. i. Newly, the affine parameters of reference picture list X can be stored in an interleaved manner with the affine parameters of reference picture list Y. ii. In one example, the affine parameters of the reference picture list X can be stored in HB i Where i is an odd number, and the affine parameters of the reference picture list X can be stored in HB j Where i is an odd number and j is an even number. e. In one example, the signal M can be sent from the encoder to the decoder, for example, at the video level (e.g., VPS), sequence level (e.g., SPS), picture level (e.g., PPS or picture header), slice level (e.g., slice header), and tile group level (e.g., tile group header). f. In one example, M may depend on the number of reference pictures. i. For example, M may depend on the number of reference pictures in reference list 0; ii. For example, M may depend on the number of reference pictures in reference list 1; g. In one example, each sub-buffer may have the same maximum number of allowed entries, denoted as N. For example, N=1 or N=2; h. In one example, each sub-buffer may have a different number of maximum allowed entries. For example, sub-buffer HB K There can be at most N K The number of entries allowed. For different K, N K May be different. i. When using a set of affine parameters to update the HMVP buffer, a sub-buffer with a sub-buffer index SI can be selected, and then the set of affine parameters can be used to update the corresponding sub-buffer HB SI . i. In one example, the selection of the sub-buffer may be based on the encoded information of the block to which the set of affine parameters is applied. (a) In one example, the decoded information may include a reference list index (or prediction direction) and / or a reference index associated with an affine parameter set. (b) For example, assuming that the reference list index and the reference index of the affine parameter set are represented as X (eg, X is 0 or 1) and RIDX, the selected sub-buffer index SI may be calculated as SI=f(X, RIDX), where f is a function. a. In one example, SI=X*MaxR0+min(RIDX,MaxRX-1), where MaxR0 and MaxR1 are integers, for example, MaxR0=MaxR1=5. b. Simply put, SI = 2*min(RIDX,MaxRX-1)+X. c. In one example, X can only be 0 or 1, and RIDX must be greater than or equal to 0. d. In one example, MaxR0 and MaxR1 may be different. e. In one example, MaxR0 / MaxR1 may depend on the temporal layer index, slice / tile group / picture type, low latency check flag, etc. f. In one example, MaxR0 may depend on the total number of reference pictures in reference list 0. g. In one example, MaxR1 may depend on the total number of reference pictures in reference list 1. h. In one example, MaxR0 and / or MaxR1 can be, for example, at a video level (e.g., VPS), a sequence level (e.g., SPS), a picture level (e.g., PPS or picture header), a slice level (e.g., slice header), or a tile group level (e.g., tile group header). j. When using a set of affine parameters to update the subbuffer HB SI When , it can be regarded as updating the regular affine HMVP buffer, and the method for updating the affine HMVP buffer disclosed in this article can be applied to update the one-point buffer. k. Spatially or temporally adjacent or non-adjacent neighboring blocks (also referred to as "neighboring blocks" for simplicity) may be used in combination with a set of one or more affine parameters stored in one or more HMVP affine sub-buffers. 36. In one example, the maximum allowed size of an affine HMVP buffer and / or an affine HMVP sub-buffer may be equal to 1. a. In one example, there is no need to keep a counter to record the number of affine parameter groups stored in the affine HMVP buffer or the affine HMVP sub-buffer. 37. Whether and / or how to operate on an affine HMVP buffer or an affine HMVP sub-buffer may depend on whether the set of affine parameters is all zero. a. In one example, when an affine HMVP buffer or an affine HMVP sub-buffer is flushed, all affine parameters stored in the buffer or sub-buffer are set to zero. i. The affine HMVP buffer or the affine HMVP subbuffer may be flushed before encoding / decoding each picture and / or slice and / or tile group and / or CTU row and / or CTU and / or CU. b. In one example, when a set of affine parameters is used to update an affine HMVP buffer or an affine HMVP sub-buffer, if all affine parameters in the set are equal to 0, the buffer or sub-buffer is not updated. c. In one example, when parameters of a set of affine parameters stored in an affine HMVP buffer or an affine HMVP sub-buffer are all zero, the set of affine parameters cannot be used to generate an affine merge candidate or an affine AMVP candidate. i. For example, an affine parameter set cannot be used to combine with neighboring blocks to generate an affine merge candidate or an affine AMVP candidate. ii. For example, when all parameters of a set of affine parameters stored in an entry of an affine HMVP buffer or an affine HMVP sub-buffer are zero, the entry is marked as “invalid” or “unavailable”. iii. For example, when the parameters of the affine parameter group stored in all entries of the affine HMVP buffer or affine HMVP sub-buffer are zero, the affine HMVP buffer or affine HMVP sub-buffer is marked as "invalid" or "unavailable", and / or the counter of the buffer or sub-buffer is set to zero. 38. When generating affine merge candidates by combining affine parameters stored in the affine HMVP buffer using spatially or temporally continuous or non-contiguous neighboring blocks (also referred to as "neighboring blocks" for simplicity), only the affine can access the parameters stored in one or more relevant sub-buffers. a. For example, the relevant sub-buffer may be determined by the codec information of the neighboring block. For example, the codec information may include a reference list and / or a reference index of the neighboring block. b. For example, a set of one or more affine parameters stored in the relevant sub-buffer may be used to combine with neighboring blocks to generate an affine merge candidate. i. For example, the affine parameter set stored as the first entry in the relevant sub-buffer may be used. ii. For example, the affine parameter set stored as the last entry in the relevant sub-buffer may be used. c. For example, refer to reference list 0 to determine a related sub-buffer HB for the MV of the adjacent block S0 . d. For example, refer to reference list 1 to determine a related sub-buffer HB for the MV of the adjacent block S1 . i.HB S0 and HB S1 May be different. e. For the MV of the neighboring block with reference index RIDX in the reference list LX, the related sub-buffer index SI is calculated as SI=g(LX, RIDX), where g is a function. i. For example, function g is the same as function f in bullet 35.d. ii. In one example, SI=LX*MaxR0+min(RIDX,MaxRX-1), where MaxR0 and MaxR1 are integers, for example, MaxR0=MaxR1=5. (a) In one example, LX can only be 0 or 1, and RIDX must be greater than or equal to 0. (b) MaxR0 and MaxR1 may be different. (c) MaxR0 may depend on the total number of reference pictures in reference list 0. (d) MaxR1 may depend on the total number of reference pictures in reference list 1. (e) MaxR0 and / or MaxR1 can be signaled from the encoder to the decoder, for example, at the video level (e.g., VPS), sequence level (e.g., SPS), picture level (e.g., PPS or picture header), slice level (e.g., slice header), tile group level (e.g., tile group header). f. In one example, when a neighboring block is an inter-frame coded with unidirectional prediction, and refers to a reference picture with a reference index RIDX in a reference list LX, then a set of affine parameters stored in a related affine HMVP sub-buffer can be combined from the neighboring block if there is at least one available entry in the sub-buffer and / or the counter of the sub-buffer is not equal to 0. i. The generated affine merge candidate should also be uni-predicted, referring to the reference picture with reference index RIDX in the reference list LX. g. In one example, when a neighboring block is inter-coded and the inter-prediction references a reference picture having a reference index RIDX0 in reference list 0 and a reference index RIDX1 in reference list 1, an affine merge candidate may be generated from a combination of the neighboring block and a set of one or more affine parameters stored in one or more associated affine HMVP sub-buffers. i. In one example, the generated affine merge candidate should also be bi-directionally predicted, referring to the reference picture with reference index RID0 in reference list 0 and reference index RID1 in reference list 1. (a) A bi-predictive affine merge candidate may be generated only if at least one entry associated with reference index RID0 in reference list 0 is available in the sub-buffer (and / or the counter of the sub-buffer is not equal to 0), and at least one entry associated with reference index RID1 in reference list 1 is available in the sub-buffer (and / or the counter of the sub-buffer is not equal to 0). (b) In one example, if the following conditions cannot be satisfied, an affine merging candidate cannot be generated from neighboring blocks combined with affine parameters stored in the affine HMVP buffer and / or sub-buffer. a. There is at least one available entry in the sub-buffer associated with reference index RID0 in reference list 0 (and / or the counter of the sub-buffer is not equal to 0), and there is at least one available entry in the sub-buffer - the buffer associated with reference index RID1 in reference list 1 (and / or the counter of the sub-buffer is not equal to 0). ii. In an alternative example, the generated affine merge candidate may also be uni-predicted, referring to the reference picture with reference index RID0 in reference list 0, or the reference picture with reference index RID1 in reference list 1. (a) If there is at least one available entry in the sub-buffer associated with reference index RID0 in reference list 0 (and / or the counter of the sub-buffer is not equal to 0), and there is no available entry in the sub-buffer associated with reference index RID1 in reference list 1 (and / or the counter of the sub-buffer is equal to 0). (b) If there is at least one available entry in the sub-buffer associated with reference index RID1 in reference list 1 (and / or the counter of the sub-buffer is not equal to 0), and there is no available entry in the sub-buffer associated with reference index RID0 in reference list 0 (and / or the counter of the sub-buffer is equal to 0). h. In one example, all methods disclosed in this document can be used to generate affine merge candidates by combining affine parameters stored in one or more related sub-buffers. 39. When generating affine AMVP candidates by combining affine parameters stored in an affine HMVP buffer using spatially or temporally continuous or non-continuous neighboring blocks (also referred to as "neighboring blocks" for simplicity), only the affine can access the parameters stored in one or more relevant sub-buffers. a. For example, the relevant sub-buffer may be determined by the codec information of the neighboring block. For example, the codec information may include a reference list and / or a reference index of the neighboring block. b. For example, a set of one or more affine parameters stored in the relevant sub-buffer may be used in conjunction with neighboring blocks to generate an affine AMVP candidate. i. For example, the affine parameter set stored as the first entry in the relevant sub-buffer may be used. ii. For example, the affine parameter set stored as the last entry in the relevant sub-buffer may be used. c. For a target reference picture with a target reference index RIDX in the target reference list LX, the associated sub-buffer index SI is calculated as SI = h(LX, RIDX), where g is a function. i. For example, function g is the same as function f in bullet 35.d. ii. For example, function g is the same as function g in item 38. iii. In one example, SI=LX*MaxR0+min(RIDX,MaxRX-1), where MaxR0 and MaxR1 are integers, for example, MaxR0=MaxR1=5. (a) In one example, LX can only be 0 or 1, and RIDX must be greater than or equal to 0. (b) MaxR0 and MaxR1 may be different. (c) MaxR0 may depend on the total number of reference pictures in reference list 0. (d) MaxR1 may depend on the total number of reference pictures in reference list 1. (e) MaxR0 and / or MaxR1 can be signaled from the encoder to the decoder, for example, at the video level (e.g., VPS), sequence level (e.g., SPS), picture level (e.g., PPS or picture header), slice level (e.g., slice header), tile group level (e.g., tile group header). d. In one example, if there is no available entry in the sub-buffer associated with the target reference index RIDX in the target reference list LX, an affine AMVP candidate cannot be generated from the affine parameters stored in the affine HMVP buffer / sub-buffer (and / or the counter of the sub-buffer is equal to 0). e. In one example, when the neighboring block is inter-coded and has an MV that refers to the target reference index RIDX in the target reference list LX, then the MV is used to generate an affine AMVP candidate in conjunction with the stored affine parameters. f. In one example, when the neighboring block is inter-coded and does not have an MV that refers to the target reference index RIDX in the target reference list LX, then an affine AMVP candidate cannot be generated from the neighboring block. i. First, when a neighboring block is inter-frame encoded and there is no MV with a target reference index RIDX in the target reference list LX, the neighboring block is checked to determine whether it has a second MV referencing a second reference picture in the reference list 1-LX, which has the same POC as the target reference picture. (a) If there is a second MV that references a second reference picture in reference list 1-LX, and the second reference has the same POC as the target reference picture, then the second MV is used in combination with the stored affine parameters to generate the relevant sub-buffer in the affine AMVP candidate. Otherwise, the affine AMVP candidate cannot be generated from the neighboring blocks. g. In one example, all methods disclosed in this document can be applied to generate affine merge / AMVP candidates by combining affine parameters stored in one or more related sub-buffers. 40. If the neighboring block is encoded and decoded by intra block copy (IBC) mode, the neighboring block cannot be used in combination with the affine parameters stored in the affine HMVP buffer or the affine HMVP sub-buffer to generate an affine merge / AMVP candidate. 41. If the spatial neighboring blocks are used to generate inherited merge / AMVP candidates, the spatial neighboring blocks cannot be combined with the affine parameters stored in the affine HMVP buffer / sub-buffer to generate the affine merge / AMVP candidates. 42. Spatially and / or temporally adjacent / non-contiguous blocks may be divided into K groups (e.g., K=2) and how the parameters in the affine HMVP buffer / sub-buffer are combined with the motion information of spatially and / or temporally adjacent / non-adjacent blocks for encoding and decoding the current block may be group-based. a. Affine merge candidates generated by combining the affine parameters stored in the affine HMVP buffer / sub-buffer with spatially adjacent blocks in different groups can be placed in different positions in the affine merge candidate list; b. Affine AMVP candidates generated by combining the affine parameters stored in the affine HMVP buffer / sub-buffer with spatially adjacent blocks in different groups can be placed in different positions in the affine AMVP candidate list; c. In one example, spatially neighboring blocks may be divided into groups based on their coded information. i. For example, neighboring blocks may be put into a specific group based on whether they are affine encoded or not. ii. For example, neighboring blocks may be put into a specific group based on whether they are affine coded and have AMVP mode. iii. For example, neighboring blocks may be put into a specific group based on whether they are affine coded and have merge mode. d. In one example, spatially neighboring blocks can be divided into groups based on their locations. e. In one example, not all neighboring blocks are put into K groups. f. In one example, spatially neighboring blocks are divided into two groups as follows: i. The first encountered affine encoded left neighboring block can be put into group X. (a) Check the left adjacent blocks in order, such as block A0 and block A1. Figure 8 shown. (b) In one example, if the first encountered affine-encoded left-neighboring block is used to generate a succession merge / AMVP candidate, it is not put into group X. ii. Put the first encountered affine encoded and decoded block of the above adjacent blocks into group X. (a) Check the above adjacent blocks in order. For example, block B0, block B1 and block B2 are as follows: Figure 8 shown. (b) In one example, if the first encountered inter-coded and affine-coded neighboring block is used to generate the inherited merge / AMVP candidate, it is not put into group X. iii. Other inter-frame coded neighboring blocks can be put into group Y, where Y is not equal to X. g. In one example, the affine merge candidate generated based on the affine parameters stored in the affine HMVP buffer / sub-buffer in combination with the spatially adjacent blocks in group X can be placed before the Kth constructed affine merge candidate in the affine merge candidate list. For example, K can be 1 or 2. h. In one example, the affine merge candidate generated from the affine parameters stored in the affine HMVP buffer / sub-buffer combined with the spatially adjacent blocks in group Y can be placed after the Kth constructed affine merge candidate in the affine merge candidate list. For example, K can be 1 or 2. i. In one example, the affine AMVP candidate generated from the affine parameters stored in the affine HMVP buffer / sub-buffer combined with the spatially adjacent blocks in group X can be placed before the Kth constructed affine merged candidate in the affine AMVP candidate list. For example, K can be 1 or 2. j. In one example, the affine AMVP candidate generated from the affine parameters stored in the affine HMVP buffer / sub-buffer combined with the spatially adjacent blocks in group Y can be put into the affine AMVP candidate list after the Kth constructed affine merge candidate. For example, K can be 1 or 2. k. In one example, the affine AMVP candidate generated from the affine parameters stored in the affine HMVP buffer / sub-buffer in combination with the spatially neighboring blocks in group X may be placed before the zero candidate in the affine AMVP candidate list. 43. The basic position (xm, ym) in bullet point 20 can be any position within a basic neighboring block (e.g., a 4×4 basic block), such as Fig.21 As shown, it shows the position in the 4X4 basic block. a. For example, (xm, ym) can be Fig.21 P22 in. b. Assume that the sample coordinates of the upper left corner of the current block are (xPos00, yPos00), the sample coordinates of the upper right corner of the current block are (xPos10, yPos00), and the sample coordinates of the upper right corner of the current block are (xPos00, yPos01), then Figure 8 middle: i.(xm,ym) is (xPos00-2,yPos01-1) for the adjacent basic block A1; ii. (xm, ym) is (xPos00-2, yPos01+3) for the adjacent basic block A0; iii. (xm, ym) is (xPos10-1, yPos00-2) for the adjacent basic block B1; iv.(xm,ym) is (xPos10+3,yPos00-2) for the adjacent basic block B0; v. The (xm, ym) of the adjacent basic block B2 is (xPos00-2, yPos00-2); 2.14 Derivation of non-affine motion based on affine motion 1. It is proposed to update the motion information of an affine coded block after motion compensation, and the updated motion information is stored and used for motion prediction of subsequent coded / decoded blocks. a. In one example, the updated motion information is used for motion prediction of subsequently encoded / decoded blocks in different pictures. b. In one example, a filtering process (eg, a deblocking filter) depends on updated motion information. c. The update process may be called under other conditions, for example, only for the right and / or bottom affine sub-blocks of a CTU. In this case, the filtering process may depend on the unupdated motion information, and the updated motion information may be used for subsequent coded / decoded blocks in the current slice / tile or other pictures. 2. In one example, the MV stored in a sub-block located at the right boundary and / or the bottom boundary may be different from the MV used in the MC of the sub-block. Fig. 22 An example is shown in which sub-blocks located at the right and lower boundaries are shaded. a. In one example, the MV stored in the sub-block located at the right boundary and / or the bottom boundary can be used as the MV prediction or candidate for the subsequent encoded / decoded block in the current frame or a different frame. b. In one example, the MV stored in the sub-block located at the right boundary and / or the lower boundary may be derived through an affine model having representative points outside the sub-block. c. In one example, two sets of MVs are stored for the right boundary and / or the bottom boundary, one set of MVs is used for deblocking and temporal motion prediction, and the other set is used for motion prediction of subsequent PU / CU in the current picture. 3. Assume that the coordinates of the upper left corner of the current block are (x0, y0), the coordinates of the upper left corner of the sub-block are (x', y'), the size of the sub-block is M×N, and the MV stored in the sub-block is recorded as (MVx, MVy). (MVx, MVy) is calculated by Eq(1) of the 4-parameter affine model or Eq(2) of the 6-parameter affine model, and the representative point (x, y) is set to (xp-x0, yp-y0)) and (xp, yp) can be defined as follows: a. If the sub-block is located at the right boundary, then xp=x'+M+M / 2, yp=y'+N / 2; Figure 23(a) depicts such an example. b. If the sub-block is located at the bottom boundary, then xp = x'+M / 2, yp = y'+N+N / 2, such an example is shown in FIG. 23(a); c. For the lower right corner, the representative point (x, y) can be defined as: i. For example, if the sub-block is located at the lower right corner, then xp = x'+M+M / 2, yp = y'+N / 2; ii. In one example, if the sub-block is located at the lower right corner, xp = x'+M / 2, yp = y'+N+N / 2; iii. In one example, if the sub-block is located at the lower right corner, xp = x'+M+M / 2, yp = y'+N+N / 2; d. If the sub-block is located at the right boundary, then xp = x'+M, yp = y'+N / 2; Figure 23(b) depicts such an example; e. If the sub-block is located at the bottom boundary, then xp = x'+M / 2, yp = y'+N; Figure 23(b) depicts such an example; f. If the sub-block is located at the lower right corner, then xp = x' + M, yp = y' + N. Figure 23(b) depicts such an example; g. If the sub-block is located at the right boundary or the bottom boundary, then xp = x'+M, yp = y'+N. Such an example is depicted in Figure 23(c); h. If the sub-block is located at the bottom boundary, then xp = x', yp = y' + N. Figure 23 (d) depicts such an example; i. If the sub-block is located at the right boundary, then xp = x'+M, yp = y'; Figure 23(d) depicts such an example; j. If the sub-block is located at the lower right corner, then xp = x' + M, yp = y' + N. Figure 23(d) depicts such an example. 4. In one example, when deriving its stored MV, some sub-blocks at the bottom boundary or the right boundary are abnormal. a. For the upper right corner (such as Figure 6 The block RT shown in Figure 1 always stores the MV in the upper right corner (e.g. Figure 6 mv1 shown). b. For the lower left corner (such as Figure 6 LB block shown), which always stores the MV in the lower left corner (such as Figure 6 mv2 shown). i. By the way, for the lower left corner, the MV is stored only when mv2 is a signaled MV. c. For the lower right corner (such as Figure 6 The block RB shown in the figure always stores the MV in the lower right corner (e.g. Figure 6 mv3 shown). 5. In one example, the MV prediction (may include one MV or two MVs for two inter prediction directions) of the current non-affine coded block may be derived from neighboring affine coded blocks based on an affine model. a. For example, when the current block is encoded and decoded in inter mode, MV prediction can be used as an MVP candidate in the MVP candidate list. b. For example, when the current block is encoded and decoded in merge mode, the MV prediction can be used as a merge candidate in the MVP candidate list. c. Assuming that the coordinates of the upper left corner of the adjacent affine coded block are (x0, y0), the CP MV of the adjacent affine coded block is (For the upper left corner) corner, For the upper right corner, is the lower right corner. The width and height of the adjacent affine encoded block are w and h. The coordinates of the upper left corner of the current block are (x', y'), and the coordinates of any point in the current block are (x", y"). The width and height of the current block are M and N. i. In one example, if the neighbors are affine, the MV prediction is calculated according to equation (1) as (mv h (x,y),mv v (x, y)), where x = x'-x0, y = y'-y0. The encoded and decoded blocks use a 4-parameter affine model; ii. In one example, if the neighbors are affine, then the MV prediction is calculated according to equation (2) as (mv h (x,y),mv v (x, y)), where x = x'-x0, y = y'-y0. The encoded and decoded blocks use a 6-parameter affine model; iii. Some possible positions of (x”, y”) are: (e.g. Fig.24 (shown) (a)(x',y') (b)(x'+M / 2,y') (c)(x'+M / 2+1,y') (d)(x'+M-1,y') (e)(x'+M,y') (f)(x',y'+N / 2) (g)(x'+M / 2,y'+N / 2) (h)(x'+M / 2+1, y'+N / 2) (i)(x'+M-1,y'+N / 2) (j)(x'+M, y'+N / 2) (k)(x',y'+N / 2+1) (l)(x'+M / 2,y'+N / 2+1) (m)(x'+M / 2+1, y'+N / 2+1) (n)(x'+M-1,y'+N / 2+1) (o)(x'+M, y'+N / 2+1) (p)(x',y'+N-1) (q)(x'+M / 2,y'+N-1) (r)(x'+M / 2+1,y'+N-1) (s)(x'+M-1,y'+N-1) (t)(x'+M, y'+N-1) (u)(x',y'+N) (v)(x'+M / 2, y'+N) (w)(x'+M / 2+1, y'+N) (x)(x'+M-1,y'+N) (y)(x'+M,y'+N) 6. If the adjacent basic unit block S (e.g., a 4×4 block in VVC) belongs to an affine coded block T (e.g., the basic unit block A0 in FIG. 7( b ) belongs to an affine coded block), the following method may be applied to obtain motion prediction candidates: a. In one example, when a basic unit block S is accessed by the MVP list construction process and / or the merge candidate list construction process, the MV stored in S is not retrieved. Instead, the derived MV prediction is obtained from the affine coded block T of the current block. b. In one example, the basic unit block S is accessed twice by the MVP list construction process and / or the merge candidate list construction process. In one access, the MV stored in S is retrieved. In another access, the MV prediction derived from the affine coded block T of the current block is obtained as an additional MVP candidate or merge candidate. 7. If the neighboring basic unit block S (e.g., a 4×4 block in VVC) belongs to the affine coded block T, then the additional MVP candidate or merge candidate T derived from the affine coded block of the current block can be added to the MVP candidate list or merge candidate list at the position: a. In one example, after taking a candidate from block S; b. In one example, before taking a candidate from block S; c. In one example, after all normal spatial candidates but before the temporal candidate; d. In one example, after the time candidate; e. In one example, the position can be adaptively changed from one block to another. 8. In one example, the total number of additional candidates derived from the affine encoded block cannot exceed a fixed number, such as 1 or 2. a. The apparently fixed number may further depend on coded information such as the size of the candidate list, the total number of available motion candidates before adding these additional candidates, block size, block type, coded mode (AMVP or merge), striping, etc. 9. In one example, additional candidates derived from the affine encoded block can be pruned along with other candidates. If a derived candidate is identical to another candidate already in the list, it will not be added to the list. a. In one example, if a neighboring basic unit block S (a 4×4 block in VVC) belongs to an affine-encoded block T, the additional candidates derived from the affine-encoded block T are combined with the MV obtained from S. b. In one example, the derived candidate is compared to other derived candidates. 10. In one example, whether and how to apply the MV prediction derived from the neighboring affine coded blocks for the current non-affine coded block may depend on the dimension of the current block (assuming the current block size is width×height). a. For example, if W>=T and H>=T, then not applicable, where T is an integer, such as 8; b. For example, if W>=T or H>=T, then not applicable, where T is an integer, such as 8; c. For example, if W <= T and H <= T, then not apply, where T is an integer, such as 8; d. For example, if W <= T or H <= T, then not applicable, where T is an integer, such as 8; General applications related to affine motion 11. Relative to the top pass samples of a sub-block of size equal to MxN, the selection of representative points can be shifted instead of always being equal to (M / 2, N / 2). a. In one example, the representative point may be set to ((M>>1)-0.5, (N>>1)-0.5). b. In one example, the performance point may be set to ((M>>1)-0.5, (N>>1)). c. In one example, the performance point may be set to ((M>>1), (N>>1)-0.5). d. In one example, the performance point may be set to ((M>>1)+0.5, (N>>1)). e. In one example, the performance point may be set to ((M>>1), (N>>1)+0.5). f. In one example, the representative point may be set to ((M>>1)+0.5, (N>>1)+0.5). g. In one example, when the coordinates of the upper left corner of the sub-block relative to the upper port sample of the current block are (xs, ys), the coordinates of the representative point are defined as (xs+1.5, ys+1.5). i. In one embodiment, rewrite equation (6) to derive the MV of the new representative point: ii. Similarly, additional offsets (0.5, 0.5) or (-0.5, -0.5) or (0, 0.5), or (0.5, 0), or (-0.5, 0), or (0, -0.5) may be added to those representative points. 12. It is recommended to align the stored motion information with the motion information used in motion compensation. a. In one example, Figure 3 The currently stored mvi is replaced by mvi', where i is (0, and / or 1, and / or 2, and / or 3). 13. It is recommended that motion candidates obtained from affine-encoded blocks (e.g., MVP candidates for AMVP mode, or merge candidates) should be used in a different way than those obtained from non-affine-encoded blocks. a. For example, the motion candidate taken from the affine coded block may not be placed in the motion candidate list or the merge candidate list; b. For example, the motion candidate taken from the affine-encoded block may be placed in a motion candidate list or a merge candidate list with a lower priority, for example, it should be placed at a later position. c. The order of merging candidates can be adaptively changed based on whether the motion candidates are obtained from affine-encoded blocks. 14. The affine MVP candidate list size or the affine merge candidate list size for the affine encoded block may be adaptive. a. In one example, the affine MVP candidate list size or the affine merge candidate list size of the affine encoded block may be adaptive based on the size of the current block. i. For example, if the block is larger, the affine MVP candidate list size or the affine merge candidate list size of the affine encoded block may be larger. b. In one example, the affine MVP candidate list size or the affine merge candidate list size of an affine coded block may be adapted based on the coding mode of spatial or temporal neighboring blocks. For example, if more spatially neighboring blocks are affine-coded, the affine MVP candidate list size or the affine merge candidate list size of the affine-coded blocks may be larger. 3. Question It is still unclear how to use the stored affine parameters to derive affine / non-affine merge / AMVP candidates. 4. Embodiments of the present disclosure In this paper, it proposes methods to control the bandwidth required for affine prediction in a more flexible way. It also proposes to coordinate affine prediction with other codec tools. The following detailed embodiments should be considered as examples for explaining the general concept. These embodiments should not be interpreted narrowly. In addition, these embodiments can be combined in any way. The combination between this disclosure and other disclosures is also applicable. In the following discussion, it is assumed that the coordinates of the upper left / upper right / lower left / lower right corners of the neighboring blocks of the current block (e.g., the neighboring CU above or on the left) are (LTNx, LTNy) / (RTNx, RTNy) / (LBNx, LBNy) / (RBNx, RBNy), respectively; the coordinates of the upper left / upper right / lower left / lower right corners of the current CU are (LTCx, LTCy) / (RTCx, RTCy) / (LBCx, LBCy) / (RBCx, RBCy)), respectively; the affine-decoded width and height of the neighboring CU above or on the left are w' and h', respectively; and the affine-decoded width and height of the current CU are w and h, respectively. The CPMVs of the upper left corner, upper right corner, and lower left corner are expressed as MV0=(MV0x, MV0y), MV1=(MV1x, MV1y), and MV2=(MV2x, MV2y), respectively. In the following discussion, SignShift(x,n) can be defined as In one example, offset0 and offset1 are set to (1<<(n-1)). In another example, they are set to 0. The shift can be defined as Shift(x,n)=(x+offset)>>n, In one example, the offset is set to (1<<(n-1)). In another example, it is set to 0. Clip3(min,max,x) can be defined as It should also be noted that the term "affine merge candidate list" may be renamed (e.g., "sub-block merge candidate list") when other types of sub-block merge candidates such as ATMVP candidates are also put into a list or otherwise. A merge list may include at least one affine merge candidate. The proposed method can also be applied to other types of motion candidate lists, such as affine AMVP candidate lists. As described in Section 2.14, the MV predictor derived using the affine model from neighboring blocks can be named as Neighboring Affine Derived (NAD) candidate. 1. In one example, an MV predictor (which may include one MV or two MVs for two inter-prediction directions) may be derived for a current non-affine-encoded block from a history-based affine parameter table / list or other method of storing affine parameters from previously-encoded blocks. Such an MV predictor may be referred to as a candidate for historical affine derivation (HAD). a. For example, when the current block is encoded in the translational inter mode, the MV predictor can be used as the MVP candidate in the MVP candidate list. i. Alternatively, furthermore, the MV predictor may also be applicable to some inter modes but not to others, e.g. it may be applicable to inter modes for which no prediction is assumed. ii. In addition, the MV predictor can be used to derive additional hypotheses based on AMVP for the multiple hypothesis prediction mode. b. For example, when the current block is encoded and decoded in merge mode, the MV predictor can be used as a merge candidate in the MVP candidate list. i. Alternatively, furthermore, the MV predictor may also be applicable to certain merge modes but not to others, e.g., it may be applicable to regular merge mode but not to MMVD / CIIP. ii. Alternatively, in addition, one piece of motion information of the MV predictor (eg L0-MV or L1-MV, but not both) may be applicable to a certain merge mode, for example, it may be applicable to the GPM mode and its variants. iii. In addition, the MV predictor can be used to derive additional merging-based hypotheses for multiple hypothesis prediction modes. c. Inter-coded neighboring blocks, which may be unit blocks, may be used to derive the MV predictor. i. Assume that the coordinates of the position of the neighboring block (e.g., the upper left corner or the center) are (x0, y0). The coordinates of the upper left corner of the current block are (x', y'), and the coordinates of any point in the current block are (x", y"). The width and height of the current block are M and N. (a) In one example, the MV predictor uses a 4-parameter affine model obtained from a history-based affine table and is calculated according to equation (1) as (mv h (x,y),mv v (x, y)), where x = x'-x0, y = y'-y0; (b) In one example, the MV predictor uses a 4-parameter affine model obtained from a history-based affine table and is calculated as (mv h (x,y),mv v (x, y)), where x = x'-x0, y = y'-y0; ii. Some possible positions of (x”, y”) are: (e.g. Fig.24 (shown) (a)(x',y'), (b)(x'+M / 2,y'), (c)(x'+M / 2+1,y'), (d)(x'+M-1,y'), (e)(x'+M,y'), (f)(x',y'+N / 2), (g)(x'+M / 2,y'+N / 2), (h)(x'+M / 2+1, y'+N / 2), (i)(x'+M-1,y'+N / 2), (j)(x'+M, y'+N / 2), (k)(x',y'+N / 2+1), (l)(x'+M / 2,y'+N / 2+1), (m)(x'+M / 2+1,y'+N / 2+1), (n)(x'+M-1,y'+N / 2+1), (o)(x'+M,y'+N / 2+1), (p)(x',y'+N-1), (q)(x'+M / 2,y'+N-1), (r)(x'+M / 2+1,y'+N-1), (s)(x'+M-1,y'+N-1), (t)(x'+M,y'+N-1), (u)(x',y'+N), (v)(x'+M / 2,y'+N), (w)(x'+M / 2+1,y'+N), (x)(x'+M-1,y'+N), (y)(x'+M,y'+N). d. Whether to apply the MV predictor can be determined on the fly or depend on the coded information, such as block size, coded method, etc. 2. In one example, a HAD or NAD merge candidate may be placed in one or more positions in a merge candidate list. a. In one example, the merge candidate list may be a merge candidate list for a regular merge mode, and / or a variant of a merge mode such as TM, CIIP, GEO, MMVD, etc. b. In one example, the merge candidate list may be a merge-based additional hypothesis motion candidate list for multiple hypothesis prediction. c. In one example, the merge candidate list may be a constructed candidate list / virtual candidate list (eg, AMVP-merge list, true bi-prediction merge list) containing at least one merge candidate. d. A HAD or NAD merge candidate can be in the pruning process along with other merge candidates. e. The total number of HAD or NAD merge candidates must not be greater than N (eg, N=0, N=1, ...). If N=0, HAD or NAD merge candidates cannot be used. iN may be signaled from the encoder to the decoder. ii. N can be derived based on codec information (such as the size W×H of the current block). (a) For example, if W>Tw||H>Th, then N=0. For example, Tw=Th=16. (b) For example, if W>Tw&&H>Th, then N=0. For example, Tw=Th=16. f. In one example, one or more HAD or NAD merge candidates of the first set may be placed in the merge candidate list before the kth (k=0, 1, 2, . . . or corresponding to the last) spatial merge candidate. g. In one example, one or more HAD or NAD merge candidates of the second set may be placed in the merge candidate list after the kth (k=0, 1, 2, ... or corresponding to the last) spatial merge candidate. h. In one example, one or more HAD or NAD merge candidates of the third set may be placed in the merge candidate list before the TMVP merge candidate. i. In one example, a fourth set of one or more HAD or NAD merge candidates may be placed in the merge candidate list after the TMVP merge candidate. j. In one example, one or more HAD or NAD merge candidates of the fifth set may be placed in the merge candidate list before the kth (k=0, 1, 2, . . . or corresponding to the last) non-adjacent merge candidate. k. In one example, the sixth set of one or more HAD or NAD merge candidates may be placed in the merge candidate list after the kth (k=0, 1, 2, . . . or corresponding to the last) non-adjacent merge candidate. 1. In one example, one or more HAD or NAD merge candidates of the seventh set may be placed in the merge candidate list before the kth (k=0, 1, 2, . . . or corresponding to the last) HMVP merge candidate. m. In one example, one or more HAD or NAD merge candidates of the third set may be placed in the merge candidate list after the kth (k=0, 1, 2, . . . or corresponding to the last) merge candidate. n. In one example, one or more HAD or NAD merge candidates of the third set may be placed in the merge candidate list before the kth (k=0, 1, 2, . . . or corresponding to the last) zero merge candidate. o. In one example, a set of specific HAD or NAD candidates may be derived using only base MVs from affine-coded neighboring blocks. p. In one example, a set of specific HAD or NAD candidates may be derived using only base MVs of inter-coded neighboring blocks from non-affine codecs. q. In one example, a specific set of HAD candidates may be derived using only the latest affine model stored in the affine HMVP table or sub-table. r. In one example, a specific set of HAD candidates may be derived using only non-latest affine models stored in an affine HMVP table or sub-table. 3. In one example, the HAD AMVP candidate may be placed in one or more positions in the AMVP candidate list. a. In one example, the AMVP candidate list may be an AMVP candidate list for a conventional AMVP mode and / or a variant of an AMVP mode. b. In one example, the AMVP candidate list may be an AMVP-based additional hypothesis motion candidate list for multiple hypothesis prediction. c. In one example, the AMVP candidate list may be a constructed candidate list / virtual candidate list (eg, an AMVP merge list, a true bidirectional prediction AMVP list) containing at least one AMVP candidate. d.HAD or NAD AMVP candidates may be in the pruning process along with other AMVP candidates. e. The total number of HAD or NAD merge candidates must not be greater than N (eg, N=0, N=1, ...). If N=0, HAD or NAD merge candidates cannot be used. iN may be signaled from the encoder to the decoder. ii. N can be derived based on codec information (such as the size W×H of the current block). (a) For example, if W>Tw||H>Th, then N=0. For example, Tw=Th=16. (b) For example, if W>Tw&&H>Th, then N=0. For example, Tw=Th=16. f. In one example, one or more HAD or NADA MVP candidates of the first set may be placed in the AMVP candidate list before the kth (k=0, 1, 2, ... or corresponding to the last) spatial AMVP candidate. g. In one example, one or more HAD or NADA MVP candidates of the second set may be placed in the AMVP candidate list after the kth (k=0, 1, 2, ... or corresponding to the last) spatial AMVP candidate. h. In one example, a third set of one or more HAD or NADA MVP candidates may be placed in the AMVP candidate list before the TMVP AMVP candidate. i. In one example, a fourth set of one or more HAD or NADA MVP candidates may be placed in the AMVP candidate list after the TMVP AMVP candidate. j. In one example, one or more HAD or NADA MVP candidates of the fifth set may be placed in the AMVP candidate list before the kth (k=0, 1, 2, ... or corresponding to the last) non-adjacent AMVP. k. In one example, the sixth set of one or more HAD or NADA MVP candidates may be placed in the AMVP candidate list after the kth (k=0, 1, 2, ... or corresponding to the last) non-adjacent AMVP. 1. In one example, the seventh set of one or more HAD or NADA MVP candidates may be placed in the AMVP candidate list before the kth (k=0, 1, 2, ... or corresponding to the last) HMVP AMVP candidate. m. In one example, one or more HAD or NAD AMVP candidates of the eighth set can be placed in the AMVP candidate list, after the k-th (k = 0, 1, 2,... or corresponding to the last) AMVP candidate. n. In one example, one or more HAD or NAD AMVP candidates of the ninth set can be placed in the AMVP candidate list, before the k-th (k = 0, 1, 2,... or corresponding to the last) zero AMVP candidate. o. In one example, a specific set of HAD or NAD candidates can be derived using only the basic MVs from neighboring blocks that have been affine coded and decoded. p. In one example, a specific set of HAD or NAD candidates can be derived using only the basic MVs from inter-frame coded adjacent blocks that have not been affine coded and decoded. q. In one example, a specific set of HAD candidates can be derived using only the latest affine model stored in the affine HMVP table or sub-table. r. In one example, a specific set of HAD candidates can be derived using only the non-latest affine model stored in the affine HMVP table or sub-table. 4. Whether and / or how to use HAD or NAD candidates that can be inserted into the merge / AMVP list (such as sub-block based merge list, regular merge list) may depend on the coding information, which may include: a. The size W×H of the current block. i. For example, if W > Tw || H > Th, then the HAD or NAD candidates are not used. For example, Tw = Th = 16 or Tw = Th = 8. ii. For example, if W > Tw && H > Th, then the HAD or NAD candidates are not used. For example, Tw = Th = 16 or Tw = Th = 8. b. The temporal layer TL of the current picture. i. For example, if TL > K, then the HAD or NAD candidates are not used. For example, K = 2. ii. For example, if TL < K, then the HAD or NAD candidates are not used. For example, K = 2. c. Whether all reference pictures are before the current picture in display order. i. For example, if all reference pictures are before the current picture in display order, then the HAD or NAD candidates are not used. d. Whether all reference pictures are before the current picture in display order. i. For example, if all reference pictures are before the current picture in display order, then the HAD or NAD candidates are not used. e. A syntax element indicating whether the MVD of reference list 1 is always 0, such as ph_mvd_l1_zero_flag. i. For example, if the syntax element is equal to a specific value (eg, 1), then the HAD or NAD candidate is not used. f. Number of reference lists. i. For example, if the number of reference lists is equal to a certain value (eg, 1), the HAD or NAD candidate is not used. g. Number of reference lists. i. For example, if the number of reference lists is equal to a certain value (eg, 1), the HAD or NAD candidate is not used. h. POC of at least one reference picture. i. For example, if the POC of reference picture 0 in reference list 0 is within the range [POCcur-k1, POCcur+k2], where POCcur is the POC of the current picture, then the HAD or NAD candidate is not used. For example, k1=k2=1. 5. Examples A history parameter table (HPT) is created. An entry in the HPT stores a set of affine parameters: a, b, c, and d, each represented by a 16-bit signed integer. Entries in the HPT are classified by reference list and reference index. In the HPT, a maximum of 5 reference indexes are supported for each reference list. Formulaically, the category of the HPT (denoted as HPTCat) is calculated as HPTCat(RefList,RefIdx)=5×RefList+min(RefIdx,4), Where RefList and RefIdx represent the reference picture list (0 or 1) and the corresponding reference index, respectively. For each category, up to two entries can be stored. So there are a total of 20 entries in the HPT. At the beginning of each CTU row, the number of entries for each category is initialized to zero. cur and RefIdx cur After decoding the affine-encoded CU, the affine parameters are used to update the category HPTCat (RefList cur RefIdx cur ). The history parameter based affine candidate (HPAC) is obtained from Fig. 27 The MV of the neighboring 4×4 blocks is used as the base MV. In a formal way, the MV of the current block at position (x, y) is calculated as follows: Where (mv h base ,mv v base ) represents the MV of the adjacent 4×4 block, (x base ,y base ) represents the center position of the adjacent 4×4 block. (x,y) can be the center of the current block to obtain the MV of the current block. Fig.25 An example of how HPAC is derived from block A0 is shown. The affine parameters {a0, b0, c0, d0} are directly copied from an entry of class HPTIdx(RefListA0, refIdx0A0) in the HPT. The affine parameters from the HPT are used together with the center position of A0 used as the base position and the MV of block A0 used as the base MV to derive the MV located at the center of the current block as a regular merge candidate.

[0086] As used herein, the terms "video unit" or "codec unit" or "block" used herein may refer to one or more of the following: a color component, a sub-picture, a slice, a tile, a codec tree unit (CTU), a CTU row, a CTU group, a codec unit (CU), a prediction unit (PU), a transform unit (TU), a codec tree block (CTB), a codec block (CB), a prediction block (PB), a transform block (TB), a block, a sub-block of a block, a sub-region within a block, or a region including more than one sample or pixel.

[0087] In the present disclosure, with respect to “a block encoded and decoded in mode N”, the term “mode N” may be a prediction mode (e.g., MODE_INTRA, MODE_INTER, MODE_PLT, MODE_IBC, etc.) or a coding technology (e.g., AMVP, merge, SMVD, BDOF, PROF, DMVR, AMVR, TM, affine, CIIP, GPM, MMVD, BCW, HMVP, SbTMVP, etc.).

[0088] It should be noted that the following terms are not limited to the specific terms defined in existing standards, and any variants of the codec tool are also applicable.

[0089] Fig.26 A flow chart of a method 2600 for video processing according to some embodiments of the present disclosure is shown. The method 2600 may be implemented during conversion between blocks and bitstreams of blocks.

[0090] In box 2610, during conversion between a target block of a video and a bitstream of the target block, a motion vector predictor for the target block is derived from a parameter table storing a set of affine parameters from at least one previously encoded block. The target block is a non-affine encoded block. In some embodiments, the motion vector predictor may include one motion vector or two motion vectors for two inter-frame prediction directions. In some embodiments, the parameter table may include a history-based affine parameter table or a history-based affine parameter list. In some embodiments, the motion vector predictor may be a candidate for historical affine derivation (HAD). For example, in one example, an MV predictor (which may include one MV or two MVs for two inter-frame prediction directions) may be derived for a current non-affine encoded block from a history-based affine parameter table / list or other methods of storing affine parameters from previously encoded blocks. Such an MV predictor may be referred to as a candidate for historical affine derivation (HAD).

[0091] At block 2620, conversion is performed based on a motion vector predictor. In some embodiments, conversion may include encoding the target block into a bitstream. Alternatively, conversion may include decoding the target block from the bitstream. Compared to existing solutions, some embodiments of the present disclosure may advantageously improve codec efficiency, codec performance, and flexibility.

[0092] Embodiments of the present disclosure may be described in terms of the following clauses, and features of these clauses may be combined in any reasonable way.

[0093] In some embodiments, if the target block is encoded with a translational inter-frame mode, the motion vector predictor is used as an MVP candidate in a motion vector prediction (MVP) candidate list. In some embodiments, the motion vector predictor is applicable to the target inter-frame mode. For example, the target inter-frame mode does not have a hypothesis prediction. In one example, the MV predictor can also be applicable to certain inter-frame modes but not to other inter-frame modes, for example, it can be applied to an inter-frame mode without a hypothesis prediction. In some embodiments, the motion vector predictor can be used to derive additional hypotheses based on advanced motion vector prediction (AMVP) for multiple hypothesis prediction modes.

[0094] In some embodiments, if the target block is encoded with a merge mode, the motion vector predictor may be used as a merge candidate in a merge candidate list. In some embodiments, the motion vector predictor may be applicable to a target merge mode. For example, the target merge mode may be a regular merge mode. In some embodiments, the target merge mode is not a merge with a combination of a motion vector difference (MMVD) mode or an intra-frame inter-frame prediction (CIIP) mode. In one example, the MV predictor may also be applicable to certain merge modes but not to other modes, for example, it may be applicable to a regular merge mode but not to MMVD / CIIP.

[0095] In some embodiments, a portion of the motion information of the motion vector predictor may be applicable to a target merge mode. In some embodiments, the target merge mode may include at least one of: a geometric partitioning mode (GPM) mode or a variant of the GPM mode. In one example, a piece of motion information of the MV predictor (such as L0-MV or L1-MV, but not both) may be applicable to a certain merge mode, for example, it may be applicable to the GPM mode and its variants. In some embodiments, the motion vector predictor may be used to derive additional merge-based hypotheses for a multiple hypothesis prediction mode.

[0096] In some embodiments, the motion vector predictor may be derived based on neighboring blocks that are inter-coded. For example, in some embodiments, the first coordinate of the first position of the neighboring block that is inter-coded may be represented as (x0, y0), the second coordinate of the second position of the target block may be represented as (x', y'), the third coordinate of any point in the target block may be represented as (x", y"), the width of the target block may be represented as M, and the height of the target block may be represented as N.

[0097] In one example, the motion vector predictor may be calculated as (mv h (x,y),mv v (x,y)), according to Calculation. In this case, for a 4-parameter affine model obtained from the parameter table, x can be equal to (x''-x0) and y can be equal to (y''-y0).

[0098] In one example, the motion vector predictor can be used as (mv h (x,y),mv v (x,y)), according to Calculation. In this case, for the 6-parameter affine model obtained from the parameter table, x can be equal to (x"-x0) and y can be equal to (y"-y0).

[0099] In some embodiments, the third coordinate can be based on at least one of the following: the second coordinate, the width, or the height. For example, the third coordinate (x", y") can be one of the following: (x', y'), (x'+M / 2, y'), (x'+M / 2+1, y'), (x'+M-1, y'), (x'+M, y'), (x', y'+N / 2), (x'+M / 2, y'+N / 2), (x'+M / 2+1, y'+N / 2), (x'+M-1, y'+N / 2), (x'+M, y'+N / 2), (x', y'+N / 2+1), (x'+M / 2, y'+N / 2+1), (x'+M / 2+1,y'+N / 2+1), (x'+M-1,y'+N / 2+1), (x'+M,y'+N / 2+1), (x',y'+N-1), (x'+M / 2,y'+N-1), (x'+M / 2+1,y'+N-1), (x'+M-1,y'+N-1), (x'+M,y'+N-1), (x',y'+N), (x'+M / 2,y'+N), (x'+M / 2+1,y'+N), (x'+M-1,y'+N) or (x'+M,y'+N).

[0100] In some embodiments, whether to apply a motion vector predictor may be determined dynamically. In other words, whether to apply a MV predictor may be determined on the fly. Of course, whether to apply a motion vector predictor may be determined based on the codec information of the target block. For example, the codec information may include one or more of the following: block size or a method of coding and decoding.

[0101] In some embodiments, the indication of whether and / or how to derive the motion vector predictor for the target block from the parameter table may be indicated at one of: sequence level, group of picture level, picture level, slice level, or tile group level.

[0102] In some embodiments, an indication of whether and / or how to derive a motion vector predictor for a target block from a parameter table may be indicated in one of: a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, or a tile group header.

[0103] In some embodiments, the indication of whether and / or how the motion vector predictor of the target block is derived from the parameter table may be included in one of the following: a prediction block (PB), a transform block (TB), a codec block (CB), a prediction unit (PU), a transform unit (TU), a codec unit (CU), a virtual pipeline data unit (VPDU), a codec tree unit (CTU), a CTU row, a slice, a tile, a sub-picture, or a region containing more than one sample or pixel.

[0104] In some embodiments, whether and / or how to derive the motion vector predictor of the target block from the parameter table can be determined based on the encoded information of the target block. The encoded information can include at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[0105] In some embodiments, a motion vector predictor of a target block is derived from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block, and a bitstream of the target block is generated based on the motion vector predictor.

[0106] In some embodiments, a motion vector predictor for a target block of the video is derived from a parameter table storing a set of affine parameters from at least one previously encoded and decoded block, the target block being a non-affine encoded and decoded block; a bitstream for the target block is generated based on the motion vector predictor; and the bitstream is stored in a non-transitory computer-readable recording medium.

[0107] Fig. 27 A flow chart of a method 2700 for video processing according to some embodiments of the present disclosure is shown. The method 2700 may be implemented during conversion between blocks and bitstreams of blocks.

[0108] like Fig. 27 As shown, at block 2710, during conversion between a target block of a video and a bitstream of the target block, at least one motion vector predictor derived using an affine model for the target block is determined. In some embodiments, at least one motion vector predictor may be a merge candidate of a historical affine derivation (HAD). Alternatively, at least one motion vector predictor may be a merge candidate of a neighbor affine derivation (NAD). In some embodiments, at least one motion vector predictor may be a HAD AMVP candidate. Alternatively, at least one motion vector predictor may be a NAD AMVP candidate.

[0109] At block 2720, a motion vector predictor is inserted into at least one position in the candidate list. In some embodiments, the candidate list may include a merge candidate list. Alternatively, the candidate list may include an AMVP candidate list.

[0110] At block 2730, conversion is performed based on the candidate list. In some embodiments, conversion may include encoding the target block into a bitstream. Alternatively, conversion may include decoding the target block from the bitstream. Compared to existing solutions, some embodiments of the present disclosure may advantageously improve codec efficiency, codec performance, and flexibility.

[0111] Embodiments of the present disclosure may be described in terms of the following clauses, and features of these clauses may be combined in any reasonable way.

[0112] In some embodiments, as described above, the candidate list may be a merge candidate list. In this case, the merge candidate list may be used for at least one of the following: a conventional merge mode, or a variant of the merge mode. For example, a variant of the merge mode may include at least one of the following: a template matching (TM) mode, a CIIP mode, a geometric (GEO) mode, or an MMVD mode. In some embodiments, the merge candidate list may be a merge-based additional hypothesis motion candidate list for multiple hypothesis predictions. In some embodiments, the merge candidate list may be a constructed candidate list / virtual candidate list containing at least one merge candidate. For example, the constructed candidate list / virtual candidate list may be one or more of the following: an AMVP-MERGE list or a true bidirectional prediction merge list. In some embodiments, at least one motion vector predictor may be in a pruning process together with at least one other merge candidate.

[0113] In some embodiments, as described above, the candidate list may include an AMVP candidate list. In some embodiments, the AMVP candidate list may be used for at least one of: a conventional AMVP mode, or a variant of the AMVP mode. In some embodiments, the AMVP candidate list may be an AMVP-based additional hypothesis motion candidate list for multiple hypothesis predictions. In some embodiments, the AMVP candidate list is a constructed candidate list / virtual candidate list containing at least one AMVP candidate. For example, the constructed / virtual candidate list may include one or more of the following: an AMVP merge list or a true bidirectional prediction AMVP list. In some embodiments, at least one motion vector predictor may be in a pruning process with at least one other AMVP candidate.

[0114] In some embodiments, the total number of motion vector predictors may not be greater than the first threshold value. The first threshold value may be any suitable integer. In some embodiments, if the first threshold value is 0, at least one motion vector predictor may not be used. In some embodiments, the first threshold value may be indicated from the encoder side to the decoder side. Alternatively, the first threshold value may be derived based on the encoding and decoding information of the target block. For example, the first threshold value may be derived based on the dimensional information of the target block. In this case, in some embodiments, if the width of the target block is greater than the first width or the height of the target block is greater than the first height, the first threshold value may be 0. For example, the first width and the first height may be 16. In some other embodiments, if the width of the target block is greater than the first width and the height of the target block is greater than the first height, the first threshold value may be 0. For example, the first width and the first height may be 16.

[0115] In some embodiments, the at least one motion vector predictor of the first set may be placed in the merge candidate list before the kth spatial merge candidate. K may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0116] In some embodiments, the at least one motion vector predictor of the second set may be placed in the merge candidate list after the kth spatial merge candidate in the candidate list. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0117] In some embodiments, the at least one motion vector predictor of the third set may be placed in the merge candidate list before a temporal motion vector prediction (TMVP) merge candidate. In some embodiments, the at least one motion vector predictor of the fourth set may be placed in the merge candidate list after a TMVP merge candidate.

[0118] In some embodiments, the at least one motion vector predictor of the fifth set may be placed in the merge candidate list before the kth non-adjacent merge candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0119] In some embodiments, the at least one motion vector predictor of the sixth set may be placed in the merge candidate list after the kth non-adjacent merge candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0120] In some embodiments, the at least one motion vector predictor of the seventh set may be placed in the merge candidate list and before the kth history-based motion vector prediction (HMVP) merge candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0121] In some embodiments, the at least one motion vector predictor of the eighth set may be placed in the merge candidate list after the kth merge candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0122] In some embodiments, the at least one motion vector predictor of the ninth set may be placed in the merge candidate list before the kth zero merge candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0123] In some embodiments, the at least one motion vector predictor of the first set may be placed in the AMVP candidate list before the kth spatial AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0124] In some embodiments, the at least one motion vector predictor of the second set may be placed in the AMVP candidate list after the kth spatial AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0125] In some embodiments, the at least one motion vector predictor of the third set may be placed in the AMVP candidate list before a temporal motion vector prediction (TMVP) AMVP candidate. In some embodiments, the at least one motion vector predictor of the fourth set is placed in the AMVP candidate list after a TMVP AMVP candidate.

[0126] In some embodiments, the at least one motion vector predictor of the fifth set may be placed in the AMVP candidate list before the kth non-adjacent AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0127] In some embodiments, the at least one motion vector predictor of the sixth set may be placed in the AMVP candidate list after the kth non-adjacent AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0128] In some embodiments, the at least one motion vector predictor of the seventh set may be placed in the AMVP candidate list and before the kth history-based motion vector prediction (HMVP) AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0129] In some embodiments, the at least one motion vector predictor of the eighth set may be placed in the AMVP candidate list after the kth AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0130] In some embodiments, the at least one motion vector predictor of the ninth set is placed in the AMVP candidate list before the kth zero AMVP candidate. k may be an integer, such as 0, 1, 2, ..., or corresponds to the last one.

[0131] In some embodiments, whether and / or how to use the at least one motion vector predictor inserted into the candidate list depends on the codec information of the target block. For example, the candidate list may include at least one of the following: a merge list, an AMVP list, a sub-block based merge list, or a conventional merge list. In some embodiments, the codec information may indicate the dimension information of the target block. For example, if the width of the target block is greater than the first width or the height of the target block is greater than the first height, the motion vector predictor may not be used. In some embodiments, the first width and the first height may be 16 or 8.

[0132] In some embodiments, if the width of the target block is greater than the first width and the height of the target block is greater than the first height, the motion vector predictor may not be used. For example, the first width and the first height may be 16 or 8.

[0133] In some embodiments, the coding information indicates the temporal layer information of the target block. For example, if the number of temporal layers of the target block is higher than a second threshold, the motion vector predictor may not be used. Alternatively, if the number of temporal layers of the target block is less than the second threshold, the motion vector predictor may not be used. In some embodiments, the second threshold may be 2.

[0134] In some embodiments, the codec information may indicate whether all reference pictures are located before the current picture associated with the target block in display order. For example, if all reference pictures are located before the current picture in the display order, the motion vector predictor may not be used. In other embodiments, the codec information may indicate whether all reference pictures are located after the current picture associated with the target block in display order. In this case, in some embodiments, if all reference pictures are located after the current picture in the display order, the motion vector predictor is not used.

[0135] In some embodiments, the codec information may indicate a syntax element indicating whether the MVD of reference list 1 is 0. For example, the syntax element may be ph_mvd_l1_zero_flag. In some embodiments, if the syntax element is equal to a specific value, the motion vector predictor is not used. In this case, for example, the specific value may be 1.

[0136] In some embodiments, the codec information may indicate the number of reference lists. In this case, in some embodiments, if the number of reference lists is equal to a specific value, the motion vector predictor is not used. For example, the specific value may be 1.

[0137] In some embodiments, the codec information indicates a picture order count (POC) of the at least one reference picture. In this case, in some embodiments, if the POC of reference picture 0 in reference list 0 is within a predetermined range, the motion vector predictor may not be used. In some embodiments, the predetermined range may be [POCcur-k1, POCcur+k2]. In this case, POCcur may be the POC of the current picture associated with the target block. k1 and k2 may be integers. For example, k1 and k2 may be equal to 1.

[0138] In some embodiments, the indication of whether and / or how to insert at least one motion vector predictor into at least one position in the candidate list may be indicated at one of: sequence level, picture group level, picture level, slice level or tile group level.

[0139] In some embodiments, an indication of whether and / or how to insert at least one motion vector predictor into at least one position in a candidate list may be indicated in at least one of the following: a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, or a tile group header.

[0140] In some embodiments, an indication of whether and / or how to insert at least one motion vector predictor into at least one position in the candidate list may be included in one of: a prediction block (PB), a transform block (TB), a codec block (CB), a prediction unit (PU), a transform unit (TU), a codec unit (CU), a virtual pipeline data unit (VPDU), a codec tree unit (CTU), a CTU row, a slice, a tile, a sub-picture, or a region containing more than one sample or pixel.

[0141] In some embodiments, whether and / or how to insert at least one motion vector predictor into at least one position in the candidate list may be determined based on coded information of the target block. The coded information may include at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[0142] In some embodiments, at least one motion vector predictor derived using an affine model for a target block of the video is determined, the motion vector predictor is inserted into at least one position in a candidate list, and a bitstream for the target block is generated based on the candidate list.

[0143] In some embodiments, at least one motion vector predictor derived using an affine model for a target block of the video is determined; the motion vector predictor is inserted into at least one position in a candidate list; a bitstream for the target block is generated based on the candidate list; and the bitstream is stored in a non-transitory computer-readable recording medium.

[0144] The embodiments of the present invention may be implemented separately. Alternatively, the embodiments of the present invention may be implemented in any appropriate combination. The embodiments of the present disclosure may be described according to the following clauses, and the features of these clauses may be combined in any reasonable manner.

[0145] Article 1. A method of video processing, comprising: during conversion between a target block of a video and a bitstream of the target block, deriving a motion vector predictor for the target block from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; performing the conversion based on the motion vector predictor.

[0146] Clause 2. The method of clause 1, wherein the motion vector predictor comprises one motion vector or two motion vectors for two inter prediction directions.

[0147] Clause 3. The method of clause 1 or 2, wherein the parameter table comprises a history-based affine parameter table or a history-based affine parameter list.

[0148] Clause 4. A method as described in any of clauses 1-3, wherein the motion vector predictor is a historical affine derived (HAD) candidate.

[0149] Clause 5. A method according to any of clauses 1-4, wherein if the target block is coded using translational inter mode, the motion vector predictor is used as a motion vector prediction (MVP) candidate in the MVP candidate list.

[0150] Clause 6. The method of clause 5, wherein the motion vector predictor is applicable to the target inter mode.

[0151] Clause 7. The method of clause 6, wherein the target inter mode has no hypothesized prediction.

[0152] Clause 8. The method of clause 5, wherein the motion vector predictor is used to derive additional hypotheses based on Advanced Motion Vector Prediction (AMVP) for a multiple hypothesis prediction mode.

[0153] Clause 9. A method according to any of clauses 1-4, wherein if the target block is encoded using merge mode, the motion vector predictor is used as a merge candidate in the MVP candidate list.

[0154] Clause 10. The method of clause 9, wherein the motion vector predictor is applicable to a target merge mode.

[0155] Clause 11. The method of clause 10, wherein the target merge mode is a normal merge mode, and wherein the target merge mode is not a merge with combined motion vector difference (MMVD) mode or a combined intra inter prediction (CIIP) mode.

[0156] Clause 12. The method of clause 9, wherein a portion of the motion information of the motion vector predictor is applicable to the target merge mode.

[0157] Clause 13. The method of clause 12, wherein the target merge mode comprises at least one of: a geometric partition mode (GPM) mode or a variant of a GPM mode.

[0158] Clause 14. The method of clause 9, wherein the motion vector predictor is used to derive a merge-based additional hypothesis for the multi-hypothesis prediction mode.

[0159] Clause 15. The method of any of clauses 1-4, wherein the motion vector predictor is derived based on inter-frame encoded neighboring blocks.

[0160] Clause 16. The method of clause 15, wherein the first coordinate of the first position of the inter-frame encoded neighboring block is represented as (x0, y0), the second coordinate of the second position of the target block is represented as (x', y'), the third coordinate of any point in the target block is represented as (x", y"), the width of the target block is M, and the height of the target block is N.

[0161] Clause 17. The method of clause 16, wherein the motion vector predictor is based on Calculated as (mv h (x,y),mv v (x, y)), where x is equal to (x"-x0) and y is equal to (y"-y0) when using a 4-parameter affine model obtained from a parameter table.

[0162] Clause 18. The method of clause 16, wherein the motion vector predictor is based on Calculated as (mv h (x,y),mv v (x,y)), where x equals (x"-x0) and y equals (y"-y0) in the case of a 6-parameter affine model taken from the parameter table.

[0163] Clause 19. The method of clause 16, wherein the third coordinate is based on at least one of: the second coordinate, the width, or the height.

[0164] Clause 20. The method according to clause 19, wherein the third coordinate (x", y") is one of the following: (x', y'), (x'+M / 2, y'), (x'+M / 2+1, y'), (x'+M-1, y'), (x'+M, y'), (x', y'+N / 2), (x'+M / 2, y'+N / 2), (x'+M / 2+1, y'+N / 2), (x'+M-1, y'+N / 2), (x'+M, y'+N / 2), (x', y'+N / 2+1), (x'+M / 2, y'+N / 2+1), (x'+M / 2+1,y'+N / 2+1),(x'+M-1,y'+N / 2+1),(x'+M,y'+N / 2+1),(x',y'+N-1),(x'+M / 2,y'+N-1),(x'+M / 2+1,y'+N-1 ), (x'+M-1,y'+N-1), (x'+M,y'+N-1), (x',y'+N), (x'+M / 2,y'+N), (x'+M / 2+1,y'+N), (x'+M-1,y'+N) or (x'+M,y'+N).

[0165] Clause 21. A method according to any of clauses 1-4, wherein whether to apply a motion vector predictor is determined dynamically, or wherein whether to apply a motion vector predictor is determined based on codec information of a target block.

[0166] Article 22. A method of video processing, comprising: during a conversion between a target block of a video and a bitstream of the target block, determining at least one motion vector predictor derived from an affine model for the target block; inserting the motion vector predictor into at least one position in a candidate list; and performing the conversion according to the candidate list.

[0167] Clause 23. The method of clause 22, wherein the at least one motion vector predictor is a historical affine derived (HAD) merge candidate or a neighboring affine derived (NAD) merge candidate, or wherein the at least one motion vector predictor is a HAD AMVP candidate or a NAD AMVP candidate.

[0168] Clause 24. A method as described in clause 22 or 23, wherein the candidate list comprises a merged candidate list.

[0169] Clause 25. The method of clause 24, wherein the merge candidate list is used for at least one of: a regular merge mode, or a variant of a merge mode.

[0170] Clause 26. The method of clause 25, wherein the variant of the merge mode comprises at least one of: a template matching (TM) mode, a CIIP mode, a geometric (GEO) mode, or an MMVD mode.

[0171] Clause 27. The method of clause 24, wherein the merge candidate list is a merge-based additional hypothesis motion candidate list for multi-hypothesis prediction.

[0172] Clause 28. The method of clause 24, wherein the merge candidate list is a constructed candidate list / virtual candidate list including at least one merge candidate.

[0173] Clause 29. The method of clause 24, wherein the at least one motion vector predictor is in the process of being pruned with at least one other merge candidate.

[0174] Article 30. The method of clause 22 or 23, wherein the candidate list comprises an AMVP candidate list.

[0175] Clause 31. The method of clause 30, wherein the AMVP candidate list is used in at least one of: a regular AMVP mode, or a variation of the AMVP mode.

[0176] Clause 32. The method of clause 30, wherein the AMVP candidate list is an AMVP-based additional hypothesis motion candidate list for multi-hypothesis prediction.

[0177] Clause 33. The method of clause 30, wherein the AMVP candidate list is a constructed candidate list / virtual candidate list comprising at least one AMVP candidate.

[0178] Clause 34. The method of claim 30, wherein the at least one motion vector predictor is in a pruning process with at least one other AMVP candidate.

[0179] Clause 35. The method of any of clauses 22-34, wherein the total number of motion vector predictors is no greater than a first threshold.

[0180] Clause 36. The method of clause 35, wherein if the first threshold is zero, the at least one motion vector predictor is not used.

[0181] Clause 37. The method of clause 35, wherein the first threshold is indicated from an encoder side to a decoder side.

[0182] Clause 38. The method of clause 35, wherein the first threshold is derived based on codec information of the target block.

[0183] Clause 39. The method of clause 38, wherein the first threshold is derived based on dimensional information of the target block.

[0184] Clause 40. The method of clause 39, wherein the first threshold is 0 if a width of the target block is greater than a first width or a height of the target block is greater than a first height.

[0185] Clause 41. The method of clause 40, wherein the first width and the first height are 16.

[0186] Clause 42. The method of clause 39, wherein the first threshold is 0 if a width of the target block is greater than a first width and a height of the target block is greater than a first height.

[0187] Clause 43. The method of clause 42, wherein the first width and the first height are 16.

[0188] Clause 44. The method of any of clauses 24-29, wherein a first set of the at least one motion vector predictor is placed in the merge candidate list before a k-th spatial merge candidate, and wherein k is an integer.

[0189] Clause 45. The method of any of clauses 24-29, wherein the second set of at least one motion vector predictor is placed in the merge candidate list after a k-th spatial merge candidate of the candidate list, and wherein k is an integer.

[0190] Clause 46. A method as recited in any of clauses 24-29, wherein the third set of at least one motion vector predictor is placed into the merge candidate list before a temporal motion vector prediction (TMVP) merge candidate.

[0191] Clause 47. The method of any of clauses 24-29, wherein a fourth set of the at least one motion vector predictor is placed into the merge candidate list after the TMVP merge candidate.

[0192] Clause 48. The method of any of clauses 24-29, wherein a fifth set of the at least one motion vector predictor is placed in the merge candidate list before a k-th non-adjacent merge candidate, and wherein k is an integer.

[0193] Clause 49. The method of any of clauses 24-29, wherein a sixth set of the at least one motion vector predictor is placed in the merge candidate list after a kth non-adjacent merge candidate, and wherein k is an integer.

[0194] Clause 50. The method of any of clauses 24-29, wherein a seventh set of the at least one motion vector predictor is placed in the merge candidate list before a kth history-based motion vector prediction (HMVP) merge candidate, and wherein k is an integer.

[0195] Clause 51. The method of any of clauses 24-29, wherein an eighth set of the at least one motion vector predictor is placed in the merge candidate list after a kth merge candidate, and wherein k is an integer.

[0196] Clause 52. The method of any of clauses 24-29, wherein a ninth set of the at least one motion vector predictor is placed in the merge candidate list before a k-th zero merge candidate, and wherein k is an integer.

[0197] Clause 53. The method of any of clauses 30-34, wherein the first set of at least one motion vector predictor is placed in the AMVP candidate list before a k-th spatial AMVP candidate, and wherein k is an integer.

[0198] Clause 54. The method of any of clauses 30-34, wherein the second set of at least one motion vector predictor is placed in the AMVP candidate list after a k-th spatial AMVP candidate, and wherein k is an integer.

[0199] Clause 55. The method of any of clauses 30-34, wherein a third set of the at least one motion vector predictor is placed into the AMVP candidate list before a temporal motion vector prediction (TMVP) AMVP candidate.

[0200] Clause 56. The method of any of clauses 30-34, wherein a fourth set of the at least one motion vector predictor is placed into the AMVP candidate list after the TMVP AMVP candidates.

[0201] Clause 57. The method of any of clauses 30-34, wherein a fifth set of the at least one motion vector predictor is placed in the AMVP candidate list before a k-th non-adjacent AMVP candidate, and wherein k is an integer.

[0202] Clause 58. The method of any of clauses 30-34, wherein a sixth set of the at least one motion vector predictor is placed in the AMVP candidate list after a kth non-adjacent AMVP candidate, and wherein k is an integer.

[0203] Clause 59. The method of any of clauses 30-34, wherein the seventh set of the at least one motion vector predictor is placed in the AMVP candidate list before a kth history-based motion vector prediction (HMVP) AMVP candidate, and wherein k is an integer.

[0204] Clause 60. The method of any of clauses 30-34, wherein an eighth set of the at least one motion vector predictor is placed in the AMVP candidate list after a kth AMVP candidate, and wherein k is an integer.

[0205] Clause 61. The method of any of clauses 30-34, wherein a ninth set of the at least one motion vector predictor is placed in the AMVP candidate list before a k-th zero AMVP candidate, and wherein k is an integer.

[0206] Clause 62. A method according to clause 22 or 23, wherein whether and / or how to use the at least one motion vector predictor inserted into the candidate list depends on codec information of the target block.

[0207] Clause 63. The method of clause 62, wherein the candidate list comprises at least one of: a merge list, an AMVP list, a sub-block based merge list, or a regular merge list.

[0208] Clause 64. The method of clause 62, wherein the codec information indicates dimension information of the target block.

[0209] Clause 65. The method of clause 64, wherein the motion vector predictor is not used if a width of the target block is greater than a first width or a height of the target block is greater than a first height.

[0210] Clause 66. The method of clause 62, wherein the first width and the first height are 16 or 8.

[0211] Clause 67. The method of clause 64, wherein if a width of the target block is greater than a first width and a height of the target block is greater than a first height, then the motion vector predictor is not used.

[0212] Clause 68. The method of clause 67, wherein the first width and the first height are 16 or 8.

[0213] Clause 69. The method of clause 62, wherein the codec information indicates temporal layer information of the target block.

[0214] Clause 70. The method of clause 69, wherein the motion vector predictor is not used if the number of temporal layers of the target block is above a second threshold, or wherein the motion vector predictor is not used if the number of temporal layers of the target block is less than the second threshold.

[0215] Clause 71. The method of clause 70, wherein the second threshold is 2.

[0216] Clause 72. The method of clause 62, wherein the codec information indicates whether all reference pictures precede the current picture associated with the target block in display order.

[0217] Clause 73. The method of clause 72, wherein if all reference pictures precede the current picture in the display order, then a motion vector predictor is not used.

[0218] Clause 74. The method of clause 62, wherein the codec information indicates whether all reference pictures are located after the current picture associated with the target block in display order.

[0219] Clause 75. The method of clause 74, wherein if all reference pictures are located after the current picture in the display order, a motion vector predictor is not used.

[0220] Clause 76. The method of clause 62, wherein the codec information indicates a syntax element, the syntax element being used to indicate whether the MVD of reference list 1 is zero.

[0221] Clause 77. The method of claim 76, wherein the syntax element is ph_mvd_l1_zero_flag.

[0222] Clause 78. The method of clause 76, wherein if the syntax element is equal to a particular value, a motion vector predictor is not used.

[0223] Clause 79. The method of clause 78, wherein the specific value is 1.

[0224] Clause 80. The method of clause 62, wherein the codec information indicates a number of reference lists.

[0225] Clause 81. The method of clause 80, wherein if the number of reference lists is equal to a particular value, the motion vector predictor is not used.

[0226] Clause 82. The method of clause 81, wherein the specific value is 1.

[0227] Clause 83. The method of clause 62, wherein the codec information indicates a picture order count (POC) of at least one reference picture.

[0228] Clause 84. The method of clause 83, wherein if the POC of reference picture 0 in reference list 0 is within a predetermined range, then the motion vector predictor is not used.

[0229] Clause 85. The method of clause 84, wherein the predetermined range is [POCcur-k1, POCcur+k2], where POCcur is the POC of the current picture associated with the target block, and k1 and k2 are integers.

[0230] Article 86. The method of clause 85, wherein k1 and k2 are equal to 1.

[0231] Clause 87. The method of any of clauses 1-86, wherein the converting comprises encoding the video unit into a bitstream.

[0232] Clause 88. The method of any of clauses 1-86, wherein converting comprises decoding the video unit from a bitstream.

[0233] Clause 89. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method of any of clauses 1-88.

[0234] Article 90. A non-transitory computer-readable storage medium storing instructions, the medium storing instructions for causing a processor to perform the method of any one of claims 1-88.

[0235] Article 91. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by a video processing apparatus, wherein the method comprises: deriving a motion vector predictor of a target block of the video from a parameter table storing a set of affine parameters from at least one previously coded or decoded block, the target block being a non-affine coded or decoded block; and generating a bitstream of the target block based on the motion vector predictor.

[0236] Article 92. A method for storing a bitstream of a video, comprising: deriving a motion vector predictor for a target block of the video from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; generating a bitstream of the target block based on the motion vector predictor; and storing the bitstream in a non-transitory computer-readable recording medium.

[0237] Article 93. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by a video processing device, wherein the method comprises: determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; and generating a bitstream of the target block based on the candidate list.

[0238] Article 94. A method for storing a bitstream of a video, comprising determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; generating a bitstream for the target block based on the candidate list; and storing the bitstream in a non-transitory computer-readable recording medium. Device Examples

[0239] Fig.28 A block diagram of a computing device 2800 is shown in which various embodiments of the present disclosure may be implemented. The computing device 2800 may be implemented as or included in the source device 110 (or video encoder 114 or 200) or the destination device 120 (or video decoder 124 or 300).

[0240] It should be understood that Fig.28 The computing device 2800 shown is for illustration purposes only and is not intended to in any way imply any limitation on the functionality and scope of the embodiments of the present disclosure.

[0241] like Fig.28 As shown, computing device 2800 includes a general computing device 2800. Computing device 2800 may include at least one or more processors or processing units 2810, memory 2820, storage unit 2830, one or more communication units 2840, one or more input devices 2850, and one or more output devices 2860.

[0242] In some embodiments, the computing device 2800 can be implemented as any user terminal or server terminal with computing power. The server terminal can be a server, a large computing device, etc. provided by a service provider. The user terminal can be, for example, any type of mobile terminal, fixed terminal, or portable terminal, including a mobile phone, a station, a unit, a device, a multimedia computer, a multimedia tablet computer, an Internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a tablet computer, a personal communication system (PCS) device, a personal navigation device, a personal digital assistant (PDA), an audio / video player, a digital camera / camcorder, a positioning device, a television receiver, a radio broadcast receiver, an e-book device, a gaming device, or any combination thereof, including accessories and peripherals of these devices, or any combination thereof. It can be expected that the computing device 2800 can support any type of interface with the user (such as a "wearable" circuit, etc.).

[0243] Processing unit 2810 may be a physical or virtual processor and may implement various processes based on a program stored in memory 2820. In a multi-processor system, multiple processing units execute computer executable instructions in parallel to increase the parallel processing capabilities of computing device 2800. Processing unit 2810 may also be referred to as a central processing unit (CPU), a microprocessor, a controller, or a microcontroller.

[0244] The computing device 2800 typically includes various computer storage media. Such media can be any media accessible to the computing device 2800, including but not limited to volatile and non-volatile media, or removable and non-removable media. The memory 2820 can be a volatile memory (e.g., a register, a cache, a random access memory (RAM)), a non-volatile memory (e.g., a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), or flash memory), or any combination thereof. The storage unit 2830 can be any removable or non-removable medium, and can include a machine-readable medium, such as a memory, a flash drive, a disk, or other media, which can be used to store information and / or data and can be accessed in the computing device 2800.

[0245] The computing device 2800 may also include additional removable / non-removable, volatile / non-volatile storage media. Fig.28 Although not shown in the figure, a magnetic disk drive for reading and / or writing from a removable and non-volatile magnetic disk and an optical disk drive for reading and / or writing from a removable non-volatile magnetic disk and a volatile optical disk may be provided. In this case, each drive may be connected to the bus (not shown) via one or more data medium interfaces.

[0246] The communication unit 2840 communicates with another computing device via a communication medium. In addition, the functions of the components in the computing device 2800 can be implemented by a single computing cluster or multiple computing machines that can communicate through a communication connection. Therefore, the computing device 2800 can operate in a networked environment using logical connections to one or more other servers, networked personal computers (PCs), or other general network nodes.

[0247] Input device 2850 may be one or more of various input devices, such as a mouse, keyboard, trackball, voice input device, etc. Output device 2860 may be one or more of various output devices, such as a display, a speaker, a printer, etc. Through communication unit 2840, computing device 2800 may also communicate with one or more external devices (not shown) such as a storage device, a display device, etc., so that a user can interact with computing device 2800. Or if necessary, any device (such as a network card, a modem, etc.) that enables computing device 2800 to communicate with one or more other computing devices. Such communication may be performed via an input / output (I / O) interface (not shown).

[0248] In some embodiments, some or all components of the computing device 2800 may also be arranged in a cloud computing architecture rather than being integrated in a single device. In a cloud computing architecture, components may be provided remotely and work together to implement the functions described in the present disclosure. In some embodiments, cloud computing provides computing, software, data access, and storage services without requiring end users to understand the physical location or configuration of the systems or hardware that provide these services. In various embodiments, cloud computing provides services over a wide area network (e.g., the Internet) using a suitable protocol. For example, a cloud computing provider provides applications over a wide area network that can be accessed through a web browser or any other computing component. The software or components of the cloud computing architecture and the corresponding data may be stored on a server at a remote location. The computing resources in a cloud computing environment may be merged or distributed at the location of a remote data center. Cloud computing infrastructure may provide services through a shared data center, although they act as a single access point for users. Therefore, cloud computing architecture may be used to provide components and functions described herein from a service provider at a remote location. In development locations, they may be provided from a traditional server or installed directly or otherwise on a client device.

[0249] The computing device 2800 may be used to implement video encoding / decoding in the embodiments of the present invention. The memory 2820 may include one or more video encoding / decoding modules 2825 having one or more program instructions. These modules may be accessed and executed by the processing unit 2810 to perform the functions of the various embodiments described herein.

[0250] In an example embodiment performing video encoding, input device 2850 may receive video data as input to be encoded 2870. The video data may be processed, for example, by video codec module 2825 to generate an encoded bitstream. The encoded bitstream may be provided as output 2880 via output device 2860.

[0251] In an example embodiment performing video decoding, input device 2850 may receive an encoded bitstream as input 2870. The encoded bitstream may be processed, for example, by video codec module 2825 to generate decoded video data. The decoded video data may be provided as output 2880 via output device 2860.

[0252] Although the present disclosure has been specifically shown and described with reference to its preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present application: as defined by the appended claims. These changes are intended to be covered by the scope of the present application. Therefore, the foregoing description of the embodiments of the present application is not intended to be limiting.

Claims

1. A video processing method, comprising: deriving a motion vector predictor for a target block of video from a parameter table storing a set of affine parameters from at least one previously coded block during conversion between the target block and a bitstream of the target block, the target block being a non-affine coded block; as well as The conversion is performed based on the motion vector predictor. 2 . The method of claim 1 , wherein the motion vector predictor comprises one motion vector or two motion vectors for two inter-prediction directions.

3. The method according to claim 1 or 2, wherein the parameter table comprises a history-based affine parameter table or a history-based affine parameter list.

4. The method according to any one of claims 1 to 3, wherein the motion vector predictor is a candidate for historical affine derivation (HAD).

5. The method according to any one of claims 1 to 4, wherein if the target block is coded in a translational inter mode, the motion vector predictor is used as a motion vector prediction (MVP) candidate in a MVP candidate list. The method of claim 5 , wherein the motion vector predictor is adapted for a target inter mode. The method of claim 6 , wherein the target inter mode has no hypothetical prediction.

8. The method of claim 5, wherein the motion vector predictor is used to derive additional hypotheses based on Advanced Motion Vector Prediction (AMVP) for a multiple hypothesis prediction mode.

9. The method according to any one of claims 1 to 4, wherein: If the target block is coded using merge mode, the motion vector predictor is used as a merge candidate in a merge candidate list.

10. The method of claim 9, wherein the motion vector predictor is adapted for a target merge mode.

11. The method of claim 10, wherein the target merge mode is a normal merge mode, and in, The target merge mode is not a merge with combination of motion vector difference (MMVD) mode or intra inter prediction (CIIP) mode.

12. The method of claim 9, wherein a portion of the motion information of the motion vector predictor is applicable to a target merge mode.

13. The method of claim 12, wherein the target merge mode comprises at least one of: a geometric partitioning mode (GPM) mode or a variant of the GPM mode.

14. The method of claim 9, wherein the motion vector predictor is used to derive merge-based additional hypotheses for a multiple hypothesis prediction mode.

15. The method according to any one of claims 1 to 4, wherein the motion vector predictor is derived based on inter-coded neighboring blocks.

16. The method according to claim 15, wherein the first coordinate of the first position of the inter-frame encoded neighboring block is represented as (x0, y0), the second coordinate of the second position of the target block is represented as (x', y'), the third coordinate of any point in the target block is represented as (x", y"), the width of the target block is represented as M, and the height of the target block is represented as N.

17. The method of claim 16, wherein the motion vector predictor is calculated as (mv h (x,y),mv v (x,y)): In the case of a 4-parameter affine model obtained from the parameter table, x is equal to (x"-x0), and y is equal to (y"-y0).

18. The method of claim 16, wherein the motion vector predictor is calculated as (mv h (x,y),mv v (x,y)): In the case of a 4-parameter affine model obtained from the parameter table, x is equal to (x"-x0), and y is equal to (y"-y0).

19. The method of claim 16, wherein the third coordinate is based on at least one of: the second coordinate, the width, or the height.

20. The method of claim 19, wherein the third coordinate (x", y") is one of the following: (x', y'), (x'+M / 2, y'), (x'+M / 2+1, y'), (x'+M-1, y'), (x'+M, y'), (x', y'+N / 2), (x'+M / 2, y'+N / 2), (x'+M / 2+1, y'+N / 2), (x'+M-1, y'+N / 2), (x'+M, y'+N / 2), (x', y'+N / 2+1), (x'+M / 2, y'+N / 2+ 1), (x'+M / 2+1,y'+N / 2+1), (x'+M-1,y'+N / 2+1), (x'+M,y'+N / 2+1), (x',y'+N-1), (x'+M / 2,y'+N-1), (x'+M / 2+1,y'+N -1), (x'+M-1,y'+N-1), (x'+M,y'+N-1), (x',y'+N), (x'+M / 2,y'+N), (x'+M / 2+1,y'+N), (x'+M-1,y'+N) or (x'+M,y'+N).

21. A method according to any one of claims 1 to 4, wherein whether to apply the motion vector predictor is determined dynamically, or in, Whether to apply the motion vector predictor is determined based on codec information of the target block.

22. A method for video processing, comprising: During conversion between a target block of video and a bitstream of the target block, determining at least one motion vector predictor derived using an affine model for the target block; inserting the motion vector predictor into at least one position in a candidate list; as well as The converting is performed based on the candidate list.

23. The method of claim 22, wherein the at least one motion vector predictor is a history affine derived (HAD) merge candidate or a neighbor affine derived (NAD) merge candidate, or in, The at least one motion vector predictor is a HAD AMVP candidate or a NAD AMVP candidate.

24. The method of claim 22 or 23, wherein the candidate list comprises a merged candidate list.

25. The method according to claim 24, wherein the merge candidate list is used for at least one of the following: Regular merge mode, or A variation of the merge mode.

26. The method of claim 25, wherein the variants of the merge mode include at least one of the following: Template Matching (TM) mode, CIIP mode, Geometry (GEO) mode, or MMVD mode.

27. The method of claim 24, wherein the merge candidate list is a merge-based additional hypothesis motion candidate list for multiple hypothesis prediction.

28. The method of claim 24, wherein the merge candidate list is a constructed candidate list / virtual candidate list including at least one merge candidate.

29. The method of claim 24, wherein the at least one motion vector predictor is in the process of being pruned with at least one other merge candidate.

30. The method of claim 22 or 23, wherein the candidate list comprises an AMVP candidate list.

31. The method of claim 30, wherein the AMVP candidate list is used for at least one of the following: Regular AMVP mode, or A variation of the AMVP model.

32. The method of claim 30, wherein the AMVP candidate list is an AMVP-based additional hypothesis motion candidate list for multiple hypothesis prediction.

33. The method of claim 30, wherein the AMVP candidate list is a constructed candidate list / virtual candidate list containing at least one AMVP candidate.

34. The method of claim 30, wherein the at least one motion vector predictor is in a pruning process with at least one other AMVP candidate.

35. The method of any one of claims 22 to 34, wherein the total number of motion vector predictors is no greater than a first threshold.

36. The method of claim 35, wherein if the first threshold is 0, the at least one motion vector predictor is not used.

37. The method of claim 35, wherein: The first threshold is indicated from the encoder side to the decoder side.

38. The method of claim 35, wherein: The first threshold is derived based on codec information of the target block.

39. The method of claim 38, wherein: The first threshold is derived based on dimensional information of the target block. 40 . The method of claim 39 , wherein if a width of the target block is greater than a first width or a height of the target block is greater than a first height, the first threshold is 0. The method of claim 40 , wherein the first width and the first height are 16.

42. The method of claim 39, wherein if a width of the target block is greater than a first width and a height of the target block is greater than a first height, the first threshold is 0. The method of claim 42 , wherein the first width and the first height are 16.

44. The method according to any one of claims 24 to 29, wherein: The first set of at least one motion vector predictor is placed in the merge candidate list before a k-th spatial merge candidate, and wherein k is an integer.

45. The method according to any one of claims 24 to 29, wherein: The second set of at least one motion vector predictor is placed in the merge candidate list and after a k-th spatial merge candidate of the candidate list, and wherein k is an integer.

46. ​​The method of any one of claims 24 to 29, wherein the third set of at least one motion vector predictor is placed in the merge candidate list before a temporal motion vector prediction (TMVP) merge candidate.

47. The method of any one of claims 24 to 29, wherein a fourth set of the at least one motion vector predictor is placed in the merge candidate list after a TMVP merge candidate.

48. The method of any one of claims 24 to 29, wherein a fifth set of the at least one motion vector predictor is placed in the merge candidate list before a k-th non-adjacent merge candidate, and wherein k is an integer.

49. The method of any one of claims 24 to 29, wherein a sixth set of the at least one motion vector predictor is placed in the merge candidate list after a k-th non-adjacent merge candidate, and wherein k is an integer.

50. The method of any one of claims 24 to 29, wherein the seventh set of at least one motion vector predictor is placed in the merge candidate list and before the kth history-based motion vector prediction (HMVP) merge candidate, and wherein k is an integer.

51. The method of any one of claims 24 to 29, wherein an eighth set of the at least one motion vector predictor is placed in the merge candidate list after the kth merge candidate, and wherein k is an integer.

52. The method of any one of claims 24 to 29, a ninth set of the at least one motion vector predictor is placed in the merge candidate list before the kth zero merge candidate, and wherein k is an integer.

53. The method of any one of claims 30 to 34, wherein the first set of at least one motion vector predictor is placed in the AMVP candidate list before the k-th spatial AMVP candidate, and wherein k is an integer.

54. The method of any one of claims 30 to 34, wherein the second set of at least one motion vector predictor is placed in the AMVP candidate list after the kth spatial AMVP candidate, and wherein k is an integer.

55. The method of any one of claims 30 to 34, wherein the third set of at least one motion vector predictor is placed in the AMVP candidate list and before a temporal motion vector prediction (TMVP) AMVP candidate.

56. The method of any one of claims 30 to 34, wherein a fourth set of the at least one motion vector predictor is placed into the AMVP candidate list after TMVP AMVP candidates.

57. The method of any one of claims 30 to 34, wherein a fifth set of the at least one motion vector predictor is placed in the AMVP candidate list before a k-th non-adjacent AMVP candidate, and wherein k is an integer.

58. The method of any one of claims 30 to 34, wherein a sixth set of the at least one motion vector predictor is placed in the AMVP candidate list after a k-th non-adjacent AMVP candidate, and wherein k is an integer.

59. A method according to any one of claims 30 to 34, wherein the seventh set of at least one motion vector predictor is placed in the AMVP candidate list and before the kth history-based motion vector prediction (HMVP) AMVP candidate, and wherein k is an integer.

60. The method of any one of claims 30 to 34, wherein an eighth set of the at least one motion vector predictor is placed in the AMVP candidate list after the kth AMVP candidate, and wherein k is an integer.

61. The method of any one of claims 30 to 34, wherein a ninth set of the at least one motion vector predictor is placed in the AMVP candidate list before the kth zero AMVP candidate, and wherein k is an integer.

62. The method according to claim 22 or 23, wherein whether and / or how to use the at least one motion vector predictor inserted into the candidate list depends on codec information of the target block.

63. The method of claim 62, wherein the candidate list comprises at least one of: Merge the list, AMVP list, Based on the merged list of sub-blocks, or Regular merge list. The method according to claim 62, wherein the codec information indicates dimension information of the target block.

65. The method of claim 64, wherein if a width of the target block is greater than a first width or a height of the target block is greater than a first height, a motion vector predictor is not used.

66. The method of claim 62, wherein the first width and the first height are 16 or 8.

67. The method of claim 64, wherein if a width of the target block is greater than a first width and a height of the target block is greater than a first height, a motion vector predictor is not used.

68. The method of claim 67, wherein the first width and the first height are 16 or 8.

69. The method of claim 62, wherein the codec information indicates temporal layer information of the target block.

70. The method of claim 69, wherein if the number of temporal layers of the target block is above a second threshold, a motion vector predictor is not used, or in, If the number of temporal layers of the target block is less than the second threshold, the motion vector predictor is not used.

71. The method of claim 70, wherein the second threshold is 2.

72. The method of claim 62, wherein the codec information indicates whether all reference pictures precede a current picture associated with the target block in display order.

73. The method of claim 72, wherein a motion vector predictor is not used if all reference pictures precede the current picture in the display order.

74. The method of claim 62, wherein the codec information indicates whether all reference pictures are located after a current picture associated with the target block in display order.

75. The method of claim 74, wherein a motion vector predictor is not used if all reference pictures follow the current picture in the display order.

76. The method according to claim 62, wherein the codec information indicates a syntax element, and the syntax element is used to indicate whether the MVD of reference list 1 is 0.

77. The method of claim 76, wherein the syntax element is ph_mvd_l1_zero_flag.

78. The method of claim 76, wherein if the syntax element is equal to a particular value, a motion vector predictor is not used.

79. The method of claim 78, wherein the specific value is 1.

80. The method of claim 62, wherein the codec information indicates a number of reference lists.

81. The method of claim 80, wherein if the number of reference lists is equal to a specific value, a motion vector predictor is not used.

82. The method of claim 81, wherein the specific value is 1.

83. The method of claim 62, wherein the codec information indicates a picture order count (POC) of at least one reference picture.

84. The method of claim 83, wherein if the POC of reference picture 0 in reference list 0 is within a predetermined range, a motion vector predictor is not used.

85. The method of claim 84, wherein the predetermined range is [POCcur-k1, POCcur+k2], where POCcur is the POC of the current picture associated with the target block, and k1 and k2 are integers.

86. The method of claim 85, wherein k1 and k2 are equal to 1.

87. A method according to any one of claims 1 to 86, wherein the conversion includes encoding the target block into the bitstream.

88. A method according to any one of claims 1 to 86, wherein the conversion comprises decoding the target block from the bitstream.

89. A device for processing video data, comprising a processor and a non-volatile memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform a method according to any one of claims 1-88.

90. A non-transitory computer-readable storage medium storing instructions for causing a processor to execute the method according to any one of claims 1-88.

91. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein the method comprises: deriving a motion vector predictor for a target block of the video from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; as well as A bitstream of the target block is generated based on the motion vector predictor.

92. A method for storing a bitstream of a video, comprising: deriving a motion vector predictor for a target block of the video from a parameter table storing a set of affine parameters from at least one previously coded block, the target block being a non-affine coded block; generating a bitstream of the target block based on the motion vector predictor; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

93. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein the method comprises: determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; as well as A bitstream of the target block is generated based on the candidate list.

94. A method for storing a bitstream of a video, comprising: determining at least one motion vector predictor derived using an affine model for a target block of the video; inserting the motion vector predictor into at least one position in a candidate list; generating a bitstream of the target block based on the candidate list; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

Images