Patent Description:
Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of pictures, each picture having a spatial dimension of, for example, <NUM> x <NUM> luminance samples and associated chrominance samples. The series of pictures can have a fixed or variable picture rate (informally also known as frame rate), of, for example <NUM> pictures per second or <NUM>. Uncompressed video has significant bitrate requirements. For example, 1080p60 <NUM>:<NUM>:<NUM> video at <NUM> bit per sample (1920x1080 luminance sample resolution at <NUM> frame rate) requires close to <NUM> Gbit/s bandwidth. An hour of such video requires more than <NUM> GBytes of storage space.

In some video compression techniques, an MV applicable to a certain area of sample data can be predicted from other MVs, for example from those related to another area of sample data spatially adjacent to the area under reconstruction, and preceding that MV in decoding order. Doing so can substantially reduce the amount of data required for coding the MV, thereby removing redundancy and increasing compression. MV prediction can work effectively, for example, because when coding an input video signal derived from a camera (known as natural video) there is a statistical likelihood that areas larger than the area to which a single MV is applicable move in a similar direction and, therefore, can in some cases be predicted using a similar motion vector derived from MVs of neighboring area. That results in the MV found for a given area to be similar or the same as the MV predicted from the surrounding MVs, and that in turn can be represented, after entropy coding, in a smaller number of bits than what would be used if coding the MV directly. In some cases, MV prediction can be an example of lossless compression of a signal (namely: the MVs) derived from the original signal (namely: the sample stream). In other cases, MV prediction itself can be lossy, for example because of rounding errors when calculating a predictor from several surrounding MVs.

Various MV prediction mechanisms are described in H. <NUM>/HEVC (ITU-T Rec. <NUM>, "High Efficiency Video Coding", December <NUM>). Out of the many MV prediction mechanisms that H. <NUM> offers, described here is a technique henceforth referred to as "spatial merge".

Referring to <FIG>, a current block (<NUM>) comprises samples that have been found by the encoder during the motion search process to be predictable from a previous block of the same size that has been spatially shifted. Instead of coding that MV directly, the MV can be derived from metadata associated with one or more reference pictures, for example from the most recent (in decoding order) reference picture, using the MV associated with either one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (<NUM> through <NUM>, respectively). <NUM>, the MV prediction can use predictors from the same reference picture that the neighboring block is using.

<CIT> concerns an apparatus that comprises a memory, and a processor coupled to the memory and configured to obtain candidate MVs corresponding to neighboring blocks that neighbor a current block in a video frame, generate a candidate list of the candidate MVs, select final MVs from the candidate list, and apply constraints to the final MVs or a transformation to obtain constrained MVs.

The present invention concerns a method for video decoding in a decoder according to claim <NUM>, and an apparatus for video decoding according to claim <NUM>. Further aspects of the present invention are defined in the dependent claims. Aspects of the disclosure provide methods and apparatuses for video encoding/decoding. In some examples, an apparatus for video decoding includes receiving circuitry and processing circuitry.

A streaming system may include a capture subsystem (<NUM>), that can include a video source (<NUM>), for example a digital camera, creating for example a stream of video pictures (<NUM>) that are uncompressed. In an example, the stream of video pictures (<NUM>) includes samples that are taken by the digital camera. The stream of video pictures (<NUM>), depicted as a bold line to emphasize a high data volume when compared to encoded video data (<NUM>) (or coded video bitstreams), can be processed by an electronic device (<NUM>) that includes a video encoder (<NUM>) coupled to the video source (<NUM>). The video encoder (<NUM>) can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter as described in more detail below. The encoded video data (<NUM>) (or encoded video bitstream (<NUM>)), depicted as a thin line to emphasize the lower data volume when compared to the stream of video pictures (<NUM>), can be stored on a streaming server (<NUM>) for future use. One or more streaming client subsystems, such as client subsystems (<NUM>) and (<NUM>) in <FIG> can access the streaming server (<NUM>) to retrieve copies (<NUM>) and (<NUM>) of the encoded video data (<NUM>). A client subsystem (<NUM>) can include a video decoder (<NUM>), for example, in an electronic device (<NUM>). The video decoder (<NUM>) decodes the incoming copy (<NUM>) of the encoded video data and creates an outgoing stream of video pictures (<NUM>) that can be rendered on a display (<NUM>) (e.g., display screen) or other rendering device (not depicted). In some streaming systems, the encoded video data (<NUM>), (<NUM>), and (<NUM>) (e.g., video bitstreams) can be encoded according to certain video coding/compression standards. Examples of those standards include ITU-T Recommendation H. In an example, a video coding standard under development is informally known as Versatile Video Coding (VVC). The disclosed subject matter may be used in the context of VVC.

<FIG> shows a block diagram of a video encoder (<NUM>) The video encoder (<NUM>) is included in an electronic device (<NUM>).

), any color space (for example, BT. <NUM> Y CrCB, RGB,.

The video encoder (<NUM>) may code and compress the pictures of the source video sequence into a coded video sequence (<NUM>) in real time or under any other time constraints as required by the application. In some situations, the controller (<NUM>) controls other functional units as described below and is functionally coupled to the other functional units.

In some situations, the video encoder (<NUM>) is configured to operate in a coding loop.

The transmitter (<NUM>) may transmit additional data with the encoded video.

In some situations, a bi-prediction technique can be used in the inter-picture prediction.

<FIG> shows a diagram of a video encoder (<NUM>) The video encoder (<NUM>) is configured to receive a processing block (e.g., a prediction block) of sample values within a current video picture in a sequence of video pictures, and encode the processing block into a coded picture that is part of a coded video sequence.

In various situations, the video encoder (<NUM>) also includes a residue decoder (<NUM>).

Aspects of the disclosure are directed to affine merge and affine motion vector coding. The disclosed methods can be used in advanced video codecs (e.g., AVC) to improve the coding performance of affine inter prediction. A motion vector can refer to a block mode, in which one whole block uses a set of motion information, such as the merge candidates in the HEVC standard. Further, the motion vector can refer to a sub-block mode, in which different sets of motion information may apply for different parts of the block, such as in an affine mode and an advanced temporal MV prediction (ATMVP) in the VVC standard.

Generally, a motion vector for a block can be coded either in an explicit way, to signal the difference to a motion vector predictor (e.g., advanced motion vector prediction or AMVP mode); or in an implicit way, to be indicated completely from one previously coded or generated motion vector. The later one is referred to as a merge mode, meaning the current block is merged into a previously coded block by using its motion information.

In both the AMVP mode and the merge mode, a candidate list is constructed during decoding. <FIG> shows examples of spatial and temporal candidates. For the merge mode in the inter prediction, merge candidates in a merge candidate list can be formed by checking motion information from either spatial and/or temporal neighboring blocks of the current block. In the <FIG> example, spatial candidate blocks A1, B1, B0, A0, and B2 are sequentially checked. When one or more of the spatial candidate blocks are valid candidates (e.g., are coded with motion vectors), the motion information of the one or more valid candidate blocks can be added into the merge candidate list. A pruning operation can be performed to ensure that duplicated candidates are not included in the merge candidate list, e.g., are not added into the list again. The candidate blocks A1, B1, B0, A0, and B2 are adjacent to corners of the current block, and can be referred to as corner candidates.

After the spatial candidates are checked, temporal candidates can be checked for inclusion into the list. In some examples, a co-located block of the current block is found in a specified reference picture. The motion information at the C0 position (e.g., at the bottom right corner of the current block) of the co-located block can be used as a temporal merge candidate when available. If the block at this position is not coded in inter mode or is not otherwise available, the C1 position (e.g., at the bottom right corner adjacent to the center of the co-located block) can be used instead. The present disclosure provides techniques to further improve the merge mode.

In the advanced motion vector prediction (AMVP) mode, motion information of spatial and temporal neighboring blocks can be used to predict the motion information of the current block. The prediction residue is further coded. Examples of the spatial and temporal neighboring candidates are illustrated in <FIG>.

In some aspects, a two-candidate motion vector predictor list is formed in the AMVP mode. For example, the two-candidate motion vector predictor list includes a first candidate predictor and a second candidate predictor. The first candidate predictor is an available motion vector from the left edge, for example a first available motion vector in the order of spatial A0, A1 positions. The second candidate predictor is an available motion vector from the top edge, for example a first available motion vector in the order of spatial B0, B1 and B2 positions. If a valid motion vector cannot be found from the checked locations (e.g., for the left edge and the top edge), none of the candidate predictors will be added to the list. If the two candidate predictors are available and are the same, only one will be kept in the list. If the list is not full (with two different candidates), the temporal co-located motion vector (after scaling) from the C0 location can be used as another candidate. If motion information at the C0 location is not available, the C1 location can be used instead.

In some examples, if there are still not enough motion vector predictor candidates, a zero motion vector will be used to fill up the list.

According to an aspect of the disclosure, affine motion compensation, by describing a <NUM>-parameter (or a simplified <NUM>-parameter) affine model for a coding block, can efficiently predict the motion information for samples within the current block. More specifically, in an affine coded or described coding block, different parts of the samples can have different motion vectors. The basic unit having a motion vector in an affine coded or described block can be referred to as a sub-block. The size of the sub-block can be as small as <NUM> sample only; and can be as large as the size of current block.

In an affine mode, a motion vector (relative to the targeted reference picture) can be derived for each sample in the current block using a model such as the <NUM> parameter affine motion model or <NUM> parameter affine motion model. In order to reduce implementation complexity, affine motion compensation can be performed on a sub-block basis, instead of on a sample basis. That means, a motion vector will be derived for each sub-block the motion vector is the same for samples in a respective sub-block. A specific location of each sub-block can be assumed, such as the top-left or the center point of the sub-block, to be a representative location. In one example, such a sub-block size contains 4x4 samples.

An affine motion model can have <NUM> parameters to describe the motion information of a block. After the affine transformation, a rectangular block will become a parallelogram. In an example, the <NUM> parameters of an affine coded block can be represented by <NUM> motion vectors at three different locations of the block. <FIG> shows an example in which <NUM> corners of the block can be used. The locations of the corners in <FIG> can be referred to as control ponints.

<FIG> shows an example of an affine coded block (<NUM>). The block (<NUM>) is represented by motion vectors v<NUM>, v<NUM>, and v<NUM> at three corner locations A, B, and C to describe the motion information of the affine motion model used for the block (<NUM>). As described above, these locations A, B, and C can be referred to as control points.

An affine motion model can use <NUM> parameters to describe the motion information of a block based on an assumption that after the affine transformation, the shape of the block does not change. Therefore, a rectangular block will remain rectangular and with the same aspect ratio (e.g., height/width) after the transformation. The affine motion model of such a block can be represented by two motion vectors at two different locations, such as at the corner locations A and B.

<FIG> shows examples of affine transformations for a <NUM>-parameter affine mode (using a <NUM>-parameter affine model) and a <NUM>-parameter affine mode (using a <NUM>-parameter affine model). When assumptions are made such that the object only has zooming and translational motions, or the object only has rotation and translation models, then the affine motion model can be further simplified to a <NUM>-parameter affine motion model with <NUM> parameters to indicate the translational part and <NUM> parameter to indicate either a scaling factor for zooming or an angular factor for rotation.

According to an aspect of the disclosure, when affine motion compensation is used, two signaling techniques can be used. The two signaling techniques can be referred to as a merge mode based signaling technique and a residue (AMVP) mode based signaling technique.

In the merge mode, the affine information of the current block is predicted from previously affine coded blocks. In one method, the current block is assumed to be in the same affine object as the reference block, so that the MVs at the control points of the current block can be derived from a model of the reference block. The MVs at other locations of the current block can be linearly modified in the same way as from one control point to another in the reference block. This method can be referred to as a model based affine prediction. An example of the model based affine prediction, or model based inherited affine prediction, is illustrated in <FIG>.

In another method, motion vectors of neighboring blocks can be used directly as the motion vectors at control points of a current block. Motion vectors for the rest of the block can then be generated using information from the control points. This method can be referred to as control point based constructed affine prediction. In either method, no residue components of the MVs at current block are to be signaled. In other words, the residue components of the MVs are assumed to be zero. An example of the control point based affine prediction is illustrated in <FIG>.

For the residue (AMVP) mode based signaling technique, affine parameters, or the MVs at the control points of the current block, are to be predicted. Because there is more than one motion vector to be predicted, the candidate list for motion vectors at the control points (e.g., all the control points) is organized in grouped way such that each candidate in the list includes a set of motion vector predictors for the control points. For example, candidate <NUM>={predictor for control point A, predictor for control point B, predictor for control point C }; candidate <NUM>={ predictor for control point A, predictor for control point B, predictor for control point C }, etc. The predictor for the same control point in different candidates can be the same or different. The motion vector predictor flag ((mvp_l0_flag for List <NUM> or mvp_l1_flag for List <NUM>) can be used to indicate which candidate from the list is chosen. After prediction, the residue part of the parameter, or the differences of the actual MVs to the MV predictors at the control points, are to be signaled. The MV predictor at each control point can also be derived from model based affine prediction from one of its neighbors, using the method described from the above description for merge mode based signaling technique.

The method can be illustrated based on a <NUM>-parameter affine model with <NUM> control points (e.g., CPO and CP1), as shown in <FIG>. However, <FIG> is a merely example and the methods in the disclosure can be extended to other motion models, or affine models with different numbers of parameters. In some embodiments, the model used may not always be an affine model, but other types of motion.

In an example, a <NUM>-parameter affine model is described, such as shown by equation (<NUM>) <MAT> , where ρ is the scaling factor for zooming, θ is the angular factor for rotation, and (c, f) is the motion vector to describe the translational motion. (x, y) is a pixel location in the current picture, (x', y') is a corresponding pixel location in the reference picture.

Let a = ρcos θ, and let b = ρsin θ, equation (<NUM>) may become the following form as in equation (<NUM>) <MAT> Thus, a <NUM>-parameter affine model can be represented by a set of model-based parameters {ρ, θ, c, f}, or {a, b, c, f}. Based on Eq. <NUM>, motion vector (MVx, MVy) at a pixel position (x, y) can be described as in equation (<NUM>). <MAT> , where Vx is a horizontal motion vector value, and Vy is a vertical motion vector value.

The <NUM>-parameter affine model can also be represented by the motion vectors of two control points, CPO and CP1, of the block. Similarly, three control points may be required to represent a <NUM>-parameter affine model. To derive the motion vector at position (x, y) in the current block, a following equation (<NUM>) can be used: <MAT> , where (v0x, v0y) is a motion vector of the top-left corner control point, CPO as depicted in <FIG>, and (v1x, v1y) is a motion vector of the top-right corner control point, CP1 as depicted in <FIG>. (v0x, v0y) and (v1x, v1y) can also be referred to as control point motion vectors (CMPWs), such as CPMV<NUM> (v0x, v0y) and CPMV<NUM> (v1x, v1y). Accordingly, in the control-point based model, the affine model of the block can be represented by {v<NUM>x, v<NUM>y, v<NUM>x, v1y, }, or {CPMV<NUM>, CMPV<NUM>}.

Similarly, three control points can be required to represent a <NUM>-parameter affine model, including CP0, CP1, and CP2, as depicted in <FIG>. And alternatively, the <NUM>-parameter affine model can be described in the following equation (<NUM>). <MAT> And motion vector values at position (x, y) in the block can be described by equation (<NUM>). <MAT> The <NUM>-parameter affine model can also be represented by control point motion vectors, such as {CPMV<NUM>, CPMV<NUM>, CPMV<NUM>}.

In methods of deriving affine merge/AMVP predictors, the difference among control point motion vectors (CPMVs) of a block can be very large, especially when the affine merge/AMVP predictors are derived by using control point based constructed affine prediction. In such a case, the affine parameters derived based on the CPMVs can become very large, which can be interpreted as very large affine transformations, such as zooming or warping. When the affine parameters reach a certain range, the corresponding affine transformation can become impractical in video coding, and the derived CPMV values can be out of the reasonable range, such as pointing to locations far beyond picture boundaries, or requiring too many bits to encode/decode the motion vector difference when the affine AMVP mode is applied. In addition, the large CPMVs, as well as other MVs in affine coded sub-blocks (which are derived from CPMVs), can be used as motion vector predictors in the later coding block. Too large or impractical MV predictors can also cause issues.

In the disclosure, methods are developed to constrain the range of CPMVs in affine motion compensation to avoid generating invalid or impractical predictors. For example, some constraints (limits) can be added to the range of a CPMV. In an embodiment, a constraint for motion vector difference (MVD) coding is set. In one example, both a MVD of translational motion and a MVD of affine motion are constrained. In another example, only one of the MVD of translational motion or the MVD of affine motion is constrained. The range of MVD can be constrained to a predefined value (for each MVD component), or a certain number of bits, such as <NUM> bits. Alternatively, the range of MVD can be signaled in a bitstream, such as in a sequence parameter set (SPS), picture parameter set (PPS), or slice header. The constraint can be a conforming constraint such that a bitstream which contains a MVD beyond the constraint is regarded as an invalid bitstream. Alternatively, when the MVD is beyond the range, the MVD can be clipped by the range accordingly.

A threshold can set to limit value ranges of motion vector predictors for the CPMVs in affine motion compensation. The threshold can set to limit affine parameter values of affine predictors.

In the disclosure, the proposed methods can be used separately or combined in any order. The term "block" in the disclosure can be interpreted as a prediction block, a coding block, or a coding unit (i.e., CU).

When the affine AMVP mode is applied, a constraint can be applied on motion vector difference coding for affine CPMVs and for translational MVs. In addition, a constraint can be applied on a motion vector difference (MVD) for each control point by using a predefined limit.

The motion vector difference can be obtained based on the difference between an optimal CPMV of each control point and the corresponding CPMV's predictor (CPMVP). For example, for control point <NUM>, the motion vector difference may be calculated as in equation (<NUM>): <MAT> Each CPMV for a respective control point in the block, which is derived based on the corresponding affine predictor, can have a horizontal component and a vertical component. Accordingly, a horizontal component of the motion vector difference for control point <NUM> can be calculated as in equation (<NUM>): <MAT> A vertical component of the motion vector difference for control point <NUM> can be calculated as in equation (<NUM>): <MAT> MVDs for control point <NUM> and/or control point <NUM> can be calculated in a similar procedure that is described in equations (<NUM>)-(<NUM>).

In one embodiment, the number of bits used to represent the horizontal component or vertical component of a control point's MVD can be limited to be a predefined range. In one example, the limit can be set to be N bits, such as N=<NUM>. Accordingly, for a affine motion predictor of a block, if the number of bits required to represent a horizontal or a vertical component of a MVD of any control point exceeds the predefined limit (e.g., <NUM> bits), the predictor can be pruned or cannot be used as an affine AMVP predictor. In another example, for any control point of the block that is under a certain MVD coding precision (e.g., <NUM>/<NUM> sample precision), when abs(MVDx) of the control point is >= <NUM><NUM> or abs(MVDy) of the control point is >= <NUM><NUM>, the corresponding affine predictor cannot be used as an affine CPMV predictor in the affine AMVP mode. abs(x) herein means an absolute value of x.

It should be noted that the predefined limit mentioned above can be any value, which is not limited by the aforementioned example. Further, the proposed methods mentioned above for MVD constraints can also be applied to translational (regular) MVs.

When the affine merge mode or the affine AMVP mode is applied, a constraint can be applied on the value ranges of the affine CMPV predictors (affine predictor), where values of the derived affine CPMV predictors can be constrained by a predefined limit.

In one embodiment, the value of the horizontal component or the vertical component of any CPMV of the affine predictor can be constrained by a predefined limit. In one example, the limit can be set to be N bits, such as N=<NUM>. When a certain motion vector storage precision is applied (e.g., <NUM>/<NUM> sample precision), if the horizontal component or the vertical component of any CPMV of the affine CPMV predictor is larger than or equal to <NUM><NUM> in an absolute value, the predictor can be pruned or cannot be used as an affine CPMV predictor in the affine AMVP mode. The predefined limit of motion vector can be any value, which is not limited by the example mentioned above.

In one embodiment, a luma sample position that any CPMV of the affine predictor is pointing to can be limited to a predefined range. The limit can be set to a predefined number of luma samples beyond each edge of the current picture's boundary. In one example, as shown in <FIG>, the limit can be set to be N luma samples, and N can be <NUM>. If any CPMV of the affine CPMV predictor points to more than <NUM> luma samples beyond any edge of the current picture, the corresponding affine predictor can be pruned and cannot be added to the predictor list. For example, as shown in <FIG>, all CPMVs of affine predictor A point to positions within the limited range, thus affine predictor A can be a valid predictor. However, one CPMV of the affine predictor B points to a position beyond the limited range (e.g., <NUM> luma samples), thus the affine predictor B is invalid, and cannot be added to the predictor list.

In one embodiment, the luma sample position that any CPMV of the affine predictor is pointing to can be limited to different predefined ranges (limits). The ranges can be different on a vertical direction and a horizontal direction. An example can be illustrated in <FIG>, where the limit in the horizontal direction has a predefined value of <NUM> luma samples that is different from the limit in the vertical direction which is <NUM> luma samples. It should be noted that <FIG> is merely an example and the number of luma samples used as the constraint on the vertical and/or horizontal directions can be any predefined values.

The luma sample position that any CPMV of the affine predictor is pointing to can also be limited to a predefined percentage of width and/or height of the current picture outside of the corresponding edges of the current picture boundary. In one example, a same percentage can be applied on both the current picture width along the horizontal direction and current picture height along the vertical direction. As shown in <FIG>, the limit can be set to be <NUM>% of the picture width in the horizontal direction, and <NUM>% of the picture height in the vertical direction. <FIG> is a merely example, the number of percentage used as the constraint on the vertical and/or horizontal directions can be any predefined values.

Further, different percentages can be applied on the current picture width along the horizontal direction and on the current picture height along the vertical direction. As shown in <FIG>, the limit can be set to <NUM>% of the picture width in the horizontal direction, and <NUM>% of the picture height in the vertical direction. The percentages used as the constraint in the vertical and/or horizontal directions in <FIG> are merely examples, and the percentages can be any predefined values.

When constraints are applied on affine parameter values of the affine predictors, affine predictors violating the constraints can be eliminated from the predictor list. Exemplary constraints can be described based on the affine merge mode. According to the affine model equations (<NUM>) and (<NUM>), the CPMV values of CPO represent the translational MV of the block, and CPMVs of CP1/CP2 reflects the shape transformation from affine model plus the translational model. Let W and H denote the current block's width and height, respectively.

In the <NUM>-parameter case, the control point motion vectors can be calculated as:.

The delta (difference) between CP1 and CP0, CP2 and CP0, can represent the affine transformation part of the affine model, and the delta values can fall in a reasonable range. Let D1 denote the delta between CPMV1 and CPMV0, which is: <MAT> In the <NUM>-parameter model case, let D2 denote the delta between CPMV2 and CPMV0, which is: <MAT> Since D1 only includes affine parameter a, d, and block width W, a ratio R1 can be defined to represent the affine parameter value range in D1, where <MAT> Similarly, since D2 only includes affine parameter b, e, and block height H, a ratio R2 can be defined to represent the affine parameter value range in D2, where <MAT> R1 and R2 can also be represented by CPMV values, as in following equations: <MAT> <MAT>.

In the proposed method, constraints can be applied to R1 and/or R2 as the constraint for the affine CPMV predictors. In the <NUM>-parameter affine model, a predefined threshold can be applied on R1. In the <NUM>-parameter affine model, a predefined threshold can be applied on R1 and/or R2. The ratio R1 and/or R2 can be denoted in a generalized form R. The disclosed method can be used for the <NUM>-parameter affine model and the <NUM>-parameter affine model, whenever the method is applicable. When the constraint is violated, the corresponding affine predictor can be excluded from the predictor list.

In an embodiment, a predefined threshold can be applied on a maximum value from the horizontal and the vertical components of ratio R. In an example, the threshold value can be set to be <NUM> with the MV storage precision, such as <NUM>/<NUM> pixel accuracy. Accordingly, the threshold value is equal to <NUM> pixel. For a <NUM>-parameter affine predictor with CPMV0 (MV0x, NW0y), CPMV1(MV1x, MV1y), and CPMV2(MV2x, MV2y), the ratio R1 and R2 can be described in equations (<NUM>) and (<NUM>): <MAT> <MAT> For R1, the maximum component, which is denoted as max(|MVl1x - MV0x| / W, |MV1y - MV0y| / W), can be checked against the threshold value. For R2, the maximum component, which is denoted as max(|MV2x - MV0x| / H, |MV2y - MV0y| / H), can also be check against the threshold value. When any of the following conditions (a) and (b) is true, the affine predictor can be considered invalid and cannot be added to the final predictor list. <MAT> <MAT> It should be noted that the predefined threshold value is not limited to the above example. For example, the predefined threshold can be defined as a value larger than <NUM>. Under the <NUM>/<NUM> pixel accuracy, the predefined threshold accordingly is equal to ½ pixel.

In some embodiments, a predefined limit can be applied on a minimum value from the horizontal and the vertical components of ratio R. Different predefined limits can be applied on the horizontal component of ratio R and the vertical component of ratio R. Further, the limits may be signaled in bitstreams, such as in SPS, PPS, or slice header.

<FIG> shows a flow chart outlining a process (<NUM>) according to an embodiment of the disclosure. The process (<NUM>) can be used in the reconstruction of a block coded in intra mode, so to generate a prediction block for the block under reconstruction. In various embodiments, the process (<NUM>) are executed by processing circuitry, such as the processing circuitry in the terminal devices (<NUM>), (<NUM>), (<NUM>) and (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), and the like. In some embodiments, the process (<NUM>) is implemented in software instructions, thus when the processing circuitry executes the software instructions, the processing circuitry performs the process (<NUM>). The process starts at (S1901) and proceeds to (S1910).

At (S1910), prediction information of a block in a current picture can be decoded from a coded video bitstream. The prediction information includes a plurality of offset indices for prediction offsets associated with an affine model in an inter prediction mode. The block includes two or more control points.

At (S1920), a motion vector for each of the two or more control points can be determined based on a corresponding motion vector predictor for the respective control point. The corresponding motion vector predictor for the respective control point can be a first predictor of a plurality of candidate motion vector predictors in a candidate list and meets a signaled constraint that is associated with a motion vector of the corresponding motion vector predictor. The signaled constraint can be received with the coded video bitstream. For example, the constraint may be signaled in the SPS, PPS, or slice header.

At (S1930), parameters of the affine model can be determined based on the determined motion vectors of the two or more control points. The parameters of the affine model can be used to transform between the block and a reference block in a reference picture that has been reconstructed.

At (S1940), samples of the block are reconstructed according to the affine model. In an example, a reference pixel in the reference picture that corresponds to a pixel in the block is determined according to the affine model. Further, the pixel in the block is reconstructed according to the reference pixel in the reference picture. Then, the process proceeds to (S1999) and terminates.

In the disclosure, the proposed methods can be used separately or combined in any order. Further, the methods (or embodiments) may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In an example, the one or more processors execute a program that is stored in a non-transitory computer-readable medium.

Computer system (<NUM>) can also include an interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, <NUM>, <NUM>, <NUM>, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (<NUM>) (such as, for example USB ports of the computer system (<NUM>)); others are commonly integrated into the core of the computer system (<NUM>) by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system (<NUM>) can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

Claim 1:
A method for video decoding in a decoder, comprising:
decoding prediction information of a current block in a current picture from a coded video bitstream, the prediction information being indicative of an affine model, the current block including two or more control points;
determining a motion vector for each of the two or more control points based on a corresponding motion vector predictor for the respective control point, the corresponding motion vector predictor for the respective control point being a first predictor of a plurality of candidate motion vector predictors in a candidate list and meeting a constraint that is associated with a motion vector of the corresponding motion vector predictor;
determining parameters of an affine model based on the determined motion vectors of the two or more control points, the parameters of the affine model being used to transform between the current block and a reference block in a reference picture that has been reconstructed; and
reconstructing at least a sample of the current block according to the affine model, wherein the constraint indicates:
a fifth limit from a width picture boundary for a first luma sample position to which a motion vector associated with a control point of the corresponding motion vector predictor of the one of the two or more control points refers, the fifth limit being defined by a first number of luma samples beyond the width picture boundary of the current picture; and
a sixth limit from a height picture boundary for a second luma sample position to which the motion vector associated with the control point of the corresponding motion vector predictor of the one of the two or more control points refers, the sixth limit being defined by a second number of luma samples beyond the height picture boundary of the current picture, wherein
the fifth limit is a predefined first percentage of a width of the current picture, and
the sixth limit is a predefined second percentage of a height of the current picture.