Video picture encoding method, video data encoding device, program, and data structure

By analyzing the bitstream, determining the applicability of the affine motion model of the video image block, transmitting only necessary parameters, and constructing a list of candidate motion vectors, solving the problem of increasing the length of the encoded video sequence in the prior art, and achieving more efficient decoding processing.

JP2025020336AActive Publication Date: 2025-02-12HUAWEI TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024195173
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2018-08-27
Filing Date
2024-11-07
Publication Date
2025-02-12
Estimated Expiration
2039-04-17

AI Technical Summary

Technical Problem

In existing video encoding techniques, motion estimation/motion compensation using non-translational motion models increases the length of the encoded video sequence, resulting in increased decoding load and increased processing time.

Method used

By analyzing the bitstream to determine whether the affine motion model is applicable to the image block, the relevant parameters are transmitted only when the conditions are met, the decoder avoids analyzing the affine motion model parameters, and a four-parameter or six-parameter affine motion model is used to construct a list of candidate motion vectors to optimize the prediction mode.

Benefits of technology

Reduces the length of the encoded video sequence, reduces the decoder load, and improves processing speed and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025020336000001_ABST
    Figure 2025020336000001_ABST
Patent Text Reader

Abstract

To provide a video picture prediction method and an apparatus which reduce the length of an encoded video sequence, reduce the load on a decoder, increase the processing speed, and decrease the processing time.SOLUTION: The method comprises adding a first type of identifier and a second type of identifier to a bitstream. The first type of identifier is used to indicate whether an affine motion model-based inter-prediction mode is enabled for a video picture. The second type of identifier is used to indicate whether the affine motion model-based inter-prediction mode is enabled for a slice in the video picture. For a slice for which the affine motion model does not need to be used, a parameter, related to the affine motion model, of a picture block does not need to be transmitted. On a decoder side, during decoding of the picture block, the parameter related to the affine motion model does not need to be parsed.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] This application claims priority to Chinese Patent Application No. 201810983026.0, entitled "Video Image Prediction Method and Apparatus," filed with the China Patent Office on August 27, 2018, the entire contents of which are incorporated herein by reference.

[0002] The present application relates to the field of image encoding and decoding technology, and in particular to a video image prediction method and apparatus. [Background technology]

[0003] With the development of information technology, video services such as high definition television, web conferencing, IPTV and 3D television are rapidly developing. Due to its features such as intuitiveness and high efficiency, video signals have become the main way of obtaining information in people's daily life. Since video signals contain a large amount of data, they occupy a large amount of transmission bandwidth and storage space. In order to transmit and store video signals efficiently, compression encoding needs to be performed on the video signals. Video compression technology has become an increasingly indispensable key technology in the field of video applications.

[0004] The basic principle of video coding compression is to remove redundancy as much as possible based on correlation between spatial domain, time domain, and codeword. The current main method is to implement video coding compression by using a hybrid video coding framework based on image blocks, performing stages such as prediction (including intra-prediction and inter-prediction), transformation, quantization, and entropy coding.

[0005] In various video encoding / decoding solutions, motion estimation / motion compensation in inter prediction is a key technique that affects the performance of encoding / decoding. In the existing inter prediction, based on block-based motion compensation (MC) prediction using a translational motion model, sub-block-based motion compensation prediction using a non-translational motion model (e.g., affine motion model) is added. Regardless of whether a non-translational motion model is used, related parameters for the affine motion model need to be added to the coded video sequence. As a result, the length of the coded video sequence increases. Summary of the Invention

[0006] The present application provides a video image prediction method and apparatus to solve the problems in the prior art as the length of coded video sequences increases.

[0007] According to a first aspect, an embodiment of the present application provides a video image prediction method, the method comprising: analyzing a bitstream to obtain a first identifier; when the first identifier indicates that a candidate motion model for inter prediction of an image block in a video image including a target block includes an affine motion model and the target block satisfies a preset condition for inter prediction using an affine motion model, analyzing the bitstream to obtain a second identifier; and determining a prediction mode for inter prediction of the target block based on the second identifier, the prediction modes including an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type prediction mode.

[0008] In the above solution, for example, some video images may have some affine characteristics, and some video images may not have affine characteristics. In this case, an identifier may be added to the bitstream to indicate whether an affine motion model type inter prediction mode is valid for a video image. If an affine motion model type inter prediction mode is not valid for a video image, parameters of the image blocks of the video image related to the affine motion model may not need to be transmitted. At the decoder side, during the decoding of the image blocks of the video image, there is no need to analyze the parameters related to the affine motion model. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0009] For example, terms such as "first" and "second" are used merely for distinction and explanation, and should not be understood as an indication or suggestion of relative importance, or an indication or suggestion of order. In addition, for parameters such as identifiers, different names may be used to describe the same content in various aspects and specific embodiments. For example, the first identifier in the first aspect is referred to as the fifth identifier in the second aspect. In a specific embodiment, the first identifier in the first aspect is referred to as identifier 1, and the second identifier in the first aspect is referred to as identifier 12.

[0010] In a possible design of the first aspect, the step of parsing the bitstream to obtain the first identifier may be implemented in the manner of parsing a sequence parameter set of the bitstream to obtain the first identifier. When the first identifier is configured in the sequence parameter set and indicates that an affine motion model type inter prediction mode is not enabled for a video image, the syntax of each image block level of the video image does not include a syntax element related to the affine motion model. At the decoder side, during the decoding of the image block of the video image, there is no need to parse the parameters related to the affine motion model. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0011] In a possible design of the first aspect, when the first identifier indicates that the candidate motion models for inter prediction of the image block of the video image including the current block include an affine motion model, the method further includes parsing the bitstream to obtain a third identifier. When the third identifier is a first value, the affine motion models include only a four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value.

[0012] In the above design, a third identifier may be further configured in the bitstream to indicate whether an affine motion model including a six-parameter affine model is valid for the video image. When the third identifier indicates that a six-parameter affine model is not valid for the video image, parameters related to the six-parameter affine model do not need to be analyzed for image blocks of the video image, and parameters related to the six-parameter affine model do not need to be transmitted in the bitstream for each image block of the video image. This can reduce the length of the coded video sequence, reduce the load on the decoder, increase processing speed, and decrease processing time.

[0013] In a specific embodiment, the third identifier in the first aspect is referred to as identifier 13.

[0014] In a possible design of the first aspect, the method further includes a step of constructing a first candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, where the first candidate motion vector list includes a first element, where the first element includes motion information of three control points for constructing a six-parameter affine motion model, or a step of constructing a second candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, where the second candidate motion vector list includes a second element, where the second element includes only motion information of two control points for constructing a four-parameter affine motion model.

[0015] In the above design, the third identifier and the second identifier are used to indicate construction of a candidate motion vector list.

[0016] In a possible design of the first aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0017] In a possible design of the first aspect, the method further comprises parsing the bitstream to obtain a fourth identifier when the second identifier indicates that an affine motion model based AMVP mode is used for inter prediction of the current block and the third identifier is the second value. When the fourth identifier is the third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is the fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0018] In a specific embodiment, the fourth identifier is referred to as identifier 14 .

[0019] In a possible design of the first aspect, parsing the bitstream to obtain the third identifier includes parsing a sequence parameter set of the bitstream to obtain the third identifier.

[0020] In a possible design of the first aspect, the preset conditions include that the width of the block to be processed is greater than or equal to a first preset threshold and that the height of the block to be processed is greater than or equal to a second preset threshold.

[0021] In a possible design of the first embodiment, the first preset threshold is equal to the second preset threshold.

[0022] According to a second aspect, an embodiment of the present application provides a video image prediction method, the method comprising: analyzing a bitstream to obtain a first identifier; when the first identifier indicates that candidate motion models for inter prediction of an image block of a slice including a current block include an affine motion model and the current block satisfies a preset condition for inter prediction using an affine motion model, analyzing the bitstream to obtain a second identifier; and determining a prediction mode for inter prediction of the current block based on the second identifier, the prediction modes including an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type prediction mode.

[0023] In the above solution, for example, some slices of a video image may have some affine properties, and some slices of a video image may not have affine properties. In this case, an identifier may be added to the bitstream to indicate whether an affine motion model type inter prediction mode is enabled for a slice of a video image. If an affine motion model type inter prediction mode is not enabled for a slice, there may be no need to transmit parameters of image blocks included in the slice that are related to an affine motion model. At the decoder side, during the decoding of image blocks in a slice, there is no need to analyze parameters related to an affine motion model. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0024] It should be noted that in a specific embodiment, the first identifier in the second aspect is referred to as identifier 2, and the second identifier in the second aspect is referred to as identifier 22 in a specific embodiment.

[0025] In a possible design of the second aspect, parsing the bitstream to obtain the first identifier includes parsing a slice header of a slice in the bitstream to obtain the first identifier.

[0026] When the first identifier is configured in a slice header of a slice and the first identifier indicates that an affine motion model type inter prediction mode is not enabled for the slice, each image block level syntax of the slice does not include a syntax element related to an affine motion model. At the decoder side, during decoding of the image blocks in the slice, there is no need to analyze parameters related to the affine motion model. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0027] In a possible design of the second aspect, when the first identifier indicates that the candidate motion models for inter prediction of the image blocks of the slice including the current block include an affine motion model, the method further includes parsing the bitstream to obtain a third identifier. When the third identifier is a first value, the affine motion models include only the four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include the four-parameter affine model and the six-parameter affine model. The first value is different from the second value.

[0028] It should be noted that the third identifier in the second aspect is referred to as identifier 23 in the specific embodiment.

[0029] In a possible design of the second aspect, the method further includes a step of constructing a first candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, where the first candidate motion vector list includes a first element, where the first element includes motion information of three control points for constructing a six-parameter affine motion model, or a step of constructing a second candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, where the second candidate motion vector list includes a second element, where the second element includes only motion information of two control points for constructing a four-parameter affine motion model.

[0030] In a possible design of the second aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0031] In a possible design of the second aspect, the method further includes a step of parsing the bitstream to obtain a fourth identifier when the second identifier indicates that an affine motion model type AMVP mode is used for inter prediction of the block to be processed and the third identifier is a second value.

[0032] When the fourth identifier is a third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0033] It should be noted that in this application, the fourth identifier is referred to as identifier 24 in a specific embodiment.

[0034] In the above design, a third identifier may be further configured in the bitstream to indicate whether the affine motion model used for the slice may include a six-parameter affine motion model. When the third identifier indicates that the six-parameter affine model is not valid for the slice, there is no need to analyze parameters related to the six-parameter affine model for image blocks included in the slice, and there is no need to transmit parameters related to the six-parameter affine model in the bitstream for each image block included in the slice. This can reduce the length of the coded video sequence, reduce the load on the decoder, increase processing speed, and decrease processing time.

[0035] In a possible design of the second aspect, parsing the bitstream to obtain the third identifier includes parsing a slice header of a slice in the bitstream to obtain the third identifier.

[0036] In a possible design of the second aspect, before parsing the bitstream to obtain the first identifier, the method further comprises parsing the bitstream to obtain a fifth identifier, where when the fifth identifier is a fifth value, candidate motion models for inter prediction of image blocks in the video image including the current block include affine motion models, or when the fifth identifier is a sixth value, candidate motion models for inter prediction of image blocks in the video image including the current block include only non-affine motion models. The fifth value is different from the sixth value.

[0037] The fifth identifier is referred to as identifier 1 in a specific embodiment.

[0038] Some video pictures do not have affine properties, and not all slices of some video pictures have affine properties. In this case, two identifiers may be added to the bitstream. A first type of identifier (referred to as the fifth identifier in the second aspect) is used to indicate whether an affine motion model type inter prediction mode is valid for a video picture, and a second type of identifier (referred to as the first identifier in the second aspect) is used to indicate whether an affine motion model type inter prediction mode is valid for a slice in the video picture. For video pictures or image blocks included in slices that do not need to use an affine motion model, it may not be necessary to transmit parameters of the image block related to the affine motion model. At the decoder side, during the decoding of the image block, there is no need to analyze parameters related to the affine motion model. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0039] In a possible design of the second aspect, parsing the bitstream to obtain the fifth identifier includes parsing a sequence parameter set of the bitstream to obtain the fifth identifier.

[0040] In a possible design of the second aspect, after parsing the bitstream to obtain the fifth identifier and before parsing the bitstream to obtain the first identifier, the method further comprises parsing the bitstream to obtain a sixth identifier, which is used to determine that the bitstream includes the third identifier.

[0041] It should be noted that the sixth identifier in the second aspect is referred to as identifier 13 in the specific embodiment.

[0042] In a possible design of the second aspect, parsing the bitstream to obtain the sixth identifier includes parsing a sequence parameter set of the bitstream to obtain the sixth identifier.

[0043] In a possible design of the second aspect, the preset conditions include that the width of the block to be processed is greater than or equal to a first preset threshold and that the height of the block to be processed is greater than or equal to a second preset threshold.

[0044] In a possible design of the second embodiment, the first preset threshold is equal to the second preset threshold.

[0045] Based on the same inventive concept as the first aspect, according to a third aspect, an embodiment of the present application provides a video image prediction device, comprising: a parsing unit configured to: parse a bitstream to obtain a first identifier; and, when the first identifier indicates that candidate motion models for inter prediction of an image block in a video image including a current block include an affine motion model, parse the bitstream to obtain a second identifier when the first identifier indicates that candidate motion models for inter prediction of an image block in a video image including a current block include an affine motion model and the current block satisfies a preset condition for inter prediction using an affine motion model.

[0046] The analysis unit is further configured to determine a prediction mode for inter prediction of the current block based on the second identifier, the prediction modes including an affine motion model based merge mode, an affine motion model based AMVP mode, and a non-affine motion model based prediction mode.

[0047] In a possible design of the third aspect, when parsing the bitstream to obtain the first identifier, the parsing unit is specifically configured to parse a sequence parameter set of the bitstream to obtain the first identifier.

[0048] In a possible design of the third aspect, when the first identifier indicates that the candidate motion models for inter prediction of the image block in the video image including the current block include an affine motion model, the parsing unit is further configured to parse the bitstream to obtain a third identifier. When the third identifier is a first value, the affine motion models include only a four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value.

[0049] In a possible design of the third aspect, the apparatus further includes a construction unit configured to: when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, construct a first candidate motion vector list, where the first candidate motion vector list includes a first element, where the first element includes motion information of three control points for constructing a six-parameter affine motion model; or, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, construct a second candidate motion vector list, where the second candidate motion vector list includes a second element, where the second element includes only motion information of two control points for constructing a four-parameter affine motion model.

[0050] In a possible design of the third aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0051] In a possible design of the third aspect, the analysis unit is further configured to analyze the bitstream to obtain a fourth identifier when the second identifier indicates that an affine motion model type AMVP mode is used for inter prediction of the block to be processed and the third identifier is a second value.

[0052] When the fourth identifier is a third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0053] In a possible design of the third aspect, when parsing the bitstream to obtain the third identifier, the parsing unit is specifically configured to parse a sequence parameter set of the bitstream to obtain the third identifier.

[0054] In a possible design of the third aspect, the preset conditions include that the width of the block to be processed is greater than or equal to a first preset threshold and that the height of the block to be processed is greater than or equal to a second preset threshold.

[0055] In a possible design of the third aspect, the first preset threshold is equal to the second preset threshold.

[0056] Based on the same inventive concept as the second aspect, according to a fourth aspect, an embodiment of the present application provides a video image prediction device, the device comprising: an analysis unit configured to analyze a bitstream to obtain a first identifier. The analysis unit is further configured to analyze the bitstream to obtain a second identifier when the first identifier indicates that a candidate motion model for inter prediction of an image block in a slice including a current block includes an affine motion model and the current block satisfies a preset condition for inter prediction using an affine motion model, and to determine a prediction mode for inter prediction of the current block based on the second identifier. The prediction modes include an affine motion model based merge mode, an affine motion model based AMVP mode, and a non-affine motion model based prediction mode.

[0057] In a possible design of the fourth aspect, when parsing the bitstream to obtain the first identifier, the parsing unit is specifically configured to parse a slice header of a slice in the bitstream to obtain the first identifier.

[0058] In a possible design of the fourth aspect, an affine motion model type merge mode is used for inter prediction of the current block. The parsing unit is further configured to parse the bitstream to obtain a third identifier when the first identifier indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model. When the third identifier is a first value, the affine motion models include only a four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value.

[0059] In a possible design of the fourth aspect, the apparatus further includes a construction unit configured to: when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, construct a first candidate motion vector list, the first candidate motion vector list including a first element, the first element including motion information of three control points for constructing a six-parameter affine motion model; or, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, construct a second candidate motion vector list, the second candidate motion vector list including a second element, the second element including only motion information of two control points for constructing a four-parameter affine motion model.

[0060] In a possible design of the fourth aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0061] In a possible design of the fourth aspect, the parsing unit is further configured to parse the bitstream to obtain a fourth identifier when the second identifier indicates that an affine motion model type AMVP mode is used for inter prediction of the current block and the third identifier is the second value. When the fourth identifier is the third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is the fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0062] In a possible design of the fourth aspect, when parsing the bitstream to obtain the third identifier, the parsing unit is specifically configured to parse a slice header of a slice in the bitstream to obtain the third identifier.

[0063] In a possible design of the fourth aspect, prior to parsing the bitstream to obtain the first identifier, the parsing unit is further configured to parse the bitstream to obtain a fifth identifier, where when the fifth identifier is a fifth value, the candidate motion models for inter prediction of image blocks in the video image including the current block include affine motion models, or when the fifth identifier is a sixth value, the candidate motion models for inter prediction of image blocks in the video image including the current block include only non-affine motion models. The fifth value is different from the sixth value.

[0064] In a possible design of the fourth aspect, when parsing the bitstream to obtain the fifth identifier, the parsing unit is specifically configured to parse a sequence parameter set of the bitstream to obtain the fifth identifier.

[0065] In a possible design of the fourth aspect, the parsing unit is further configured to parse the bitstream to obtain a sixth identifier after parsing the bitstream to obtain the fifth identifier and before parsing the bitstream to obtain the first identifier, the sixth identifier being used to determine that the bitstream includes the third identifier.

[0066] In a possible design of the fourth aspect, when parsing the bitstream to obtain the sixth identifier, the parsing unit is specifically configured to parse a sequence parameter set of the bitstream to obtain the sixth identifier.

[0067] In a possible design of the fourth aspect, the preset conditions include that the width of the block to be processed is greater than or equal to a first preset threshold and that the height of the block to be processed is greater than or equal to a second preset threshold.

[0068] In a possible design of the fourth aspect, the first preset threshold is equal to the second preset threshold.

[0069] According to a fifth aspect, an embodiment of the present application provides an apparatus. The apparatus may be a decoder and includes a processor and a memory. The memory is configured to store instructions. When the apparatus operates, the processor executes the instructions stored in the memory, enabling the apparatus to perform the method provided in any one of the first aspect, the design of the first aspect, the second aspect, or the design of the second aspect. It should be noted that the memory may be integrated with the processor or may be separate from the processor.

[0070] According to a sixth aspect, an embodiment of the present application provides a video image prediction method, which is applied to an encoder side and includes the steps of: encoding a first identifier into a bitstream; and, when the first identifier indicates that a candidate motion model for inter prediction of an image block in a video image including a current block includes an affine motion model and the current block satisfies a preset condition for inter prediction using an affine motion model, encoding a second identifier into the bitstream, the second identifier being used to determine a prediction mode for inter prediction of the current block. The prediction mode includes an affine motion model based merge mode, an affine motion model based advanced motion vector prediction AMVP mode, and a non-affine motion model based prediction mode.

[0071] In a possible design of the sixth aspect, encoding the first identifier into the bitstream may be implemented in a manner that encodes the first identifier into a sequence parameter set of the bitstream.

[0072] In a possible design of the sixth aspect, when the first identifier indicates that the candidate motion models for inter prediction of an image block in a video image including the current block include an affine motion model, the method further comprises encoding a third identifier into the bitstream. When the third identifier is a first value, the affine motion models include only a four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value.

[0073] In a possible design of the sixth aspect, the method further includes a step of constructing a first candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, wherein the first candidate motion vector list includes a first element, the first element including motion information of three control points for constructing a six-parameter affine motion model, or a step of constructing a second candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, wherein the second candidate motion vector list includes a second element, the second element including only motion information of two control points for constructing a four-parameter affine motion model.

[0074] In the above design, the third identifier and the second identifier are used to indicate construction of a candidate motion vector list.

[0075] In a possible design of the sixth aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0076] In a possible design of the sixth aspect, the method further comprises encoding a fourth identifier into the bitstream when the second identifier indicates that an affine motion model type AMVP mode is used for inter prediction of the current block and the third identifier is the second value. When the fourth identifier is the third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is the fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0077] In a specific embodiment, the fourth identifier is referred to as identifier 14 .

[0078] In a possible design of the sixth aspect, encoding the third identifier into the bitstream includes encoding the third identifier into a sequence parameter set of the bitstream.

[0079] According to a seventh aspect, an embodiment of the present application provides a video image prediction method, which is applied on an encoder side and includes the steps of: encoding a first identifier into a bitstream; and, when the first identifier indicates that a candidate motion model for inter prediction of an image block in a slice including a current block includes an affine motion model and the current block satisfies a preset condition for inter prediction using an affine motion model, encoding a second identifier into the bitstream, wherein the second identifier is used to determine a prediction mode for inter prediction of the current block, the prediction mode including an affine motion model based merge mode, an affine motion model based advanced motion vector prediction AMVP mode, and a non-affine motion model based prediction mode.

[0080] In a possible design of the seventh aspect, encoding the first identifier into the bitstream includes encoding the first identifier into a slice header of a slice of the bitstream.

[0081] In a possible design of the seventh aspect, when the first identifier indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model, the method further comprises encoding a third identifier into the bitstream. When the third identifier is a first value, the affine motion models include only a four-parameter affine model. Or, when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value.

[0082] In a possible design of the seventh aspect, the method further comprises a step of constructing a first candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, wherein the first candidate motion vector list includes a first element, the first element including motion information of three control points for constructing a six-parameter affine motion model, or a step of constructing a second candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a first value, wherein the second candidate motion vector list includes a second element, the second element including only motion information of two control points for constructing a four-parameter affine motion model.

[0083] In a possible design of the seventh aspect, when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is a second value, the first candidate motion vector list further includes a second element.

[0084] In a possible design of the seventh aspect, the method further comprises a step of encoding a fourth identifier into the bitstream when the second identifier indicates that affine motion model type AMVP mode is used for inter prediction of the block to be processed and the third identifier is the second value.

[0085] When the fourth identifier is a third value, the affine motion model is a six-parameter affine motion model, or when the fourth identifier is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value.

[0086] In a possible design of the seventh aspect, encoding the third identifier into the bitstream includes encoding the third identifier into a slice header of a slice of the bitstream.

[0087] In a possible design of the seventh aspect, before encoding the first identifier into the bitstream, the method further comprises encoding a fifth identifier into the bitstream. When the fifth identifier is a fifth value, the candidate motion models for inter prediction of image blocks in the video image including the current block include affine motion models, or when the fifth identifier is a sixth value, the candidate motion models for inter prediction of image blocks in the video image including the current block include only non-affine motion models. The fifth value is different from the sixth value.

[0088] In a possible design of the seventh aspect, encoding the fifth identifier into the bitstream includes encoding the fifth identifier into a sequence parameter set of the bitstream.

[0089] In a possible design of the seventh aspect, after encoding the fifth identifier into the bitstream and before encoding the first identifier in the bitstream, the method further comprises encoding a sixth identifier into the bitstream, the sixth identifier being used to determine that the bitstream includes the third identifier.

[0090] It should be noted that the sixth identifier in the seventh aspect is referred to as identifier 13 in a specific embodiment.

[0091] In a possible design of the seventh aspect, encoding the sixth identifier into the bitstream includes encoding the sixth identifier into a sequence parameter set of the bitstream.

[0092] According to an eighth aspect, an embodiment of the present application provides an apparatus. The apparatus may be an encoder, and includes a processor and a memory. The memory is configured to store instructions. When the apparatus operates, the processor executes the instructions stored in the memory, enabling the apparatus to perform the method provided in any one of the third aspect, the design of the third aspect, the fourth aspect, or the design of the fourth aspect. It should be noted that the memory may be integrated with the processor or may be separate from the processor.

[0093] According to a ninth aspect, the present application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the methods described in each of the previous aspects.

[0094] According to a tenth aspect, the present application provides a computer program product comprising instructions, which when run on a computer enable the computer to carry out the methods described in each of the previous aspects.

[0095] It should be understood that the technical solutions of the third to tenth aspects of the present application are consistent with the technical solutions of the first and second aspects of the present application, and the advantageous effects achieved by the aspects and corresponding implementable designs are similar, and details will not be described again here. [Brief description of the drawings]

[0096] [Figure 1] FIG. 1 is a block diagram of a video encoding and decoding system in an implementation described in embodiments of the present application.

[0097] [Figure 2A]FIG. 2 is a block diagram of a video encoder in an implementation described in an embodiment of the present application.

[0098] [Figure 2B] FIG. 2 is a schematic diagram of inter prediction in the implementation described in the embodiments of the present application.

[0099] [Figure 2C] FIG. 2 is a block diagram of a video decoder in an implementation described in an embodiment of the present application.

[0100] [Diagram 3] 2 is a schematic diagram of candidate positions of motion information in an implementation described in an embodiment of the present application;

[0101] [Figure 4] FIG. 2 is a schematic diagram of the prediction of inherited control point motion vectors in the implementation described in the embodiments of the present application;

[0102] [Figure 5A] FIG. 2 is a schematic diagram of prediction of constructed control point motion vectors in the implementation described in the embodiments of the present application;

[0103] [Figure 5B] 13 is a schematic flowchart of combining control point motion information to obtain constructed control point motion information in the implementation described in the embodiments of the present application;

[0104] [Figure 6A] 1 is a flowchart of an inter-prediction method in an implementation described in an embodiment of the present application.

[0105] [Figure 6B] FIG. 2 is a schematic diagram of constructing a candidate motion vector list in the implementation described in the embodiments of the present application;

[0106] [Figure 6C]FIG. 2 is a schematic diagram of a motion compensation unit in an implementation described in an embodiment of the present application.

[0107] [Figure 7] 1 is a schematic flowchart of a video image prediction method according to an embodiment of the present application;

[0108] [Figure 8] 1 is a schematic flowchart of an inter prediction method according to an embodiment of the present application;

[0109] [Figure 9] 4 is a schematic flowchart of another video image prediction method according to an embodiment of the present application;

[0110] [Figure 10] 1 is a schematic flowchart of an inter prediction method according to an embodiment of the present application;

[0111] [Figure 11] 4 is a schematic flowchart of yet another video image prediction method according to an embodiment of the present application;

[0112] [Figure 12] 12 is a schematic diagram of an apparatus 1200 according to an embodiment of the present application.

[0113] [Figure 13] 13 is a schematic diagram of an apparatus 1300 according to an embodiment of the present application.

[0114] [Figure 14] FIG. 14 is a schematic diagram of an apparatus 1400 according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0115] The video image prediction solution provided in the embodiment of the present application may be applied to encoding or decoding of video images. Figure 1 is a schematic block diagram of a video encoding and decoding system 10 according to the embodiment of the present application. As shown in Figure 1, the system 10 includes a source device 11 and a destination device 12. The source device 11 generates encoded video data and transmits the encoded video data to the destination device 12. The destination device 12 is configured to receive the encoded video data, decode the encoded video data, and display the decoded video data. The source device 11 and the destination device 12 may include any one of a variety of devices, including a desktop computer, a laptop computer, a tablet computer, a set-top box, a mobile phone such as a smartphone, a smart touch panel, a television set, a camera, a display device, a digital media player, a video gaming console, a video streaming transmission device, and the like.

[0116] The solution for predicting the intra mode of an image block provided in the embodiments of the present application may be applied to video image encoding or decoding.

[0117] The destination device 12 may receive the encoded video data to be decoded through the link 16. The link 16 may include any type of medium or device capable of transferring the encoded video data from the source device 11 to the destination device 12. In a possible implementation, the link 16 may include a communication medium that allows the source device 11 to transmit the encoded video data directly to the destination device 12 in real time. The encoded video data may be modulated according to a communication standard (e.g., a wireless communication protocol), and the modulated encoded video data is transmitted to the destination device 12. The communication medium may include any wireless or wired communication medium, such as a radio frequency spectrum, or one or more physical transmission lines. The communication medium may be part of a packet-based network (e.g., a local area network, a wide area network, or a global network of the Internet). The communication medium may include a router, a switch, a base station, or any other device configured to facilitate communication between the source device 11 and the destination device 12.

[0118] Alternatively, the video encoding and decoding system 10 further includes a storage device. The encoded data may be output to the storage device through the output interface 14. Similarly, the encoded data may be accessed from the storage device through the input interface 15. The storage device may include any one of a variety of distributed or locally accessed data storage media, such as a hard disk drive, a Blu-ray disc, a DVD, a CD-ROM, a flash memory, a volatile or non-volatile memory, or any other suitable digital storage medium used to store encoded video data. In another possible implementation, the storage device may correspond to a file server or another intermediate storage device capable of maintaining the encoded video generated by the source device 11. The destination device 12 may access the video data stored in the storage device through streaming transmission or download. The file server may be any type of server capable of storing the encoded video data and transmitting the encoded video data to the destination device 12. In a possible implementation, the file server includes a website server, a file transfer protocol server, a network attached storage device, or a local disk drive. The destination device 12 may access the encoded video data through any standard data connection, including an Internet connection. The data connection may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., a cable modem), or a combination thereof. The wireless channel or the wired connection is suitable for accessing the encoded video data stored in a file server. The transmission of the encoded video data from the storage device may be a streaming transmission, a download transmission, or a combination thereof.

[0119] The technology of the present application is not necessarily limited to wireless applications or settings. The technology may be applied to video decoding to support any one of a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, streaming video transmission (e.g., over the Internet), digital video encoding for storage on a data storage medium, decoding of digital video stored on a data storage medium, or another application. In some possible implementations, the system 10 may be configured to support one-way or two-way video transmission to support applications such as streaming video transmission, video playback, video broadcasting, and / or video calling.

[0120] In a possible implementation of FIG. 1, source device 11 may include video source 13, video encoder 20, and output interface 14. In some applications, output interface 14 may include a modulator / demodulator (modem) and / or a transceiver. In source device 11, video source 13 may include, for example, the following source devices: a video capture device (e.g., a camera), an archive containing previously captured video, a video feed-in interface for receiving video from a video content provider, and / or a computer graphics system used to generate computer graphics data as source video, or a combination thereof. In a possible implementation, if video source 13 is a camera, source device 11 and destination device 12 may constitute a camera phone or a video phone. For example, the techniques described herein may be applied to, for example, video decoding, and may be applied to wireless and / or wired applications.

[0121] Video encoder 20 may encode, capture, pre-capture, or compute the generated video. The encoded video data may be transmitted directly to destination device 12 through output interface 14 of source device 11. The encoded video data may also (or alternatively) be stored in a storage device for later access by destination device 12, or may be stored in another device for decoding and / or playback.

[0122] Destination device 12 includes an input interface 15, a video decoder 30, and a display device 17. In some applications, input interface 15 may include a receiver and / or a modem. Input interface 15 of destination device 12 receives encoded video data over link 16. The encoded video data transmitted or provided to storage over link 16 may include various syntax elements generated by video encoder 20 for decoding the video data by video decoder 30. These syntax elements may be included with the encoded video data transmitted over a communication medium and stored on a storage medium or file server.

[0123] Display device 17 may be integrated into destination device 12 or may be located external to destination device 12. In some possible implementations, destination device 12 may include an integrated display device and may be configured to connect to an external display interface. In another possible implementation, destination device 12 may be a display device. In general, display device 17 displays the decoded video data to a user and may include any of a variety of display devices, such as, for example, a liquid crystal display, a plasma display, an organic light emitting diode display, or another type of display device.

[0124] The video encoder 20 and the video decoder 30 may operate, for example, according to the Next Generation Video Coding and Compression Standard (H.266) currently being developed and may conform to the H.266 Test Model (JEM). Alternatively, the video encoder 20 and the video decoder 30 may operate, for example, according to the ITU-T H.265 standard or the ITU-T H.264 standard or extensions thereof (the ITU-T H.265 standard is also referred to as the High Efficiency Video Coding standard, and the ITU-T H.264 standard is also referred to as the MPEG-4 Part 10 standard), or other proprietary or industry standards, such as advanced video coding (AVC). However, the technology herein is not limited to any particular decoding standard. Other possible implementations of video compression standards include MPEG-2 and ITU-T H.263.

[0125] 1, in some aspects, video encoder 20 and video decoder 30 may be integrated with audio encoders and decoders, respectively, and may include multiplexer-demultiplexer (MUX-DEMUX) units or other hardware and software suitable for encoding both audio and video in a common or separate data stream. If applicable, in some possible implementations, the MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol or other protocols, such as User Datagram Protocol (UDP).

[0126] The video encoder 20 and the video decoder 30 may be implemented separately as any one of a variety of suitable encoder circuits, such as, for example, one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When some of the techniques are implemented as software, a device may store instructions for the software on a suitable non-transitory computer-readable medium and execute the instructions in hardware form by using one or more processors to implement the techniques of the present application. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, and either the video encoder 20 or the video decoder 30 may be integrated as part of a combined encoder / decoder (CODEC) in a corresponding device.

[0127] JCT-VC developed the H.265 (HEVC) standard. The HEVC standardization is based on an evolution model of a video decoder, which is called the HEVC Test Model (HM). The latest H.265 standard document is available at http: / / www.itu.int / rec / T-REC-H.265. The latest version of the standard document is H.265(12 / 16), which is incorporated herein by reference in its entirety. In the HM, the video decoder is assumed to have several additional features over the existing algorithms of ITU-TH.264 / AVC.

[0128] JVET is dedicated to the development of the H.266 standard. The H.266 standardization process is based on a video decoding device evolution model, which is referred to as the H.266 Test Model. The H.266 algorithm description is available at http: / / phenix.int-evry.fr / jvet. The latest algorithm description is contained in JVET-F1001-v2. The algorithm description document is incorporated herein by reference in its entirety. In addition, the reference software for the JEM Test Model is available at https: / / jvet.hhi.fraunhofer.de / svn / svn_HMJEMSoftware and is also incorporated herein by reference in its entirety.

[0129] Generally, in the description of the HM working model, a video frame or image may be divided into a sequence of treeblocks or largest coding units (LCUs), which contain both luma and chroma samples, and LCUs are also referred to as CTUs. A treeblock has a function similar to a macroblock in the H.264 standard. A slice includes multiple consecutive treeblocks in decoding order. A video frame or image may be partitioned into one or more slices. Each treeblock may be divided into coding units based on a quadtree. For example, a treeblock serving as a root node of the quadtree may be divided into four child nodes, each of which may also serve as a parent node and be divided into four other child nodes. The final non-splittable child nodes serving as leaf nodes of the quadtree include decoded nodes, e.g., decoded image blocks. In syntax data associated with the decoded bitstream, the maximum number of treeblock divisions and the minimum size of the decoded nodes may be defined.

[0130] The coding unit includes a decoding node, a prediction unit (PU), and a transform unit (TU) associated with the decoding node. The size of the CU corresponds to the size of the decoding node, and the shape of the CU must be square. The size of the CU may range from 8×8 pixels up to 64×64 pixels, or may be a larger treeblock size. Each CU may include one or more PUs and one or more TUs. For example, the syntax data associated with the CU may describe partitioning the CU into one or more PUs. Different partitioning modes may be used when the CU is coded in skip mode, direct mode, intra-prediction mode, or inter-prediction mode. The PU obtained through partitioning may be of a non-square shape. For example, the syntax data associated with the CU may also describe partitioning the CU into one or more TUs based on a quadtree. The TUs may be of a square or non-square shape.

[0131] The HEVC standard allows for transforms based on TUs. Different CUs may contain different TUs. The size of a TU is typically set based on the size of a PU in a given CU, which is defined for a partitioned LCU. However, this may not always be the case. The size of a TU is typically the same as or smaller than the size of a PU. In some possible implementations, a quadtree structure, called a "residual quadtree (RQT)", may be used to split the residual samples corresponding to a CU into smaller units. The leaf nodes of the RQT may be referred to as TUs. Pixel differences associated with the TUs may be transformed to generate transform coefficients, and the transform coefficients may be quantized.

[0132] Generally, a PU includes data related to a prediction process. For example, when a PU is coded in intra mode, the PU may include data describing the intra prediction mode of the PU. In another possible implementation, when a PU is coded in inter mode, the PU may include data defining the motion vector of the PU. For example, the data defining the motion vector of the PU may describe the horizontal component of the motion vector, the vertical component of the motion vector, the resolution of the motion vector (e.g., 1 / 4 pixel accuracy, or 1 / 8 pixel accuracy), the reference image to which the motion vector points, and / or the reference image list of the motion vector (e.g., list 0, list 1, or list C).

[0133] In general, transform and quantization processes are used for the TUs. A given CU, which includes one or more PUs, may also include one or more TUs. After prediction, video encoder 20 may calculate residual values ​​corresponding to the PUs. The residual values ​​include pixel differences. The pixel differences may be transformed into transform coefficients, which are quantized and scanned by using the TUs to generate serialized transform coefficients for entropy decoding. In this application, the term "image block" is generally used to represent a decoding node of a CU. In some specific applications, in this application, the term "image block" may also be used to represent a tree block including a decoding node, a PU, and a TU, e.g., an LCU or a CU.

[0134] The video encoder 20 encodes the video data. The video data may include one or more pictures. The video encoder 20 may generate a bitstream, which includes encoded information of the video data in the form of a bitstream. The encoded information may include encoded image data and associated data. The associated data may include a sequence parameter set (SPS), a picture parameter set (PPS), and another syntax structure. The SPS may include parameters that apply to zero or more sequences. The SPS describes higher layer parameters of general characteristics of a coded video sequence (CVS), and the sequence parameter set SPS includes information required by all slices in the CVS. The PPS may include parameters that apply to zero or more pictures. The syntax structure is a set of zero or more syntax elements that are arranged in the bitstream in a specified order.

[0135] In a possible implementation, the HM supports prediction for various PU sizes. Assuming that the size of a particular CU is 2N×2N, the HM supports intra prediction for PU sizes of 2N×2N or N×N, and inter prediction for symmetric PU sizes of 2N×2N, 2N×N, N×2N, or N×N. The HM also supports asymmetric partitioning for inter prediction for PU sizes of 2N×nU, 2N×nD, nL×2N, and nR×2N. In asymmetric partitioning, the CU is not partitioned in one direction, but is partitioned into two parts in another direction, one part occupies 25% of the CU, and the other part occupies 75% of the CU. The part occupying 25% of the CU is indicated by an indicator that includes "n" followed by "U(Up)", "D(Down)", "L(Left)", or "R(Right)". So, for example, "2N×nU" refers to a horizontally partitioned 2N×2N CU, with 2N×0.5N PUs above and 2N×1.5N PUs below.

[0136] In this application, "NxN" and "N by N" may be used interchangeably to indicate the pixel size of an image block in the vertical and horizontal dimensions. For example, 16x16 pixels or 16 by 16 pixels. Typically, a 16x16 block has 16 pixels in the vertical direction (y=16) and 16 pixels in the horizontal direction (x=16). Similarly, an NxN block typically has N pixels in the vertical direction and N pixels in the horizontal direction, where N is a non-negative integer value. The pixels in a block may be arranged in rows and columns. In addition, the number of pixels in the horizontal direction and the number of pixels in the vertical direction in a block may not necessarily be the same. For example, a block may include NxM pixels, where M is not necessarily equal to N.

[0137] After decoding a PU in a CU in intra or inter prediction mode, video encoder 20 may calculate residual data of the TU in the CU. The PU may include pixel data in a spatial domain (also referred to as a pixel domain), and the TU may include coefficients in a transform domain obtained after a transform (e.g., a discrete cosine transform (DCT), an integer transform, a wavelet transform, or other conceptually similar transform) is applied to the residual video data. The residual data may correspond to pixel differences between pixels of the uncoded image and predicted values ​​corresponding to the PU. Video encoder 20 may generate TUs including the residual data of the CU and then transform the TUs to generate transform coefficients of the CU.

[0138] The JEM model further improves the video image coding structure. Specifically, a block coding structure called "quadtree + binary tree" (QTBT) structure is introduced. The QTBT structure supports more flexible CU partition shapes without using concepts such as CU, PU, ​​and TU in HEVC. CUs can be square or rectangular. Quadtree partitioning is first performed on CTUs, and binary tree partitioning is further performed on leaf nodes of the quadtree. In addition, there are two binary tree partitioning modes, namely symmetric horizontal partitioning and symmetric vertical partitioning. The leaf nodes of the binary tree are called CUs. CUs in the JEM model are not further partitioned in either prediction or transformation processes. In other words, CUs, PUs, and TUs in the JEM model have the same block size. In the existing JEM model, the maximum CTU size is 256x256 luma pixels.

[0139] FIG. 2A is a schematic block diagram of a video encoder 20 according to an embodiment of the present application.

[0140] 2A, the video encoder 20 may include a prediction module 21, an adder 22, a transform module 23, a quantization module 24, and an entropy coding module 25. In an example, the prediction module 21 may include an inter prediction module 211 and an intra prediction module 212. The internal structure of the prediction module 21 is not limited to this embodiment of the present application. Optionally, the video encoder 20 with a hybrid architecture may also include an inverse quantization module 26, an inverse transform module 27, and an adder 28.

[0141] 2A, video encoder 20 may further include a storage module 29. It should be understood that storage module 29 may alternatively be located outside video encoder 20.

[0142] In another possible implementation, video encoder 20 may further include a filter (not shown in FIG. 2A ) for filtering image block boundaries, thereby removing artifacts from the reconstructed video image. If necessary, the filter typically filters the output from summer 28.

[0143] Optionally, the video encoder 20 may further include a partitioning unit (not shown in FIG. 2A ). The video encoder 20 receives video data, and the partitioning unit partitions the video data into image blocks. Such partitioning may further include partitioning into slices, image blocks, or other larger units, and partitioning into image blocks performed based on a quadtree structure of LCUs and CUs (for example). The video encoder 20, for example, describes components for encoding image blocks in a video slice to be encoded. A slice may typically be divided into multiple image blocks (and into sets of image blocks). Slice types include I (mainly used for intra image coding), P (used for inter forward reference predictive image coding), and B (used for inter bidirectional reference predictive image coding).

[0144] The prediction module 21 is configured to perform intra or inter prediction on the image block that needs to be currently processed, and obtain a prediction value (which may be referred to as prediction information in this application) of the current block. In this embodiment of the application, the image block that needs to be currently processed may be a target block for short, may be a current image block for short, or may be a current block for short. Alternatively, the image block that needs to be currently processed in the encoding phase may be referred to as a current coding block (coding block) for short, and the image block that needs to be currently processed in the decoding phase may be referred to as a current coding block (decoding block) for short.

[0145] Specifically, the inter prediction module 211 included in the prediction module 21 performs inter prediction on the current block to obtain an inter prediction value. The intra prediction module 212 performs intra prediction on the current block to obtain an intra prediction value. The inter prediction module 211 searches for a matching reference block in the reconstructed image for the current block in the current image, and uses the sample values ​​of the samples in the reference block as prediction information or prediction values ​​of the sample values ​​of the samples in the current block (hereinafter, information and value are not distinguished) (this process is called motion estimation (ME) (shown in FIG. 2B)), and transmits the motion information of the current block.

[0146] It should be noted that the motion information of an image block includes an indication of the prediction direction (usually forward prediction, backward prediction, or bidirectional prediction), one or two motion vectors (Motion vectors, MVs) to which the reference block points, and an indication of the image in which the reference block is located (often represented as a reference image index).

[0147] Forward prediction means selecting a reference image from a forward reference image set to obtain a reference block of the current block. Backward prediction means selecting a reference image from a backward reference image set to obtain a reference block of the current block. Bidirectional prediction means selecting a reference image from a forward reference image set and a reference image from a backward reference image set to obtain a reference block. When the bidirectional prediction method is used, there are two reference blocks for the current block. Each reference block needs to be indicated by using a motion vector and a reference image index, and then the predicted value of the sample value of the sample in the current block is determined based on the pixel values ​​of the samples in the two reference blocks.

[0148] In the motion estimation process, multiple reference blocks in a reference image need to be tried for the current block, and finally it is determined which one or more specific reference blocks are used for prediction through rate-distortion optimization (RDO) or by using another method.

[0149] After the prediction module 21 generates a prediction value of the current block through inter prediction or intra prediction, the video encoder 20 subtracts the prediction value from the current block to generate residual information. The transform module 23 is configured to transform the residual information. The transform module 23 applies a transform such as a discrete cosine transformation (DCT) or a conceptually similar transform (e.g., a discrete sine transform DST) to transform the residual information into residual transform coefficients. The transform module 23 may transmit the obtained residual transform coefficients to the quantization module 24. The quantization module 24 quantizes the residual transform coefficients to further reduce the code rate. In some possible implementations, the quantization module 24 may continue scanning the matrix including the quantized transform coefficients. Alternatively, the entropy coding module 25 may perform the scanning.

[0150] After quantization, entropy encoding module 25 may perform entropy encoding on the quantized residual transform coefficients to obtain a bitstream. For example, entropy encoding module 25 may perform context-adaptive variable length decoding (CAVLC), context-adaptive binary arithmetic decoding (CABAC), syntax-based context-adaptive binary arithmetic decoding (SBAC), probability interval partitioning entropy (PIPE) decoding, or another entropy encoding method or technique. After entropy encoding module 25 performs the entropy encoding, the encoded bitstream may be transmitted to video decoder 30 or archived for future transmission or retrieval by video decoder 30.

[0151] The inverse quantization module 26 and the inverse transform module 27 perform inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain as a reference block in the reference image. The adder 28 adds the residual information obtained through reconstruction and the prediction value generated by the prediction module 21 to generate a reconstructed block, and uses the reconstructed block as a reference block and stores it in the storage module 29. The reference block can be used by the prediction module 21 to perform inter or intra prediction on a block in a subsequent video frame or image.

[0152] It should be understood that other structural variations of the video encoder 20 can be used to encode the video stream. For example, for some image blocks or image frames, the video encoder 20 may directly quantize the residual information without processing by the transform module 23 or by the inverse transform module 27. Alternatively, for some image blocks or image frames, the video encoder 20 may not generate residual information, and correspondingly, processing by the transform module 23, the quantization module 24, the inverse quantization module 26, and the inverse transform module 27 is not required. Alternatively, the video encoder 20 may directly store the reconstructed image block as a reference block without processing by a filter unit. Alternatively, the quantization module 24 and the inverse quantization module 26 in the video encoder 20 may be combined together. Alternatively, the transform module 23 and the inverse transform module 27 in the video encoder 20 may be combined together. Alternatively, the adder 22 and the adder 28 may be combined together.

[0153] FIG. 2C is a schematic block diagram of a video decoder 30 according to an embodiment of the present application.

[0154] 2C, the video decoder 30 may include an entropy decoding module 31, a prediction module 32, an inverse quantization module 34, an inverse transform module 35, and a reconstruction module 36. In an example, the prediction module 32 may include a motion compensation module 322 and an intra prediction module 321. This is not limited to this embodiment of the present application.

[0155] In possible implementations, video decoder 30 may further include a storage module 33. It should be understood that storage module 33 may alternatively be located outside video decoder 30. In some possible implementations, video decoder 30 may perform an exemplary decoding procedure that is the inverse of the encoding procedure of video encoder 20 in FIG. 2A.

[0156] In the decoding process, the video decoder 30 receives a bitstream from the video encoder 20. The entropy decoding module 31, the inverse quantization module 34, and the inverse transform module 35 successively perform entropy decoding, inverse quantization, and inverse transform on the bitstream received by the video decoder 30, respectively, to obtain residual information. Whether intra prediction or inter prediction is performed on the current block is determined based on the bitstream. If intra prediction is performed, the intra prediction module 321 in the prediction module 32 constructs prediction information based on the intra prediction method used and the pixel values ​​of reference pixels of the reconstructed blocks around the current block. If inter prediction is performed, the motion compensation module 322 needs to obtain motion information through analysis, and determines a reference block from the reconstructed image block based on the analyzed motion information, and uses the sample values ​​of the samples in the reference block as prediction information (this process is called motion compensation (MC)). The reconstruction module 36 can obtain reconstruction information by using the prediction information and the residual information.

[0157] As mentioned above, the present application relates to, for example, inter-decoding, and therefore certain techniques of the present application may be performed by motion compensation module 322. In other possible implementations, one or more other units of video decoder 30 may additionally or alternatively be responsible for performing the techniques of the present application.

[0158] First, the concept of this application will be explained below.

[0159] (1) Inter prediction mode

[0160] In HEVC, two inter prediction modes are used: advanced motion vector prediction (AMVP) mode and merge mode.

[0161] In AMVP mode, the spatially or temporally adjacent coding blocks (represented as neighboring blocks) of the current block are traversed first, a candidate motion vector list (which may also be referred to as motion information candidate list) is constructed based on the motion information of each neighboring block, an optimal motion vector is determined from the candidate motion vector list by using the rate-distortion cost, and the candidate motion information with the minimum rate-distortion cost is used as the motion vector predictor (MVP) of the current block. Both the position of the neighboring blocks and the traversal order of the neighboring blocks are predetermined. The rate-distortion cost is calculated according to Equation (1). J represents the rate-distortion cost (RD Cost), SAD is the sum of absolute differences (SAD) between the original pixel value and the predicted pixel value obtained through motion estimation by using the candidate motion vector predictor, R represents the bit rate, and λ represents the Lagrange multiplier. The encoder side transfers the index value of the selected motion vector predictor in the candidate motion vector list and the reference image index value to the decoder side. Furthermore, a motion search is performed in the neighborhood, centered on the MVP, to obtain the actual motion vector of the current block. The encoder side transfers the motion vector difference between the MVP and the actual motion vector to the decoder side. Formula (1)

number

[0162] In the merge mode, first, a candidate motion vector list is constructed by using the motion information of the spatially or temporally neighboring coded blocks of the current block, then, by calculating the rate-distortion cost, the best motion information is determined from the candidate motion vector list and used as the motion information of the current block, and then, the index value (represented as merge index, and the same will be hereinafter) of the position of the best motion information in the candidate motion vector list is transferred to the decoder side. Figure 3 shows the spatial and temporal candidate motion information of the current block. The spatial candidate motion information comes from five spatially neighboring blocks (A0, A1, B0, B1 and B2). If the neighboring blocks are not available (there is no neighboring block, the neighboring block is not coded, or the prediction mode used by the neighboring block is not an inter prediction mode), the motion information of the neighboring block is not added to the candidate motion vector list. The temporal candidate motion information of the current block is obtained by scaling the MV of the block at the corresponding position in the reference frame based on the picture order count (POC) of the reference frame and the current frame. First, it is determined whether the block at the position T in the reference frame is available. If the block is not available, the block at position C is selected.

[0163] Similar to the AMVP mode, in the merge mode, both the positions of the neighboring blocks and the traversal order of the neighboring blocks are also predefined. In addition, in different modes, the positions of the neighboring blocks and the traversal order of the neighboring blocks may be different.

[0164] It can be seen that the candidate motion vector list needs to be maintained in both AMVP mode and merge mode. Before new motion information is added to the candidate list every time, it is first checked whether the same motion information already exists in the list. If the same motion information exists in the list, the motion information is not added to the list. This checking process is called pruning the candidate motion vector list. The list is pruned to avoid the same motion information in the list, thereby avoiding redundant rate-distortion cost calculation.

[0165] In inter prediction in HEVC, the same motion information is used for all pixels in a coding block, and then motion compensation is performed based on the motion information to obtain a predicted value of the pixel of the coding block. However, not all pixels in a coding block have the same motion characteristics. Using the same motion information may result in inaccurate motion compensation prediction and more residual information.

[0166] In existing video coding standards, block matching motion estimation based on translational motion model is used, and the motion of all pixels in a block is assumed to be consistent. However, in the real world, there are various motions. Many objects are non-translational motions, such as rotating objects, roller coasters rotating in different directions, fireworks displays, and some stunts in movies, especially moving objects in UGC scenarios. For these moving objects, if block motion compensation techniques based on translational motion model in existing coding standards are used for coding, the coding efficiency may be greatly affected. In this case, a non-translational motion model, such as an affine motion model, is introduced to further improve coding efficiency.

[0167] Based on this, in relation to different motion models, the AMVP mode may be classified into a translational model type AMVP mode and a non-translational model type AMVP mode, and the merge mode may be classified into a translational model type merge mode and a non-translational motion model type merge mode.

[0168] (2) Non-translational motion model

[0169] Non-translational motion model prediction means that the encoder / decoder side uses the same motion model to derive the motion information of each motion compensation subunit in the current block, and performs motion compensation based on the motion information of the motion compensation subunit to obtain a prediction block, thereby improving prediction efficiency. Common non-translational motion models include a four-parameter affine motion model or a six-parameter affine motion model.

[0170] The motion compensation subunit in this embodiment of the present application can be a sample or a pixel block obtained through partitioning according to a specific method and having a size of N1×N2, where both N1 and N2 are positive integers, and N1 can be equal to N2 or not equal to N2.

[0171] The four-parameter affine motion model is expressed as the following equation (2). Formula (2)

number

[0172] The four-parameter affine motion model can be represented by using the motion vectors of two samples and the coordinates of the two samples relative to the top-left sample of the current block. The samples used to represent the motion model parameters are called control points. When the top-left sample (0,0) and the top-right sample (W,0) are used as the control points, the motion vectors (vx0,vy0) and (vx1,vy1) of the control points of the top-left sample and the top-right sample of the current block are first determined, and then the motion information of each motion compensation sub-unit in the current block is obtained according to equation (3). (x,y) is the coordinate of the motion compensation sub-unit relative to the top-left sample of the current block, and W is the width of the current block. Formula (3)

number

[0173] The six-parameter affine motion model is expressed as Equation (4). Formula (4)

number

[0174] The six-parameter affine motion model can be represented by using the motion vectors of three samples and the coordinates of the three samples relative to the top-left sample of the current block. If the top-left sample (0,0), the top-right sample (W,0) and the bottom-left sample (0,H) are used as control points, the motion vectors of the top-left control point, the top-right control point and the bottom-left control point of the current block are first determined as (vx0,vy0), (vx1,vy1) and (vx2,vy2), respectively. Then, the motion information of each motion compensation sub-unit in the current block is obtained according to Equation (5). (x,y) is the coordinate of the motion compensation sub-unit relative to the top-left sample of the current block, and W and H are the width and height of the current block, respectively. Formula (5)

number

[0175] A coded block that is predicted by using an affine motion model is called an affine coded block.

[0176] The motion information of the control points of an affine-coded block can usually be obtained by using an affine motion model-based Advanced Motion Vector Prediction (AMVP) mode or an affine motion model-based Merge mode.

[0177] The motion information of the control points of the current coding block may be obtained by using a method for predicting the inherited control point motion vectors or the constructed control point motion vectors.

[0178] (3) A method for predicting inherited control point motion vectors

[0179] The method for predicting the inherited control point motion vector is to determine the candidate control point motion vectors of the current block by using the motion models of the neighboring coded affine-coded blocks.

[0180] The current block shown in Fig. 4 is used as an example. The blocks in the neighboring positions around the current block are traversed in a specified order, for example, the order A1->B1->B0->A0->B2, to find the affine-coded block in which the blocks in the neighboring positions of the current block are located, and obtain the control point motion information of the affine-coded block. Furthermore, the control point motion vector (used in merge mode) or the control point motion vector prediction value (used in AMVP mode) of the current block is further derived by using the motion model constructed by using the control point motion information of the affine-coded block. The order A1->B1->B0->A0->B2 is used only as an example. Other combination orders are also applicable to the present application. In addition, the blocks in the neighboring positions are not limited to A1, B1, B0, A0 and B2.

[0181] The blocks at the neighboring positions may be pixel blocks of a preset size obtained through samples or partitioning according to a specific method, for example, but not limited to, a 4×4 pixel block, a 4×2 pixel block, or a pixel block of another size.

[0182] In the following, the decision process is described by using A1 as an example, and other cases are similar.

[0183] As shown in Figure 4, if the coding block where A1 is located is a four-parameter affine coding block, the motion vector (vx4, vy4) of the top-left sample (x4, y4) of the affine coding block and the motion vector (vx5, vy5) of the top-right sample (x5, y5) of the affine coding block are obtained. The motion vector (vx0, vy0) of the top-left sample (x0, y0) of the current affine coding block is calculated according to equation (6), and the motion vector (vx1, vy1) of the top-right sample (x1, y1) of the current affine coding block is calculated according to equation (7). Formula (6)

number

number

[0184] The combination of the motion vector (vx0, vy0) of the top-left sample (x0, y0) of the current block and the motion vector (vx1, vy1) of the top-right sample (x1, y1) of the current block obtained based on the affine coding block in which A1 is located is the candidate control point motion vector of the current block.

[0185] If the coding block where A1 is located is a 6-parameter affine coding block, the motion vector (vx4, vy4) of the top-left sample (x4, y4) of the affine coding block, the motion vector (vx5, vy5) of the top-right sample (x5, y5) of the affine coding block, and the motion vector (vx6, vy6) of the bottom-left sample (x6, y6) of the affine coding block are obtained. The motion vector (vx0, vy0) of the top-left sample (x0, y0) of the current block is calculated according to equation (8), the motion vector (vx1, vy1) of the top-right sample (x1, y1) of the current block is calculated according to equation (9), and the motion vector (vx2, vy2) of the bottom-left sample (x2, y2) of the current block is calculated according to equation (10). Formula (8)

number

number

number

[0186] The combination of the motion vector (vx0, vy0) of the top-left sample (x0, y0) of the current block, the motion vector (vx1, vy1) of the top-right sample (x1, y1) of the current block, and the motion vector (vx2, vy2) of the bottom-left sample (x2, y2) of the current block, obtained based on the affine coding block in which A1 is located, is the candidate control point motion vector of the current block.

[0187] It should be noted that other motion models, candidate positions, and search and traversal orders are also applicable to the present application, and will not be described in detail in this embodiment of the present application.

[0188] It should be noted that methods in which other control points are used to represent the motion models of the neighboring and current coding blocks are also applicable to the present application, and will not be described in detail here.

[0189] (4) Method 1 for predicting constructed control point motion vectors

[0190] The method of predicting the constructed control point motion vector is to combine the motion vectors of adjacent coding blocks around the control point of the current block to serve as the control point motion vector of the current affine coding block, without considering whether the adjacent coding blocks are affine coding blocks or not.

[0191] The motion vector of the upper left sample and the upper right sample of the current block are determined by using the motion information of the neighboring coding blocks around the current coding block. Figure 5A is used as an example to describe the method for predicting the constructed control point motion vector. It should be noted that Figure 5A is just an example.

[0192] As shown in Figure 5A, the motion vectors of the neighboring coding blocks A2, B2 and B3 of the top-left sample are used as candidate motion vectors for the motion vector of the top-left sample of the current block, and the motion vectors of the neighboring coding blocks B1 and B0 of the top-right sample are used as candidate motion vectors for the motion vector of the top-right sample of the current block. The candidate motion vectors of the top-left sample and the candidate motion vectors of the top-right sample are combined to form a number of 2-tuples. The motion vectors of the two coding blocks included in the 2-tuples can be used as candidate control point motion vectors of the current block, as shown in equation (11A). Formula (11A)

number

[0193] As shown in Figure 5A, the motion vectors of the neighboring coded blocks A2, B2, and B3 of the upper left sample are used as candidate motion vectors for the motion vector of the upper left sample of the current block, the motion vectors of the neighboring coded blocks B1 and B0 of the upper right sample are used as candidate motion vectors for the motion vector of the upper right sample of the current block, and the motion vectors of the neighboring coded blocks A0 and A1 of the lower left sample are used as candidate motion vectors for the motion vector of the lower left sample of the current block. The candidate motion vector of the upper left sample, the candidate motion vector of the upper right sample, and the candidate motion vector of the lower left sample are combined to form a 3-tuple. The motion vectors of the three coded blocks included in the 3-tuple can be used as candidate control point motion vectors of the current block, as shown in Equation (11B) and Equation (11C). Formula (11B)

number

number

[0194] It should be noted that other methods for combining control point motion vectors are also applicable to the present application, and will not be described in detail here.

[0195] It should be noted that methods in which other control points are used to represent the motion models of the neighboring and current coding blocks are also applicable to the present application, and will not be described in detail here.

[0196] (5) Method 2 for predicting constructed control point motion vectors shown in FIG. 5B

[0197] Step 501: Obtain the motion information of the control points of the current block.

[0198] For example, in Fig. 5A, CPk (k=1,2,3,4) represents the kth control point. A0, A1, A2, B0, B1, B2, and B3 are spatially adjacent positions of the current block and are used to predict CP1, CP2, or CP3. T is a temporally adjacent position of the current block and is used to predict CP4.

[0199] Assume that the coordinates of CP1, CP2, CP3 and CP4 are (0,0), (W,0), (H,0) and (W,H), respectively, where W and H represent the width and height of the current block.

[0200] The motion information of each control point is obtained in the following order.

[0201] (1) For CP1, the check order is B2->A2->B3. If B2 is available, the motion information of B2 is used. If not, A2 and B3 are checked. If the motion information of all three positions is not available, the motion information of CP1 cannot be obtained.

[0202] (2) For CP2, the check order is B0->B1. If B0 is available, the motion information of B0 is used for CP2; otherwise, B1 is checked. If the motion information of both positions is not available, the motion information of CP2 cannot be obtained.

[0203] (3) In the case of CP3, the check order is A0->A1.

[0204] (4) In the case of CP4, the motion information of T is used.

[0205] Here, X being available means that the block containing the X (X is A0, A1, A2, B0, B1, B2, B3 or T) position is coded and the inter prediction mode is used. Otherwise, the X position is not available.

[0206] It should be noted that other methods for obtaining the motion information of the control points are also applicable to the present application, and will not be described in detail here.

[0207] Step 502: Combining the motion information of the control points to obtain constructed control point motion information.

[0208] The motion information of two control points is combined to form a 2-tuple to construct a four-parameter affine motion model. Two control points can be combined as {CP1,CP4}, {CP2,CP3}, {CP1,CP2}, {CP2,CP4}, {CP1,CP3}, or {CP3,CP4}. For example, a four-parameter affine motion model constructed by using a 2-tuple based on the motion information (e.g., 2MV) of control points CP1 and CP2 can be represented as Affine(CP1,CP2).

[0209] The motion information of the three control points is combined to form a 3-tuple to construct a 6-parameter affine motion model. The three control points can be combined as {CP1,CP2,CP4}, {CP1,CP2,CP3}, {CP2,CP3,CP4} or {CP1,CP3,CP4}. For example, a 6-parameter affine motion model constructed by using a 3-tuple based on the motion information of control points CP1, CP2 and CP3 (e.g., 3MV) can be represented as Affine(CP1,CP2,CP3).

[0210] The motion information of the four control points is combined to form a 4-tuple to construct an 8-parameter bilinear motion model. The 8-parameter bilinear model constructed by using a 4-tuple containing the motion information of control points CP1, CP2, CP3, and CP4 (e.g., 4MV) is denoted as Bilinear(CP1,CP2,CP3,CP4).

[0211] In this embodiment of the application, for ease of explanation, a combination of motion information of two control points (or two coding blocks) is abbreviated to a 2-tuple, a combination of motion information of three control points (or three coding blocks) is abbreviated to a 3-tuple, and a combination of motion information of four control points (or four coding blocks) is abbreviated to a 4-tuple.

[0212] These models are traversed in a preset order. If the motion information of a particular control point corresponding to the combined model is not available, the model is deemed to be unavailable. Otherwise, the reference image index of the model is determined and the motion vector of the control point is scaled. If the motion information of all the control points obtained after scaling is consistent, the model is invalid. If all the motion information of the control points that control the model is available and the model is valid, the motion information of the control points for constructing the model is added to the motion information candidate list.

[0213] The control point motion vector scaling method is shown in equation (12). Formula (12)

number

[0214] It should be noted that a combination of different control points can be transformed into a control point at the same location.

[0215] For example, a four-parameter affine motion model obtained by using the combination of {CP1,CP4}, {CP2,CP3}, {CP2,CP4}, {CP1,CP3} or {CP3,CP4} is transformed to {CP1,CP2} or {CP1,CP2,CP3}. The transformation method is to obtain the model parameters by substituting the motion vectors of the control points and the coordinate information of the control points into equation (2), and then to obtain the motion vectors of CP1 and CP2 by substituting the coordinate information of {CP1,CP2} into equation (3).

[0216] More directly, the conversion may be performed according to equations (13)-(21). W represents the width of the current block. H represents the height of the current block. In equations (13)-(21), (vx0, vy0) represents the motion vector of CP1, (vx1, vy1) represents the motion vector of CP2, (vx2, vy2) represents the motion vector of CP3, and (vx3, vy3) represents the motion vector of CP4.

[0217] {CP1, CP2} can be transformed to {CP1, CP2, CP3} by using equation (13). In other words, the motion vector of CP3 in {CP1, CP2, CP3} can be determined using equation (13). Formula (13)

number

[0218] {CP1,CP3} can be converted to {CP1,CP2} or {CP1,CP2,CP3} by using equation (14). Formula (14)

number

[0219] {CP2,CP3} can be converted to {CP1,CP2} or {CP1,CP2,CP3} by using equation (15). Formula (15)

number

[0220] {CP1,CP4} can be converted to {CP1,CP2} or {CP1,CP2,CP3} by using equations (16) or (17). Formula (16)

number

number

[0221] {CP2,CP4} can be converted to {CP1,CP2} by using equation (18), and {CP2,CP4} can be converted to {CP1,CP2,CP3} by using equations (18) and (19). Formula (18)

number

number

[0222] {CP3,CP4} can be converted to {CP1,CP2} by using equation (20), and {CP3,CP4} can be converted to {CP1,CP2,CP3} by using equations (20) and (21). Formula (20)

number

number

[0223] For example, a six-parameter affine motion model obtained by using combinations {CP1,CP2,CP4}, {CP2,CP3,CP4}, or {CP1,CP3,CP4} is transformed to control points {CP1,CP2,CP3}. The transformation method is to obtain the model parameters by substituting equation (4) with the motion vectors of the control points and the coordinate information of the control points, and then to obtain the motion vectors of CP1, CP2, and CP3 by substituting equation (5) with the coordinate information of {CP1,CP2,CP3}.

[0224] More directly, the conversion may be performed according to equations (22) to (24). W represents the width of the current block. H represents the height of the current block. In equations (13) to (21), (vx0, vy0) represents the motion vector of CP1, (vx1, vy1) represents the motion vector of CP2, (vx2, vy2) represents the motion vector of CP3, and (vx3, vy3) represents the motion vector of CP4.

[0225] {CP1, CP2, CP4} can be transformed to {CP1, CP2, CP3} according to equation (22). Formula (22)

number

[0226] {CP2, CP3, CP4} can be transformed to {CP1, CP2, CP3} according to equation (23). Formula (23)

number

[0227] {CP1, CP3, CP4} can be transformed to {CP1, CP2, CP3} according to equation (24). Formula (24)

number

[0228] (6) Affine motion model type advanced motion vector prediction mode (Affine AMVP mode)

[0229] 1. Building a list of candidate motion vectors

[0230] The candidate motion vector list of the affine motion model type AMVP mode is constructed by using a method for predicting the inherited control point motion vector and / or the constructed control point motion vector. In this embodiment of the present application, the candidate motion vector list of the affine motion model type AMVP mode can be referred to as a control point motion vector predictor candidate list, and each control point motion vector predictor includes the motion vectors of two (four-parameter affine motion model) control points or the motion vectors of three (six-parameter affine motion model) control points.

[0231] Optionally, the control point motion vector predictor candidate list may be pruned and sorted according to certain rules and truncated or padded to a certain number.

[0232] 2. Determining the optimal control point motion vector prediction value

[0233] At the encoder side, the motion vector of each motion compensation sub-unit in the current coding block is obtained according to formula (3) / (5) by using each control point motion vector predictor in the control point motion vector predictor candidate list. Furthermore, the pixel value of the corresponding position in the reference frame pointed to by the motion vector of each motion compensation sub-unit is obtained and used as the predicted value of the pixel value to perform motion compensation by using the affine motion model. The average value of the difference between the original value and the predicted value of all samples in the current coding block is calculated. The control point motion vector predictor corresponding to the minimum average value is selected as the optimal control point motion vector predictor, and is used as the 2 / 3 control point motion vector predictor of the current coding block. An index number representing the position of the control point motion vector predictor in the control point motion vector predictor candidate list is coded into the bitstream and transmitted to the decoder.

[0234] At the decoder side, the index number is analyzed, and a control point motion vectors predictor (CPMVP) is determined from the control point motion vector predictor candidate list based on the index number.

[0235] 3. Determining control point motion vectors

[0236] At the encoder side, the control point motion vector prediction value is used as a search starting point for motion search within a certain search range to obtain control point motion vectors (CPMV). The difference between the control point motion vector and the control point motion vector prediction value (control point motion vector differences (CPMVD)) is transferred to the decoder side.

[0237] At the decoder side, the control point motion vector difference is analyzed, and the control point motion vector difference and the control point motion vector prediction value are added to obtain the control point motion vector.

[0238] (7) Affine Merge mode

[0239] A control point motion vectors merge candidate list is constructed by using a method for predicting the inherited control point motion vectors and / or the constructed control point motion vectors.

[0240] Optionally, the control point motion vector merge candidate list may be pruned and sorted according to certain rules, and truncated or padded to a certain number.

[0241] At the encoder side, by using each control point motion vector in the merge candidate list, the motion vector of each motion compensation sub-unit (sample or pixel block with a size of N1×N2 obtained through partitioning according to a specific method) in the current coding block is obtained according to formula (3) / (5). Furthermore, the pixel value of the position in the reference frame pointed to by the motion vector of each motion compensation sub-unit is obtained and used as the predicted value of the pixel value to perform affine motion compensation. The average value of the difference between the original value and the predicted value of all samples in the current coding block is calculated. The control point motion vector corresponding to the minimum average value of the difference is selected as the 2 / 3 control point motion vector of the current coding block. The index number representing the position of the motion vector of the control point in the candidate list is coded into the bitstream and transmitted to the decoder.

[0242] At the decoder side, the index number is analyzed, and control point motion vectors (CPMVs) are determined from the control point motion vector merge candidate list based on the index number.

[0243] In addition, it should be noted that in this application, "at least one" means one or more, and "multiple" means two or more than two. The term "and / or" describes a correspondence between related objects and indicates that three relationships may exist. For example, A and / or B may represent the following cases: only A is present, both A and B are present, and only B is present. Here, A and B may be singular or plural. The character " / " generally indicates an "or" relationship between related objects. "At least one of the following items (elements)" or similar expressions refers to any combination of these items, including any combination of single items (elements) or multiple items (elements). For example, at least one of a, b, or c may refer to a, b, c, a and b, a and c, b and c, or a, b, and c. Here, a, b, and c may be singular or plural.

[0244] In this application, if the current block is decoded by using an inter prediction mode, the inter prediction mode may be signaled by using a syntax element.

[0245] For a portion of the syntax structure currently used to analyze the inter-prediction mode used for the current block, see Table 1. It should be noted that the syntax elements in the syntax structure may alternatively be represented by other identifiers, which is not specifically limited in this application. [Table 1]

[0246] The syntax element merge_flag[x0][y0] may be used to indicate whether merge mode is used for the current block. For example, merge_flag[x0][y0]=1 indicates that merge mode is used for the current block. Or, merge_flag[x0][y0]=0 indicates that merge mode is not used for the current block. x0 and y0 represent the coordinates of the current block relative to the video image.

[0247] The variable allowAffineMerge may be used to indicate whether the condition for enabling the affine motion model type merge mode for the current block is met. For example, when allowAffineMerge=0, it indicates that the condition for enabling the affine motion model type merge mode is not met. Or, when allowAffineMerge=1, it indicates that the condition for the affine motion model type merge mode is met. The condition for enabling the affine motion model type merge mode may be that both the width and height of the current block are equal to or greater than 8. cbWidth represents the width of the current block, and cbHeight represents the height of the current block. That is, when cbWidth<8 or cbHeight<8, allowAffineMerge=0. Or, when cbWidth≧8 and cbHeight≧8, allowAffineMerge=1.

[0248] The variable allowAffineInter may be used to indicate whether the condition for enabling the affine motion model AMVP mode for the current block is met. For example, when allowAffineInter=0, it indicates that the condition for enabling the affine motion model AMVP mode is not met. Or, when allowAffineInter=1, it indicates that the condition for enabling the affine motion model AMVP mode is met. The condition for enabling the affine motion model AMVP mode may be that both the width and height of the current block are equal to or greater than 16. In other words, when cbWidth<16 or cbHeight<16, allowAffineInter=0. Or, when cbWidth≧16 and cbHeight≧16, allowAffineInter=1.

[0249] The syntax element affine_merge_flag[x0][y0] may be used to indicate whether an affine motion model type merge mode is used for the current block when the slice containing the current block is a P slice or a B slice. For example, when affine_merge_flag[x0][y0]=1, it indicates that an affine motion model type merge mode is used for the current block. Or, when affine_merge_flag[x0][y0]=0, it indicates that an affine motion model type merge mode is not used for the current block and a translational motion model type merge mode may be used.

[0250] The syntax element affine_inter_flag[x0][y0] may be used to indicate whether the affine motion model AMVP mode is used for the current block when the slice containing the current block is a P slice or a B slice. For example, when affine_inter_flag[x0][y0]=1, it indicates that the affine motion model AMVP mode is used for the current block. Or, when affine_inter_flag[x0][y0]=0, it indicates that the affine motion model AMVP mode is not used for the current block and the translational motion model AMVP mode may be used.

[0251] The syntax element affine_type_flag[x0][y0] may be used to indicate whether 6-parameter affine motion model type motion compensation is used for the current block when the slice including the current block is a P slice or a B slice. When affine_type_flag[x0][y0]=0, it indicates that 6-parameter affine motion model type motion compensation is not used for the current block and only 4-parameter affine motion model type motion compensation may be used for the current block. Or, when affine_type_flag[x0][y0]=1, it indicates that 6-parameter affine motion model type motion compensation is used for the current block.

[0252] As shown in Table 2, when MotionModelIdc[x0][y0]=1, it indicates that a four-parameter affine motion model is used, when MotionModelIdc[x0][y0]=2, it indicates that a six-parameter affine motion model is used, or when MotionModelIdc[x0][y0]=0, it indicates that a translational motion model is used. [Table 2]

[0253] The variable MaxNumMergeCand is used to represent the maximum list length, indicating the maximum number of candidates in the constructed candidate motion vector list. inter_pred_idc[x0][y0] is used to indicate the prediction direction. PRED_L1 is used to indicate backward prediction. num_ref_idx_l0_active_minus1 indicates the number of reference frames in the forward reference frame list (list 0), and ref_idx_l0[x0][y0] indicates the forward (list 0) reference image index for the current block. mvd_coding(x0,y0,0,0) indicates the first motion vector difference. mvp_l0_flag[x0][y0] indicates the MVP candidate index in the forward MVP candidate list (list 0). PRED_L0 indicates forward prediction. num_ref_idx_l1_active_minus1 indicates the number of reference frames in the backward reference frame list (list 1). ref_idx_l1[x0][y0] indicates the backward (list 1) reference image index for the current block, and mvp_l1_flag[x0][y0] indicates the MVP candidate index in the backward MVP candidate list (list 1).

[0254] In Table 1, ae(v) represents a syntax element that is coded by using context-based adaptive binary arithmetic coding (CABAC).

[0255] The inter prediction process is described in detail below, see Figure 6A.

[0256] Step 601: Parse the bitstream based on the syntax structure shown in Table 1, and determine the inter prediction mode of the current block.

[0257] If it is determined that the inter prediction mode of the current block is an affine motion model type AMVP mode, step 602a is executed.

[0258] That is, when merge_flag=0 and affine_inter_flag=1, it indicates that the inter prediction mode of the current block is the affine motion model type AMVP mode.

[0259] If it is determined that the inter prediction mode of the current block is the affine motion model type merge mode, step 602b is executed.

[0260] That is, in the syntax element, merge_flag = 1 and affine_merge_flag = 1 indicate that the inter prediction mode of the current block is the affine motion model type merge mode.

[0261] Step 602a: Construct a candidate motion vector list corresponding to the affine motion model type AMVP mode, and execute step 603a.

[0262] Candidate control point motion vectors for the current block are derived by using a method for predicting the inherited control point motion vectors and / or the constructed control point motion vectors, and are added to a candidate motion vector list.

[0263] The candidate motion vector list may include a 2-tuple list (the current coding block is a 4-parameter affine motion model) or a 3-tuple list. The 2-tuple list contains one or more 2-tuples used to build a 4-parameter affine motion model. The 3-tuple list contains one or more 3-tuples used to build a 6-parameter affine motion model.

[0264] Optionally, the candidate motion vector 2-tuple / 3-tuple list may be pruned and sorted according to a particular rule, truncated to a particular number, or padded.

[0265] A1: A description is provided of a procedure for building a candidate motion vector list by using a method to predict inherited control point motion vectors.

[0266] FIG. 4 is used as an example. For example, the blocks at adjacent positions around the current block are traversed in the order A1->B1->B0->A0->B2 in FIG. 4 to find the affine coding block in which the blocks at adjacent positions are located, and obtain the control point motion information of the affine coding block. Furthermore, a motion model is constructed by using the control point motion information of the affine coding block, and the candidate control point motion information of the current block is derived. For details, please refer to the related description of the method for predicting the inherited control point motion vector in (3). Details are not described here.

[0267] For example, the affine motion model used for the current block is a four-parameter affine motion model (i.e., MotionModelIdc=1). If the neighboring affine-coded block is a four-parameter affine motion model, the motion vectors of two control points of the affine-coded block are obtained, namely, the motion vector (vx4,vy4) of the top-left control point (x4,y4) and the motion vector (vx5,vy5) of the top-right control point (x5,y5). The affine-coded block is an affine-coded block that is predicted in the coding phase by using the affine motion model.

[0268] The motion vectors for the top-left control point and the top-right control point of the current block are derived according to equations (6) and (7), respectively, corresponding to the four-parameter affine motion model by using a four-parameter affine motion model that includes two control points of adjacent affine-coded blocks.

[0269] When a six-parameter affine motion model is used for adjacent affine-coded blocks, motion vectors of three control points of the adjacent affine-coded blocks are obtained, for example, the motion vector (vx4, vy4) of the upper left control point (x4, y4), the motion vector (vx5, vy5) of the upper right control point (x5, y5), and the motion vector (vx6, vy6) of the lower left control point (x6, y6) in Figure 4.

[0270] The motion vector of the top-left control point and the top-right control point of the current block are derived according to equations (8) and (9), respectively, corresponding to the six-parameter affine motion model by using a six-parameter affine motion model that includes three control points of adjacent affine-coded blocks.

[0271] For example, the affine motion model of the current decoded block is a 6-parameter affine motion model (ie, MotionModelIdc=2).

[0272] If the affine motion model used for the adjacent affine coded block is a six-parameter affine motion model, the motion vectors of three control points of the adjacent affine coded block are obtained, for example, the motion vector (vx4, vy4) of the upper left control point (x4, y4), the motion vector (vx5, vy5) of the upper right control point (x5, y5), and the motion vector (vx6, vy6) of the lower left control point (x6, y6) in Figure 4.

[0273] The motion vectors for the top-left control point, the top-right control point, and the bottom-left control point of the current block are derived according to equations (8), (9), and (10), respectively, corresponding to the six-parameter affine motion model by using a six-parameter affine motion model that includes three control points of adjacent affine-coded blocks.

[0274] If the affine motion model used for the adjacent affine coded block is a four-parameter affine motion model, the motion vectors of two control points of the affine coded block are obtained, i.e., the motion vector (vx4, vy4) of the top-left control point (x4, y4) and the motion vector (vx5, vy5) of the top-right control point (x5, y5).

[0275] The motion vectors for the top-left control point, the top-right control point, and the bottom-left control point of the current block are derived according to equations (6) and (7), respectively, corresponding to the four-parameter affine motion model by using a four-parameter affine motion model that includes two control points of adjacent affine-coded blocks.

[0276] It should be noted that other motion models, candidate positions, and search orders are also applicable to the present application, and will not be described in detail here. It should be noted that other methods in which control points are used to represent the motion models of the neighboring and current coding blocks are also applicable to the present application, and will not be described in detail here.

[0277] A2: Provides a description of the procedure for constructing a candidate motion vector list by using a method for predicting a constructed control motion vector.

[0278] For example, the affine motion model used for the current decoding block is a four-parameter affine motion model (i.e., MotionModelIdc is 1). In this case, the motion vectors of the upper left sample and the upper right sample of the current coding block are determined by using the motion information of the neighboring coding blocks around the current coding block. Specifically, the candidate motion vector list can be constructed by method 1 or method 2, which predicts the constructed control point motion vector. For specific methods, please refer to the descriptions of (4) and (5). Details will not be described here.

[0279] For example, if the affine motion model used for the current decoding block is a 6-parameter affine motion model (i.e., MotionModelIdc is 2), the motion vectors of the top-left sample, the top-right sample, and the bottom-left sample of the current coding block are determined by using the motion information of the neighboring coding blocks around the current coding block. Specifically, the candidate motion vector list can be constructed by method 1 or method 2 of predicting the constructed control point motion vector. For specific methods, please refer to the description of (4) and (5). Details will not be described here.

[0280] It should be noted that other combinations of control point motion information are also applicable to the present application, and will not be described in detail here.

[0281] Step 603a: Analyze the bitstream to determine an optimal control point motion vector predictor, and execute step 604a.

[0282] B1: If the affine motion model used for the current decoding block is a four-parameter affine motion model (MotionModelIdc is 1), obtain an index number through analysis, and determine the optimal motion vector prediction value of two control points from the candidate motion vector list based on the index number.

[0283] For example, the index number is mvp_l0_flag or mvp_l1_flag.

[0284] B2: If the affine motion model used for the current decoding block is a 6-parameter affine motion model (MotionModelIdc is 2), obtain an index number through analysis, and determine the optimal motion vector prediction value of the three control points from the candidate motion vector list based on the index number.

[0285] Step 604a: Analyze the bitstream to determine control point motion vectors.

[0286] C1: When the affine motion model used for the current decoded block is a four-parameter affine motion model (MotionModelIdc is 1), decode the bitstream to obtain the motion vector difference of two control points of the current block, and obtain the control point motion vector according to the motion vector difference and the motion vector prediction value of the control point. Forward prediction is used as an example. The motion vector difference pointed to by the two control points is mvd_coding(x0,y0,0,0) and mvd_coding(x0,y0,0,1).

[0287] For example, the motion vector difference of the top-left control point and the top-right control point is obtained by decoding the bitstream and added to the motion vector prediction value respectively to obtain the motion vectors of the top-left control point and the top-right control point of the current block.

[0288] C2: When the affine motion model of the current decoded block is a 6-parameter affine motion model (i.e., MotionModelIdc is 2), decode the bitstream to obtain the motion vector difference of three control points of the current block, and obtain the control point motion vector according to the motion vector difference and the motion vector prediction value of the control point. Forward prediction is used as an example. The motion vector difference of the three control points are mvd_coding(x0,y0,0,0), mvd_coding(x0,y0,0,1) and mvd_coding(x0,y0,0,2).

[0289] For example, the motion vector differences of the top-left control point, the top-right control point, and the bottom-left control point are obtained by decoding the bitstream, and added to the motion vector prediction value respectively to obtain the motion vectors of the top-left control point, the top-right control point, and the bottom-left control point of the current block.

[0290] Step 602b: Construct a motion information candidate list for the affine motion model type merge mode.

[0291] Specifically, a motion information candidate list for an affine motion model type merge mode may be constructed by using a method for predicting inherited control point motion vectors and / or constructed control point motion vectors.

[0292] Optionally, the motion information candidate list may be pruned and sorted according to certain rules and truncated or padded to a certain number.

[0293] D1: A description of the procedure for building a candidate motion vector list by using a method for predicting an inherited control motion vector is provided.

[0294] The candidate control point motion information of the current block is derived by using a method for predicting the inherited control point motion vectors and added to the motion information candidate list.

[0295] The blocks in the neighboring positions around the current block are traversed in the order of A1, B1, B0, A0 and B2 in Fig. 5A to find the affine-coded blocks in the neighboring positions and obtain the control point motion information of the affine-coded blocks. Furthermore, the candidate control point motion information of the current block is further derived by using a motion model constructed from the control point motion information of the affine-coded blocks.

[0296] If the candidate motion vector list is empty at this time, the candidate control point motion information is added to the candidate list. Otherwise, the motion information in the candidate motion vector list is traversed sequentially to check whether motion information identical to the candidate control point motion information exists in the candidate motion vector list. If the motion information identical to the candidate control point motion information does not exist in the candidate motion vector list, the candidate control point motion information is added to the candidate motion vector list.

[0297] To determine whether two candidate motion information are identical, it is necessary to determine sequentially whether the forward reference frame, the backward reference frame, the horizontal and vertical components of each forward motion vector, and the horizontal and vertical components of each backward motion vector in one candidate motion information are identical to those of another candidate motion information. Only if all of the aforementioned elements are different, the two candidate motion information are regarded as different candidate motion information.

[0298] When the number of motion information in the candidate motion vector list reaches the maximum list length MaxNumMrgCand (MaxNumMrgCand is a positive integer such as 1, 2, 3, 4 or 5, and 5 is used as an example in the following description, and details are not described here), the construction of the candidate list is completed. Otherwise, the block in the next adjacent position is traversed.

[0299] D2: Derive candidate control point motion information of the current block by using a method for predicting the constructed control point motion vector, and add the candidate control point motion information to a motion information candidate list, as shown in FIG. 6B.

[0300] Step 601c: Obtain motion information of the control points of the current block. See step 501 in method 2 for predicting the constructed control point motion vector in (5). Details are not described again here.

[0301] Step 602c: Combine the motion information of the control points to obtain constructed control point motion information. Please refer to step 501 in Figure 5B. Details will not be described again here.

[0302] Step 603c: Add the constructed control point motion information to a candidate motion vector list.

[0303] If the length of the candidate list is less than the maximum list length MaxNumMrgCand at this point, these combinations are traversed in a preset order to obtain valid combinations as candidate control point motion information. If the candidate motion vector list is empty at this point, the candidate control point motion information is added to the candidate motion vector list. Otherwise, the motion information in the candidate motion vector list is traversed sequentially to check whether motion information identical to the candidate control point motion information exists in the candidate motion vector list. If motion information identical to the candidate control point motion information does not exist in the candidate motion vector list, the candidate control point motion information is added to the candidate motion vector list.

[0304] For example, the pre-defined order is Affine(CP1,CP2,CP3)->Affine(CP1,CP2,CP4)->Affine(CP1,CP3,CP4)->Affine(CP2,CP3,CP4)->Affine(CP1,CP2)->Affine(CP1,CP3)->Affine(CP2,CP3)->Affine(CP1,CP4)->Affine(CP2,CP4)->Affine(CP3,CP4). There are 10 combinations in total.

[0305] If the control point motion information corresponding to the combination is not available, the combination is deemed unavailable. If the combination is available, the reference image index of the combination is determined (for two control points, the minimum reference image index is selected as the reference image index of the combination, for more than two control points, the most frequently occurring reference image index is selected, and if multiple reference image indexes appear the same number of times, the minimum reference image index is selected as the reference image index of the combination), and the control point motion vectors are scaled. If the motion information of all control points obtained after scaling is consistent, the combination is invalid.

[0306] Optionally, in this embodiment of the present application, the candidate motion vector list may be further padded. For example, if after the above traversal process, the length of the candidate motion vector list is less than the maximum list length MaxNumMrgCand, the candidate motion vector list may be padded until the length of the list is equal to MaxNumMrgCand.

[0307] The padding can be performed by filling with zero motion vectors, or by combining or weighted averaging existing candidate motion information in the existing list. It should be noted that other methods for padding the candidate motion vector list are also applicable to the present application, and will not be described in detail here.

[0308] Step S603b: Analyze the bitstream to determine optimal control point motion information.

[0309] The index number is analyzed, and the optimal control point motion information is determined from the candidate motion vector list based on the index number.

[0310] Step 604b: Obtain a motion vector for each sub-block of the current block based on the optimal control point motion information and the affine motion model used for the current decoded block.

[0311] For each subblock (subblock may also be equal to a motion compensation unit, and the width and height of the subblock are smaller than the width and height of the current block) of the current affine coding block, the motion information of a sample at a preset position in the motion compensation unit may be used to represent the motion information of all samples in the motion compensation unit. Assuming the size of the motion compensation unit is M×N, in this case, the sample at the preset position may be the center sample (M / 2, N / 2), the top-left sample (0, 0), the top-right sample (M-1, 0), or a sample at another position of the motion compensation unit. The following provides an explanation by using the center pixel of the motion compensation unit as an example. Please refer to FIG. 6C. In FIG. 6C, V0 represents the motion vector of the top-left control point, and V1 represents the motion vector of the top-right control point. Each small square frame represents one motion compensation unit.

[0312] The coordinates of the center sample of a motion compensation unit relative to the top-left sample of the current affine-coded block are calculated by using equation (25), where i is the ith motion compensation unit in the horizontal direction (left to right), j is the jth motion compensation unit in the vertical direction (top to bottom), and (x (i.j) ,y (i,j) ) represents the coordinates of the center sample of the (i,j)th motion compensation unit relative to the top-left sample of the current affine-coded block.

[0313] If the affine motion model used for the current affine coded block is a 6-parameter affine motion model, then (x (i.j) ,y (i,j) ) is substituted into equation (26) corresponding to the six-parameter affine motion model to obtain the motion vector of the center sample of each motion compensation unit, and the motion vector of the center sample of each motion compensation unit is the motion vector of all samples of the motion compensation unit (vx (i,j) ,vy (i,j) ) is used.

[0314] If the affine motion model used for the current affine coded block is a four-parameter affine motion model, then (x (i.j) ,y (i,j) ) is substituted into equation (27) corresponding to the four-parameter affine motion model to obtain the motion vector of the center sample of each motion compensation unit, and the motion vector of the center sample of each motion compensation unit is the motion vector of all samples of the motion compensation unit (vx (i,j) ,vy (i,j) ) is used. Formula (25)

number

number

number

[0315] Step 605b: Perform motion compensation for each sub-block based on the determined motion vector of the sub-block to obtain a predicted pixel value of the sub-block.

[0316] In the prior art, both the parameter information of the four-parameter affine motion model and the parameter information of the six-parameter affine motion model, for example, affine_merge_flag, affine_inter_flag and affine_type_flag in Table 1, need to be transmitted to the decoder side through the bitstream. If the current video image or slice does not have affine transformation characteristics, the transmission of the parameter information increases the number of bits in the bitstream. In addition, the parameter information indicating whether the affine motion model is used for each coding block needs to be analyzed at the decoder side. As a result, the load of the decoder may increase, the processing speed may decrease, and the processing time may increase.

[0317] On this basis, the embodiments of the present application provide a video image prediction method and apparatus, which solves the problem in the prior art that the number of bits in a bitstream increases. The method and the apparatus are based on the same inventive concept. The problem-solving principle of the method is similar to that of the apparatus, so cross-reference may be made to the implementation of the apparatus and the method. No repeated description is provided.

[0318] To solve the above problems, the embodiments of the present application provide several possible implementations, including but not limited to the following.

[0319] In a first possible implementation, for example, some video pictures may have some affine properties and some video pictures may not have affine properties, in which case an identifier may be added to the bitstream to indicate whether an affine motion model type inter prediction mode is in effect for a video picture.

[0320] In a second possible implementation, for example, not all slices in a video image have affine properties, and an identifier may be added to the bitstream to indicate whether an affine motion model type inter prediction mode is enabled for a slice.

[0321] In a third possible implementation, for example, some video pictures do not have affine properties, and not all slices of some video pictures have affine properties. In this case, two types of identifiers may be added to the bitstream. A first type of identifier is used to indicate whether an affine motion model type inter prediction mode is enabled for a video picture, and a second type of identifier is used to indicate whether an affine motion model type inter prediction mode is enabled for a slice in the video picture.

[0322] For ease of subsequent description, the identifier used to indicate whether an affine motion model type inter prediction mode is valid for a video image will be referred to as identifier 1, and the identifier used to indicate whether an affine motion model type inter prediction mode is valid for a slice contained in the video image will be referred to as identifier 2.

[0323] In the above three possible implementations, for an image block included in a video image or slice that does not need to use an affine motion model, there may be no need to transmit parameters related to the affine motion model of the image block, such as affine_merge_flag, affine_inter_flag, or affine_type_flag in Table 1. At the decoder side, during the decoding of the image block, the parameters related to the affine motion model do not need to be analyzed. This can reduce the load of the decoder, increase the processing speed, and reduce the processing time.

[0324] In the following, from the decoder side perspective, the above-mentioned multiple possible implementations provided in the present application will be described in detail with reference to the accompanying drawings. Specifically, the possible implementations can be performed by the video decoder 30, or can be performed by a motion compensation module in the video decoder, or can be performed by a processor.

[0325] See Figure 7. A first possible implementation is described.

[0326] Step 701: Parse the bitstream to obtain identifier 1.

[0327] The identifier 1 is used to indicate whether the candidate motion models for inter prediction of the video image including the current block include an affine motion model. In other words, the identifier 1 is used to indicate whether affine motion model-based motion compensation is enabled for the video image including the current block.

[0328] For example, identifier 1 may be configured in the SPS of the bitstream. Based on this, parsing the bitstream to obtain identifier 1 may be implemented in a manner of parsing the SPS of the bitstream to obtain identifier 1.

[0329] Step 702: When identifier 1 indicates that the candidate motion models for inter prediction of the video image including the current block include an affine motion model and the current block satisfies preset conditions for inter prediction using the affine motion model, analyze the bitstream to obtain identifier 12.

[0330] Optionally, the pre-set conditions may include at least one of the following cases:

[0331] The width of the target block is greater than or equal to a first preset threshold, and the height of the target block is greater than or equal to a second preset threshold.

[0332] The first preset threshold value may be equal to the second preset threshold value. For example, when the inter prediction mode is a merge mode, the preset condition may be that the width of the processing target block is equal to or greater than 8, and that the height of the processing target block is equal to or greater than 8. When the inter prediction mode is an AMVP mode, the preset condition may be that the width of the processing target block is equal to or greater than 16, and that the height of the processing target block is equal to or greater than 16.

[0333] For example, when the inter prediction mode is a merge mode, whether the current block satisfies a preset condition for inter prediction using an affine motion model may be represented by a variable allowAffineMerge. For example, when the inter prediction mode is an AMVP mode, whether the current block satisfies a preset condition for inter prediction using an affine motion model may be represented by a variable allowAffineInter. Please refer to Table 1 for related descriptions of allowAffineMerge and allowAffineInter. Details will not be described again here.

[0334] For example, when identifier 1 indicates that the candidate motion models for inter prediction of an image block in a video image including the current block do not include an affine motion model, parameter information related to the affine motion model does not need to be analyzed when inter prediction is performed on the image block of the video image. For example, the bitstream does not need to be analyzed to obtain identifier 12.

[0335] For example, when identifier 1 is value A, it indicates that candidate motion models for inter prediction of image blocks in a video image including the current block include an affine motion model, or when identifier 1 is value B, it indicates that candidate motion models for inter prediction of image blocks in a video image including the current block do not include an affine motion model. For example, when identifier 1 is 1, it indicates that candidate motion models for inter prediction of image blocks in a video image including the current block include an affine motion model, or when identifier 1 is 0, it indicates that candidate motion models for inter prediction of image blocks in a video image including the current block do not include an affine motion model.

[0336] Step 703: Determine a prediction mode for inter prediction of the current block based on the identifier 12. The prediction mode includes an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type prediction mode.

[0337] For example, identifier 1 may be represented by the syntax element sps_affine_enabled_flag. sps_affine_enabled_flag specifies whether affine model type motion compensation is enabled for inter prediction (sps_affine_enabled_flag specifies whether affine model type motion compensation can be used for inter prediction). For example, sps_affine_enabled_flag is equal to 0, the syntax element is restricted so that affine model type motion compensation is not used in CVS, and affine_merge_flag, affine_inter_flag, and affine_type_flag are not indicated in the image block level syntax of CVS. sps_affine_enabled_flag is equal to 1, and affine model type motion compensation can be used in CVS. (If sps_affine_enabled_flag is equal to 0, the syntax elements are restricted so that affine-model-based motion compensation is not used in CVS, and affine_merge_flag, affine_inter_flag, and affine_type_flag are not indicated in the coding unit level syntax of CVS. Otherwise (sps_affine_enabled_flag is equal to 1), affine-model-based motion compensation may be used in CVS.)

[0338] For example, when the inter prediction mode is an AMVP mode, the identifier 12 may be represented by a syntax element affine_inter_flag, or when the inter prediction mode is a merge mode, the identifier 12 may be represented by a syntax element affine_merge_flag. For related descriptions of affine_inter_flag and affine_merge_flag, please refer to the description of Table 1. Details will not be described again here.

[0339] In a first possible implementation, in a possible example, the identifier 13 may further be configured in the bitstream. The identifier 13 may be configured in the sequence parameter set of the bitstream. When the affine motion model type merge mode is used for inter prediction of the current block, when the identifier 1 obtained by analyzing the bitstream indicates that the candidate motion models for inter prediction of the image block in the video image including the current block include an affine motion model, the bitstream is analyzed to obtain the identifier 13. When the identifier 13 is a first value, the affine motion model includes only a four-parameter affine model. Or, when the identifier 13 is a second value, the affine motion model includes a four-parameter affine model and a six-parameter affine model. The first value is different from the second value. For example, the first value is 1 and the second value is 0. Or, the first value is 0 and the second value is 1.

[0340] For example, identifier 13 may be represented by sps_affine_type_flag. sps_affine_type_flag specifies whether 6-parameter affine model type motion compensation is enabled for inter prediction. For example, sps_affine_type_flag is equal to 0, and the syntax element is restricted such that 6-parameter affine model type motion compensation is not used in the CVS, and affine_type_flag is not indicated in the image block level syntax in the CVS. (sps_affine_type_flag specifies whether six-parameter affine model motion compensation can be used for inter prediction. If sps_affine_type_flag is equal to 0, the syntax element is restricted so that six-parameter affine model motion compensation is not used in CVS, and affine_type_flag is not indicated in the cu-level syntax in CVS. Otherwise (sps_affine_type_flag is equal to 1), six-parameter affine model motion compensation may be used in CVS. When not present, the value of sps_affine_type_flag is inferred to be equal to 0.

[0341] In a first possible implementation, in a possible example, when the identifier 12 indicates that an affine motion model type AMVP mode is used for inter prediction of the block to be processed and the identifier 13 is a second value, the bitstream needs to be parsed to obtain the identifier 14. When the identifier 14 is a third value, the affine motion model is a six-parameter affine motion model. Or, when the identifier 14 is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value. For example, the third value is 1 and the fourth value is 0. Or, the third value is 0 and the fourth value is 1.

[0342] For example, the identifier 14 may be represented by affine_type_flag. The affine_type_flag is used to indicate whether the six-parameter affine motion model type motion compensation can be used for inter prediction of the image block. For example, when affine_type_flag=0, it indicates that the six-parameter affine motion model type motion compensation cannot be used for inter prediction of the image block.

[0343] For example, see Table 3 for the syntax structure for parsing identifier 1 and identifier 13. u(1) represents reading 1 more consecutive bit and is interpreted as an unsigned integer. [Table 3]

[0344] For example, see Table 4 for a portion of the syntax structure for parsing the inter prediction mode used for the current image block. [Table 4]

[0345] In a first possible implementation, in a possible example, when the bitstream is parsed to obtain the identifier 1 and the identifier 13, when the identifier 12 indicates that the affine motion model type merge mode is used for the inter prediction of the current block and the identifier 13 is a second value, a first candidate motion vector list is constructed. The first candidate motion vector list includes a first element, which includes motion information of three control points for constructing a six-parameter affine motion model. For example, the first element includes one or more 3-tuples.

[0346] Optionally, the first candidate motion vector list may further include a second element, which includes only motion information of two control points for constructing a four-parameter affine motion model. For example, the second element includes one or more 2-tuples. The first candidate motion vector list may further include a third element, which includes motion information of a non-affine motion model.

[0347] In another possible example, when the identifier 12 indicates that an affine motion model type merge mode is used for inter prediction of the current block and the identifier 13 is a first value, a second candidate motion vector list is constructed. The second candidate motion vector list includes a second element, and the second element includes only motion information of two control points for constructing a four-parameter affine motion model. The second candidate motion vector list does not include the first element. The second candidate motion vector list may further include a third element, and the third element includes motion information of a non-affine motion model. Both the first candidate motion vector list and the second candidate motion vector list are candidate motion vector lists for the affine motion model type merge mode.

[0348] In a first possible implementation, in a possible example, when the bitstream is parsed to obtain the identifier 1 and the identifier 13, when the identifier 12 indicates that the affine motion model type AMVP mode is used for the inter prediction of the current block and the identifier 13 is a second value, the bitstream is parsed to obtain the identifier 14. When the identifier 14 is a third value, the affine motion model is a six-parameter affine motion model, or when the identifier 14 is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value. For example, the third value is 1 and the fourth value is 0. Or, the third value is 0 and the fourth value is 1.

[0349] Optionally, the identifier 14 may be represented by a syntax element affine_type_flag, for which see the relevant description in Table 1. Details will not be described again here.

[0350] In the following, the syntax structures in Tables 3 and 4 are used as examples to describe in detail the inter prediction procedure performed in the first possible manner as shown in FIG.

[0351] Step 801a: Parse the bitstream based on the syntax structure shown in Table 3 and Table 4, and determine the inter-prediction mode of the current block.

[0352] If it is determined that the inter prediction mode of the current block is an affine motion model type AMVP mode, step 802a is executed.

[0353] That is, if sps_affine_enabled_flag=1, merge_flag=0, and affine_inter_flag=1 in the syntax element, it indicates that the inter prediction mode of the current block is the affine motion model type AMVP mode.

[0354] For example, if the syntax elements are sps_affine_enabled_flag=1, merge_flag=0, affine_inter_flag=1, and sps_affine_type_flag=1, the bitstream needs to be parsed to obtain affine_type_flag. If the parsed affine_type_flag is equal to 1, it indicates that the inter prediction mode of the current block is a 6-parameter affine motion model type AMVP mode. Alternatively, if the affine_type_flag obtained through parsing is equal to 0, it indicates that the inter prediction mode of the current block is a 4-parameter affine motion model type AMVP mode.

[0355] For example, if sps_affine_enabled_flag=1, merge_flag=0, affine_inter_flag=1, and sps_affine_type_flag=0 in a syntax element, it indicates that the inter prediction mode of the current block is a four-parameter affine motion model type AMVP mode. In this case, there is no need to parse affine_type_flag.

[0356] For example, when sps_affine_enabled_flag=0 and merge_flag=0 in the syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type AMVP mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0357] If it is determined that the inter prediction mode of the current block is the affine motion model type merge mode, step 802b is executed.

[0358] That is, in the syntax elements, sps_affine_enabled_flag=1, merge_flag=1, and affine_merge_flag=1 indicate that the inter prediction mode of the current block is the affine motion model type merge mode.

[0359] For example, when sps_affine_enabled_flag=1 and merge_flag=0 in a syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type merge mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0360] For steps 802a to 804a, please refer to steps 602a to 604a, and the details will not be described again here.

[0361] Step 802b: Construct a motion information candidate list for the affine motion model type merge mode.

[0362] Specifically, a motion information candidate list for an affine motion model type merge mode may be constructed by using a method for predicting inherited control point motion vectors and / or constructed control point motion vectors.

[0363] For constructing a motion information candidate list for the affine motion model type merge mode by using a method for predicting the inherited control point motion vector, please refer to the relevant description of D1 in step 602b, and the details will not be described again here.

[0364] When the candidate control point motion information of the current block is derived by using the method for predicting the constructed control point motion vector and added to the motion information candidate list, the method specifically includes the following steps.

[0365] (1) Obtain the motion information of the control point of the current block. For details, please refer to step 601c. The details will not be described again here.

[0366] (2) The motion information of the control points is combined to obtain constructed control point motion information.

[0367] If sps_affine_type_flag=0, the motion information of two control points is combined to construct a four-parameter affine motion model. Two control points are combined as follows: {CP1,CP4}, {CP2,CP3}, {CP1,CP2}, {CP2,CP4}, {CP1,CP3}, or {CP3,CP4}. For example, a four-parameter affine motion model constructed by using a two-tuple based on the motion information (e.g., 2MV) of control points CP1 and CP2 is represented as Affine(CP1,CP2).

[0368] When sps_affine_type_flag=1, the motion information of three control points is combined to construct a six-parameter affine motion model. The three control points are combined as follows: {CP1,CP2,CP4}, {CP1,CP2,CP3}, {CP2,CP3,CP4}, or {CP1,CP3,CP4}. For example, a six-parameter affine motion model constructed by using a three-tuple based on the motion information of control points CP1, CP2, and CP3 (e.g., 3MV) is represented as Affine(CP1,CP2,CP3). For example, when sps_affine_type_flag=1, in addition to combining the motion information of three control points to construct a six-parameter affine motion model, the motion information of two control points may be further combined to construct a four-parameter affine motion model.

[0369] It should be noted that a combination of different control points can also be converted into a control point at the same position. For specific conversion methods, please refer to the relevant description in step 502. Details will not be described again here.

[0370] (3) Add the constructed control point motion information to a candidate motion vector list.

[0371] At this point, if the length of the candidate list is less than the maximum list length MaxNumMrgCand, these combinations are traversed in a preset order to obtain valid combinations as candidate control point motion information. If the candidate motion vector list is empty at this point, the candidate control point motion information is added to the candidate motion vector list. Otherwise, the motion information in the candidate motion vector list is traversed sequentially to check whether motion information identical to the candidate control point motion information exists in the candidate motion vector list. If motion information identical to the candidate control point motion information does not exist in the candidate motion vector list, the candidate control point motion information is added to the candidate motion vector list.

[0372] For example, when sps_affine_type_flag is 1, the preset order is Affine(CP1,CP2,CP3)->Affine(CP1,CP2,CP4)->Affine(CP1,CP3,CP4)->Affine(CP2,CP3,CP4)->Affine(CP1,CP2)->Affine(CP1,CP3)->Affine(CP2,CP3)->Affine(CP1,CP4)->Affine(CP2,CP4)->Affine(CP3,CP4). There are 10 combinations in total. The order of adding the 10 combinations to the candidate motion vector list is not specifically limited in this embodiment of the present application.

[0373] When sps_affine_type_flag is 0, the preset order is Affine(CP1,CP2)->Affine(CP1,CP3)->Affine(CP2,CP3)->Affine(CP1,CP4)->Affine(CP2,CP4)->Affine(CP3,CP4). There are 6 combinations in total. The order of adding the 6 combinations to the candidate motion vector list is not specifically limited in this embodiment of the present application.

[0374] For steps 803b to 805b, please refer to steps 603b to 605b, and the details will not be described again here.

[0375] With reference to FIG. 9, a second possible implementation is described.

[0376] Step 901: Parse the bitstream to obtain identifier 2.

[0377] Identifier 2 is used to indicate whether the candidate motion models for inter prediction of the image blocks in the slice including the current block include an affine motion model. In other words, identifier 2 is used to indicate whether an affine motion model can be used when motion compensation is performed on the image blocks included in the slice including the current block.

[0378] For example, the identifier 2 may be configured in a slice header of a slice of the bitstream. Based on this, parsing the bitstream to obtain the identifier 2 may be implemented in the following manner: parsing a slice header of a slice of the bitstream to obtain the identifier 2.

[0379] Step 902: When identifier 2 indicates that candidate motion models for inter prediction of an image block in a slice including the current block include an affine motion model and the current block satisfies preset conditions for inter prediction using an affine motion model, analyze the bitstream to obtain identifier 12.

[0380] For relevant descriptions of the preset conditions and the identifiers 12, please refer to the corresponding embodiments of Figures 7 and 8. Details will not be described again here.

[0381] For example, when identifier 2 indicates that the candidate motion models for inter prediction of the image blocks of the slice including the current block do not include an affine motion model, parameter information related to the affine motion model does not need to be parsed when inter prediction is performed on the image blocks of the slice. For example, there is no need to parse the bitstream to obtain identifier 12.

[0382] For example, when identifier 2 is a value A1, it indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model. Or, when identifier 2 is a value B1, it indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model. For example, when identifier 2 is equal to 1, it indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model. Or, when identifier 2 is equal to 0, it indicates that the candidate motion models for inter prediction of image blocks in a slice including the current block do not include an affine motion model.

[0383] Step 903: Determine a prediction mode for inter prediction of the current block based on the identifier 12. The prediction mode includes an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type prediction mode.

[0384] For example, identifier 2 may be represented by the syntax element slice_affine_enabled_flag. slice_affine_enabled_flag specifies whether affine model type motion compensation is enabled for inter prediction. For example, slice_affine_enabled_flag is equal to 0, the syntax element is restricted such that affine model type motion compensation is not used for the slice, and affine_merge_flag, affine_inter_flag, and affine_type_flag are not indicated in the image block level syntax of CVS. slice_affine_enabled_flag is equal to 1, and affine model type motion compensation may be used for the slice. (slice_affine_enabled_flag specifies whether affine model motion compensation can be used for inter prediction. If slice_affine_enabled_flag is equal to 0, the syntax element is restricted so that affine model motion compensation is not used for the slice, and affine_merge_flag, affine_inter_flag and affine_type_flag are not indicated in the cu level syntax of the CVS. Otherwise (slice_affine_enabled_flag is equal to 1), affine model motion compensation may be used in the slice).

[0385] In a second possible implementation, in a possible example, an identifier 23 may be further configured in the bitstream. The identifier 23 may be configured in a slice header of a slice of the bitstream. When the identifier 2 obtained by parsing the bitstream indicates that the candidate motion models for the inter prediction of the slice including the current block include an affine motion model, the bitstream is further parsed to obtain the identifier 23. When the identifier 23 is a first value, the affine motion models include only a four-parameter affine model. When the identifier 23 is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value. For example, the first value is 1 and the second value is 0. Or, the first value is 0 and the second value is 1.

[0386] For example, identifier 23 may be represented by slice_affine_type_flag, which specifies whether 6-parameter affine model type motion compensation is enabled for inter prediction. For example, slice_affine_type_flag is equal to 0, and the syntax element is restricted such that 6-parameter affine model type motion compensation is not used for the slice, and affine_type_flag is not indicated in the image block level syntax in the CVS. (slice_affine_type_flag specifies whether six-parameter affine model motion compensation can be used for inter prediction. If slice_affine_type_flag is equal to 0, the syntax element is restricted to not use six-parameter affine model motion compensation in the slice, and affine_type_flag is not indicated in the cu-level syntax in the CVS. Otherwise (slice_affine_type_flag is equal to 1), six-parameter affine model motion compensation may be used in the slice. When not present, the value of slice_affine_type_flag is inferred to be equal to 0.

[0387] For example, see Table 5 for the syntax structure for parsing Identifier 2 and Identifier 23. [Table 5]

[0388] For example, see Table 6 for a portion of the syntax structure for parsing the inter prediction mode used for the current image block. [Table 6]

[0389] In a second possible implementation, in a possible example, when the identifier 2 and the identifier 23 are obtained by analyzing the bitstream, when the identifier 12 indicates that the affine motion model type merge mode is used for the inter prediction of the block to be processed and the identifier 23 is a second value, a first candidate motion vector list is constructed. The first candidate motion vector list includes a first element, and the first element includes motion information of three control points for constructing a six-parameter affine motion model. For example, the first element includes one or more 3-tuples.

[0390] Optionally, the first candidate motion vector list may further include a second element, which includes only motion information of two control points for constructing a four-parameter affine motion model. For example, the second element includes one or more 2-tuples. The first candidate motion vector list may further include a third element, which includes motion information of a non-affine motion model.

[0391] In another possible example, when the identifier 12 indicates that an affine motion model type merge mode is used for inter prediction of the current block and the identifier 23 is a first value, a second candidate motion vector list is constructed. The second candidate motion vector list includes a second element, and the second element includes only motion information of two control points for constructing a four-parameter affine motion model. The second candidate motion vector list does not include the first element. The second candidate motion vector list may further include a third element, and the third element includes motion information of a non-affine motion model. Both the first candidate motion vector list and the second candidate motion vector list are candidate motion vector lists for the affine motion model type merge mode.

[0392] In a second possible implementation, in a possible example, when the identifier 2 and the identifier 23 are obtained by analyzing the bitstream, when the identifier 12 indicates that the affine motion model type AMVP mode is used for inter prediction of the block to be processed and the identifier 23 is a second value, the bitstream is analyzed to obtain the identifier 14. When the identifier 14 is a third value, the affine motion model is a six-parameter affine motion model. Or, when the identifier 14 is a fourth value, the affine motion model is a four-parameter affine motion model. The third value is different from the fourth value. For example, the third value is 1 and the fourth value is 0. Or, the third value is 0 and the fourth value is 1.

[0393] Optionally, the identifier 14 may be represented by a syntax element affine_type_flag, for which see the relevant description in Table 1. Details will not be described again here.

[0394] In the following, the syntax structures in Tables 5 and 6 are used as examples to describe in detail the inter prediction procedure performed in the second possible manner as shown in FIG.

[0395] Step 1001: Parse the bitstream based on the syntax structure shown in Table 5 and Table 6, and determine the inter prediction mode of the current block.

[0396] If it is determined that the inter prediction mode of the current block is an affine motion model type AMVP mode, step 1002a is executed.

[0397] That is, when slice_affine_enabled_flag=1, merge_flag=0, and affine_inter_flag=1 in the syntax element, it indicates that the inter prediction mode of the current block is the affine motion model type AMVP mode.

[0398] For example, when slice_affine_enabled_flag=0 and merge_flag=0 in the syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type AMVP mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0399] If it is determined that the inter prediction mode of the current block is the affine motion model type merge mode, step 702b is executed.

[0400] That is, in the syntax elements, slice_affine_enabled_flag=1, merge_flag=1, and affine_merge_flag=1 indicate that the inter prediction mode of the current block is the affine motion model type merge mode.

[0401] For example, when slice_affine_enabled_flag=1 and merge_flag=0 in a syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type merge mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0402] For steps 1002a to 1004a, please refer to steps 602a to 604a, and the details will not be described again here.

[0403] Step 1002b: Construct a motion information candidate list for the affine motion model type merge mode.

[0404] Specifically, a motion information candidate list for an affine motion model type merge mode may be constructed by using a method for predicting inherited control point motion vectors and / or constructed control point motion vectors.

[0405] For constructing a motion information candidate list for the affine motion model type merge mode by using a method for predicting the inherited control point motion vector, please refer to the relevant description of D1 in step 602b, and the details will not be described again here.

[0406] When the candidate control point motion information of the current block is derived by using the method for predicting the constructed control point motion vector and added to the motion information candidate list, the method specifically includes the following steps.

[0407] (1) Obtain the motion information of the control point of the current block. For details, please refer to step 601c. The details will not be described again here.

[0408] (2) The motion information of the control points is combined to obtain constructed control point motion information.

[0409] If slice_affine_type_flag=0, the motion information of two control points is combined to construct a four-parameter affine motion model. Two control points are combined as follows: {CP1,CP4}, {CP2,CP3}, {CP1,CP2}, {CP2,CP4}, {CP1,CP3}, or {CP3,CP4}. For example, a four-parameter affine motion model constructed by using control points CP1 and CP2 is represented as Affine(CP1,CP2).

[0410] When slice_affine_type_flag=1, the motion information of three control points is combined to construct a six-parameter affine motion model. The three control points are combined as follows: {CP1, CP2, CP4}, {CP1, CP2, CP3}, {CP2, CP3, CP4}, or {CP1, CP3, CP4}. For example, a six-parameter affine motion model constructed by using control points CP1, CP2, and CP3 is represented as Affine(CP1, CP2, CP3). For example, when slice_affine_type_flag=1, in addition to combining the motion information of three control points to construct a six-parameter affine motion model, the motion information of two control points may be further combined to construct a four-parameter affine motion model.

[0411] It should be noted that a combination of different control points can also be transformed into a control point at the same position. For specific transformation methods, please refer to the related description in step 502. Details will not be described again here.

[0412] (3) Add the constructed control point motion information to a candidate motion vector list.

[0413] If the length of the candidate list is less than the maximum list length MaxNumMrgCand at this point, these combinations are traversed in a preset order to obtain valid combinations as candidate control point motion information. If the candidate motion vector list is empty at this point, the candidate control point motion information is added to the candidate motion vector list. Otherwise, the motion information in the candidate motion vector list is traversed sequentially to check whether motion information identical to the candidate control point motion information exists in the candidate motion vector list. If motion information identical to the candidate control point motion information does not exist in the candidate motion vector list, the candidate control point motion information is added to the candidate motion vector list.

[0414] For example, when slice_affine_type_flag is 1, the preset order is Affine(CP1,CP2,CP3)->Affine(CP1,CP2,CP4)->Affine(CP1,CP3,CP4)->Affine(CP2,CP3,CP4)->Affine(CP1,CP2)->Affine(CP1,CP3)->Affine(CP2,CP3)->Affine(CP1,CP4)->Affine(CP2,CP4)->Affine(CP3,CP4). There are 10 combinations in total. The order of adding the 10 combinations to the candidate motion vector list is not specifically limited in this embodiment of the present application.

[0415] When slice_affine_type_flag is 0, the preset order is Affine(CP1,CP2)->Affine(CP1,CP3)->Affine(CP2,CP3)->Affine(CP1,CP4)->Affine(CP2,CP4)->Affine(CP3,CP4). There are 6 combinations in total. The order of adding the 6 combinations to the candidate motion vector list is not specifically limited in this embodiment of the present application.

[0416] For step 1003b, please refer to step 603b, and the details will not be described again here.

[0417] For step 1004b, please refer to step 604b, and the details will not be described again here.

[0418] With reference to FIG. 11, a third possible implementation is described.

[0419] Step 1101: Parse the bitstream and obtain the identifier 1.

[0420] Step 1102: When the identifier 1 indicates that the candidate motion models for inter prediction of the image block in the video image including the current block include an affine motion model, parse the bitstream and obtain an identifier 2.

[0421] For example, identifier 1 may be represented by a syntax element sps_affine_enabled_flag. sps_affine_enabled_flag specifies whether affine model type motion compensation is enabled for inter prediction. For example, when sps_affine_enabled_flag is equal to 0, it indicates that affine model type motion compensation is not used in CVS, and slice_affine_enabled_flag is not indicated in the slice level syntax of CVS. (sps_affine_enabled_flag is equal to 1 specifies that slice_affine_enabled_flag is present in the slice header. sps_affine_enabled_flag is equal to 0 specifies that slice_affine_enabled_flag is not present in the slice header and that affine model type motion compensation is not used in CVS).

[0422] In a possible example, if identifier 1 indicates that candidate motion models for inter prediction of image blocks in a video image including the current block include an affine motion model, then the bitstream is indicated to include identifier 2. If identifier 1 indicates that candidate motion models for inter prediction of image blocks in a video image including the current block do not include an affine motion model, then the bitstream is indicated to include identifier 2.

[0423] Step 1103: When identifier 2 indicates that candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model and the current block satisfies preset conditions for inter prediction using an affine motion model, analyze the bitstream to obtain identifier 12.

[0424] For relevant descriptions of the preset conditions, identifier 1, identifier 2, and identifier 12, please refer to the embodiments corresponding to Figures 9 and 10. Details will not be described again here.

[0425] Step 1104: Determine a prediction mode for inter prediction of the current block based on the identifier 12. The prediction mode includes an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type mode.

[0426] In a third possible implementation, in a possible example, the identifier 23 may further be configured in the bitstream. The identifier 23 may be configured in a slice header of a slice of the bitstream. When the identifier 2 obtained by parsing the bitstream indicates that the candidate motion models for inter prediction of the image block in the slice including the current block include an affine motion model, the bitstream is parsed to obtain the identifier 23. When the identifier 23 is a first value, the affine motion models include only a four-parameter affine model. When the identifier 23 is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model. The first value is different from the second value. For example, the first value is 1 and the second value is 0. Or, the first value is 0 and the second value is 1.

[0427] For example, see Table 7 for the syntax structure for parsing Identifier 1. [Table 7]

[0428] For example, see Table 8 for the syntax structure for parsing Identifier 2 and Identifier 23. The details will not be described again here. [Table 8]

[0429] For example, see Table 6 for a portion of the syntax structure for parsing the inter prediction mode used for the current image block.

[0430] In the inter prediction procedure in the third possible manner, only the procedure of analyzing the bitstream to determine the inter prediction mode of the current block is different from that in the second possible manner, and the other procedures are the same. Details are not described again here.

[0431] When the bitstream is parsed to determine the inter prediction mode of the current block, if the syntax elements sps_affine_enabled_flag=1, slice_affine_enabled_flag=1, merge_flag=0, and affine_inter_flag=1 indicate that the inter prediction mode of the current block is affine motion model type AMVP mode.

[0432] For example, when sps_affine_enabled_flag=0 and merge_flag=0 in the syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type AMVP mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0433] For example, when sps_affine_enabled_flag=1, slice_affine_enabled_flag=0, and merge_flag=0 in the syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type AMVP mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0434] In the syntax elements, if sps_affine_enabled_flag=1, slice_affine_enabled_flag=1, merge_flag=1, and affine_merge_flag=1, it indicates that the inter prediction mode of the current block is the affine motion model type merge mode.

[0435] For example, when sps_affine_enabled_flag=1 and merge_flag=0 in a syntax element, it indicates that the inter prediction mode of the current block is a translational motion model type merge mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0436] For example, when sps_affine_enabled_flag=1, slice_affine_enabled_flag=0, and merge_flag=1, it indicates that the inter prediction mode of the current block is a translational motion model type merge mode. In this case, affine_merge_flag, affine_inter_flag, and affine_type_flag do not need to be included in the bitstream and do not need to be obtained by parsing the bitstream.

[0437] In a third possible implementation, identifier 13 may further be configured in the bitstream based on identifier 1. In a third possible implementation, when identifier 13 indicates that an affine motion model type merge mode is used for inter prediction of the current block, identifier 13 may further indicate whether the bitstream includes identifier 23.

[0438] After parsing the bitstream to obtain identifier 1 in step 1101, and before parsing the bitstream to obtain identifier 2 in step 1102, the method further includes parsing the bitstream to obtain identifier 13.

[0439] Identifier 13 may be represented by a syntax element sps_affine_type_flag. sps_affine_type_flag is used to indicate whether six-parameter affine motion model type motion compensation is enabled for inter prediction and whether the bitstream includes slice_affine_type_flag. For example, sps_affine_type_flag=0 indicates that six-parameter affine motion model type motion compensation is not enabled for inter prediction. In this case, the CVS does not include a syntax element used to indicate six-parameter affine motion model type motion compensation. For example, slice_affine_type_flag or affine_type_flag is not indicated in the image block level syntax of the CVS. (slice_affine_type_flag specifies whether six-parameter affine model motion compensation can be used for inter prediction. If slice_affine_type_flag is equal to 0, the syntax element is restricted to not use six-parameter affine model motion compensation for decoding the current picture, and affine_type_flag is not indicated in the cu level syntax for the current picture. Otherwise (slice_affine_type_flag is equal to 1), six-parameter affine model motion compensation may be used for decoding the current picture. When not present, the value of slice_affine_type_flag is inferred to be equal to 0.

[0440] For example, see Table 9 for the syntax structure for parsing Identifier 1 and Identifier 13. [Table 9]

[0441] For example, see Table 10 for the syntax structure for parsing Identifier 2 and Identifier 23. [Table 10]

[0442] Based on the same inventive concept as the method embodiment, the present application further provides an apparatus. Referring to Fig. 12, the apparatus 1200 can be specifically a processor, a chip, or a chip system in a video decoder, or a module in a video decoder, such as the motion compensation module 322.

[0443] For example, the apparatus may include a parsing unit 1201 and a constructing unit 1202. The parsing unit 1201 and the constructing unit 1202 perform steps in the method shown in the embodiment corresponding to Figures 7 to 11. For example, the parsing unit 1201 may be configured to analyze identifiers (e.g., identifier 1, identifier 12, identifier 13, identifier 14, identifier 2, and identifier 23) included in the bitstream, and the constructing unit 1202 is configured to construct a candidate motion vector list (a first candidate motion vector list, a second candidate motion vector list, or the like).

[0444] The embodiment of the present application further provides another structure of the decoding device. As shown in Fig. 13, the device 1300 may include a communication interface 1310 and a processor 1320. Optionally, the device 1300 may further include a memory 1330. The memory 1330 may be located inside or outside the device. Both the analysis unit 1201 and the construction unit 1202 shown in Fig. 12 may be implemented by the processor 1320. The processor 1320 is configured to send or receive a video stream or a bitstream through the communication interface 1310 and implement the method in Fig. 7 to Fig. 11. In the implementation process, the steps in the processing procedure may be implemented by using an integrated logic circuit of hardware in the processor 1320 or an instruction in the form of software to complete the method in Fig. 7 to Fig. 11.

[0445] The communication interface 1310 in this embodiment of the present application may be a circuit, a bus, a transceiver, or any other device that may be configured to exchange information. For example, the other device may be a device connected to the apparatus 1300. For example, when the apparatus is a video encoder, the other device may be a video decoder.

[0446] In the present embodiment of the present application, the processor 1320 may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor, or any conventional processor or the like. The steps in the methods disclosed with reference to the embodiments of the present application may be directly executed by a hardware processor, or may be executed by using a combination of hardware and software units in a processor. The program code executed by the processor 1320 to implement the aforementioned methods may be stored in the memory 1330. The memory 1330 is coupled to the processor 1320.

[0447] A coupling in this embodiment of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in an electrical, mechanical or other form, and is used for the exchange of information between the devices, units or modules.

[0448] The processor 1320 may operate in conjunction with memory 1330. The memory 1330 may be a non-volatile memory, such as a hard disk drive (HDD) or solid-state drive (SSD), or a volatile memory, such as a random-access memory (RAM). The memory 1330 may be any medium that can be configured to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, including, but not limited to, any other medium.

[0449] In this embodiment of the present application, the specific connection medium between the communication interface 1310, the processor 1320, and the memory 1330 is not limited. In this embodiment of the present application, the memory 1330, the processor 1320, and the communication interface 1310 are connected through a bus in FIG. 13, and the bus is represented by a thick line in FIG. 13. The connection modes between other components are merely described generally and are not limited thereto. The bus can be classified into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used to represent a bus in FIG. 13, but this does not mean that there is only one bus or only one type of bus.

[0450] The above possible implementations and the specific embodiments related to Figures 7 to 11 describe one or more video data decoding devices in this application. According to the above description, it should be understood that the encoder side usually determines an inter prediction mode and encodes the inter prediction mode into a bitstream. After the last selected inter prediction mode is selected, the indicator of the inter prediction mode (for example, identifier 1, identifier 2, identifier 12, identifier 13, identifier 14, and identifier 23 in the above description) is encoded into a bitstream according to an encoding process that is completely reverse to the above decoding method (corresponding to identifier 1, identifier 2, identifier 12, identifier 13, identifier 14, and identifier 23 analyzed in the decoding process, respectively). It should be understood that the construction of the candidate motion vector list on the encoder side is completely consistent with the decoder side. The specific embodiment of the encoder side will not be described again. However, it should be understood that the video image prediction method described in this application is also applicable to an encoding device.

[0451] The embodiment of the present application further provides an encoding device. As shown in Fig. 14, the device 1400 may include a communication interface 1410 and a processor 1420. Optionally, the device 1400 may further include a memory 1430. The memory 1430 may be located inside or outside the device. The processor 1420 transmits or receives a video stream or a bitstream through the communication interface 1410.

[0452] In one aspect, the processor 1420 is configured to code the identifier 1 into a bitstream, and code the identifier 12 into the bitstream when the identifier 1 indicates that the candidate motion models for inter prediction of the image block in the video image including the current block include an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model. The identifier 12 is used to determine a prediction mode for inter prediction of the current block. The prediction mode includes an affine motion model based merge mode, an affine motion model based advanced motion vector prediction AMVP mode, and a non-affine motion model based prediction mode.

[0453] In another aspect, the processor 1420 is configured to code the identifier 3 into a bitstream, and to code the identifier 32 into a bitstream when the identifier 3 indicates that the candidate motion models for inter prediction of the image block in the slice including the current block include an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model. The identifier 32 is used to determine a prediction mode for inter prediction of the current block. The prediction mode includes an affine motion model based merge mode, an affine motion model based advanced motion vector prediction AMVP mode, and a non-affine motion model based prediction mode.

[0454] The communication interface 1410 in this embodiment of the present application may be a circuit, a bus, a transceiver, or any other device that may be configured to exchange information. For example, the other device may be a device connected to the apparatus 1400. For example, when the apparatus is a video encoder, the other device may be a video decoder.

[0455] In the present embodiment of the present application, the processor 1420 may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor, or any conventional processor or the like. The steps in the methods disclosed with reference to the embodiments of the present application may be directly executed by a hardware processor, or may be executed by using a combination of hardware and software units in a processor. The program code executed by the processor 1420 to implement the aforementioned methods may be stored in the memory 1430. The memory 1430 is coupled to the processor 1420.

[0456] A coupling in this embodiment of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in an electrical, mechanical or other form, and is used for the exchange of information between the devices, units or modules.

[0457] The processor 1420 may operate in conjunction with memory 1430. The memory 1430 may be a non-volatile memory, such as a hard disk drive (HDD) or solid-state drive (SSD), or a volatile memory, such as a random-access memory (RAM). The memory 1430 may be any medium that can be configured to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, including, but not limited to, any other medium.

[0458] In this embodiment of the present application, the specific connection medium between the communication interface 1410, the processor 1420, and the memory 1430 is not limited. In this embodiment of the present application, the memory 1430, the processor 1420, and the communication interface 1410 are connected through a bus in FIG. 14, and the bus is represented by a thick line in FIG. 14. The connection modes between other components are merely described generally and are not limited thereto. The bus can be classified into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used to represent a bus in FIG. 14, but this does not mean that there is only one bus or only one type of bus.

[0459] Based on the above embodiment, an embodiment of the present application further provides a computer storage medium. The storage medium stores a software program. When the software program is read and executed by one or more processors, the method provided in any one or more of the above embodiments can be implemented. The computer storage medium may include any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory, a random access memory, a magnetic disk, or an optical disk.

[0460] Based on the above embodiment, the embodiment of the present application further provides a chip. The chip includes a processor configured to implement the functions in any one or more of the above embodiments, such as obtaining or processing information or messages in the above method. Optionally, the chip further includes a memory, the memory configured to store program instructions and data required and executed by the processor. The chip may include a chip, or may include a chip and another discrete device.

[0461] Although certain aspects of the present application have been described with reference to video encoder 20 and video decoder 30, it may be understood that the techniques of the present invention may be applied by using many other video encoding and / or decoding units, processing units such as processors, hardware-based decoding units of encoder / decoders (CODECs) and the like, and the like. In addition, it should be understood that the steps shown and described in Figures 6A to 11 are provided merely as possible implementations. In other words, the steps shown in the possible implementations in Figures 6A to 11 are not necessarily performed in the order shown in Figures 6A to 11, and fewer, additional, or alternative steps may be performed.

[0462] Further, it should be understood that, depending on a possible implementation, certain actions or events in any of the methods described herein may be performed in a different order, actions or events may be added, or actions or events may be combined or omitted (e.g., not all of the described actions or events may be required to implement a method). Further, in a particular possible implementation, actions or events may be subject to (for example) multi-threaded or interrupt processing, or may be processed by multiple processors simultaneously rather than sequentially. Furthermore, while for ease of explanation, certain aspects of the present application are described as being performed by a single module or unit, it should be understood that the techniques of the present application may be performed by a combination of units or modules associated with a video decoder.

[0463] In one or more possible implementations, the described functions may be implemented by using hardware, software, firmware, or any combination thereof. If the functions are implemented by using software, the functions may be stored on a computer-readable medium as one or more instructions or codes or transmitted over the computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include a computer-readable storage medium or a communication medium. The computer-readable storage medium corresponds to a tangible medium such as a data storage medium. The communication medium includes any medium that facilitates the transmission of a computer program from one location to another location according to (for example) a communication protocol.

[0464] In this manner, a computer-readable medium may correspond, for example, to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, code, and / or data structures for implementing the techniques described herein. A computer program product may include a computer-readable medium.

[0465] As possible implementations, but not limited to, a computer-readable storage medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that can be used to store instructions or code necessary to form a data structure and that can be accessed by a computer. Similarly, any connection may be appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or another remote source through a coaxial cable, a fiber optic cable, a twisted pair, a digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, the fiber optic cable, the twisted pair, the DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

[0466] However, computer-readable storage media and data storage media should be understood to mean non-transitory tangible storage media without including connections, carriers, signals, or other transitory media. Magnetic disks and optical disks as used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks. Magnetic disks usually replicate data magnetically, while optical disks replicate data optically through lasers. Combinations of the aforementioned magnetic disks and optical disks are also included within the scope of computer-readable media.

[0467] The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor" as used herein may refer to any one of the aforementioned structures or another structure used to implement the techniques described herein. In addition, in some aspects, the functions described herein may be provided in dedicated hardware and / or software modules configured for encoding and decoding, or may be incorporated into a combined codec. In addition, the techniques may all be implemented in one or more circuits or logic elements.

[0468] The techniques herein may be implemented in a variety of apparatuses or devices, including wireless mobile phones, integrated circuits (ICs) or sets of ICs (e.g., chipsets). To highlight functional aspects of apparatuses configured to perform the disclosed techniques, various components, modules or units are described herein, but are not necessarily implemented by different hardware units. More specifically, as described above, the units may be combined in a codec hardware unit, or may be provided by a set of interoperable hardware units (including one or more processors as described above) in conjunction with suitable software and / or firmware.

[0469] The above description is merely an example of a specific implementation of the present application, and is not intended to limit the scope of protection of the present application. Any modifications or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application shall be included in the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims. Other possible claims (Item 1) A video image prediction method, comprising: parsing the bitstream to obtain a first identifier; parsing the bitstream to obtain a second identifier when the first identifier indicates that candidate motion models for inter prediction of an image block in a video image including a current block include an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model; determining a prediction mode for inter prediction of the current block based on the second identifier, the prediction mode including an affine motion model merge mode, an affine motion model advanced motion vector prediction (AMVP) mode, and a non-affine motion model prediction mode; A method for providing the above. (Item 2) The step of analyzing the bitstream to obtain the first identifier includes: 2. The method of claim 1, further comprising parsing a sequence parameter set of the bitstream to obtain the first identifier. (Item 3) When the first identifier indicates that the candidate motion models for inter prediction of an image block in the video image including the current block include the affine motion model, parsing the bitstream to obtain a third identifier, wherein when the third identifier is a first value, the affine motion models include only a four-parameter affine model, or when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model, and the first value is different from the second value; 3. The method of claim 1 or 2, further comprising: (Item 4) When the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, constructing a first candidate motion vector list, the first candidate motion vector list including a first element, the first element including motion information of three control points for constructing the six-parameter affine motion model, or constructing a second candidate motion vector list when the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the first value, the second candidate motion vector list including a second element, the second element including only motion information of two control points for constructing the four-parameter affine motion model; 4. The method of claim 3, further comprising: (Item 5) The method described in Item 4, wherein when the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the block to be processed and the third identifier is the second value, the first candidate motion vector list further includes the second element. (Item 6) When the second identifier indicates that the affine motion model type AMVP mode is used for inter prediction of the processing target block and the third identifier is the second value, the method further includes analyzing the bitstream to obtain a fourth identifier; When the fourth identifier is a third value, the affine motion model is the six-parameter affine motion model; or when the fourth identifier is a fourth value, the affine motion model is the four-parameter affine motion model, and the third value is different from the fourth value. 6. The method according to any one of items 3 to 5. (Item 7) The step of analyzing the bitstream to obtain a third identifier includes: Parsing the sequence parameter set of the bitstream to obtain the third identifier. 7. The method according to any one of items 3 to 6, comprising: (Item 8) A method according to any one of items 1 to 7, wherein the preset conditions include a width of the processing target block being greater than or equal to a first preset threshold and a height of the processing target block being greater than or equal to a second preset threshold. (Item 9) The method described in Item 8, wherein the first preset threshold is equal to the second preset threshold. (Item 10) A video image prediction method, comprising: parsing the bitstream to obtain a first identifier; analyzing the bitstream to obtain a second identifier when the first identifier indicates that candidate motion models for inter prediction of image blocks in a slice including the current block include an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model; determining a prediction mode for inter prediction of the current block based on the second identifier, the prediction mode including an affine motion model type merge mode, an affine motion model type advanced motion vector prediction (AMVP) mode, and a non-affine motion model type prediction mode; A method for providing the above. (Item 11) The step of analyzing the bit stream to obtain the first identifier includes: Item 11. The method of item 10, comprising parsing a slice header of the slice in the bitstream to obtain the first identifier. (Item 12) When the first identifier indicates that the candidate motion models for inter prediction of an image block in the slice including the current block include the affine motion model, parsing the bitstream to obtain a third identifier, wherein when the third identifier is a first value, the affine motion models include only a four-parameter affine model, or when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model, and the first value is different from the second value; 12. The method according to item 10 or 11, further comprising: (Item 13) When the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, constructing a first candidate motion vector list, the first candidate motion vector list including a first element, the first element including motion information of three control points for constructing the six-parameter affine motion model; or constructing a second candidate motion vector list when the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the first value, the second candidate motion vector list including a second element, the second element including only motion information of two control points for constructing the four-parameter affine motion model; Item 13. The method of item 12, further comprising: (Item 14) The method described in Item 13, wherein when the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the block to be processed and the third identifier is the second value, the first candidate motion vector list further includes the second element. (Item 15) When the second identifier indicates that the affine motion model type AMVP mode is used for inter prediction of the processing target block and the third identifier is the second value, the method further includes analyzing the bitstream to obtain a fourth identifier; when the fourth identifier is a third value, the affine motion model is the six-parameter affine motion model; or when the fourth identifier is a fourth value, the affine motion model is the four-parameter affine motion model, and the third value is different from the fourth value; 14. The method according to item 12 or 13. (Item 16) The step of analyzing the bit stream to obtain a third identifier includes: 16. A method according to any one of items 12 to 15, comprising parsing the slice header of the slice in the bitstream to obtain the third identifier. (Item 17) Prior to the step of analyzing the bitstream to obtain the first identifier, analyzing the bitstream to obtain a fifth identifier, where when the fifth identifier is a fifth value, candidate motion models for inter prediction of a video image including the current block include the affine motion model, or when the fifth identifier is a sixth value, candidate motion models for inter prediction of a video image including the current block include only the non-affine motion model, and the fifth value is different from the sixth value; 17. The method according to any one of items 10 to 16, further comprising: (Item 18) The step of acquiring the bit stream and analyzing the fifth identifier includes: Item 18. The method of item 17, comprising parsing a sequence parameter set of the bitstream to obtain the fifth identifier. (Item 19) After the step of analyzing the bitstream to obtain a fifth identifier and before the step of analyzing the bitstream to obtain a first identifier, parsing the bitstream to obtain a sixth identifier, the sixth identifier being used to determine that the bitstream includes the third identifier; 19. The method according to item 17 or 18, further comprising: (Item 20) The step of analyzing the bit stream to obtain a sixth identifier includes: 20. The method of claim 19, further comprising parsing the sequence parameter set of the bitstream to obtain the sixth identifier. (Item 21) A method according to any one of Items 10 to 20, wherein the preset conditions include a width of the processing block being greater than or equal to a first preset threshold and a height of the processing block being greater than or equal to a second preset threshold. (Item 22) The method described in Item 21, wherein the first preset threshold is equal to the second preset threshold. (Item 23) A video image prediction device, a parsing unit configured to parse a bitstream to obtain a first identifier, the parsing unit being configured to parse the bitstream to obtain a second identifier when the first identifier indicates that candidate motion models for inter prediction of an image block in a video image including a current block include an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model, The analysis unit is further configured to determine a prediction mode for inter prediction of the current block based on the second identifier, the prediction mode including an affine motion model based merge mode, an affine motion model based AMVP mode, and a non-affine motion model based prediction mode. Device. (Item 24) When parsing the bitstream to obtain the first identifier, the parsing unit specifically: Item 24. The apparatus of item 23, configured to analyze a sequence parameter set of the bitstream to obtain the first identifier. When the first identifier indicates that the candidate motion models for inter prediction of the image block in the video image including the current block include the affine motion model, the analysis unit further configured to parse the bitstream to obtain a third identifier, where when the third identifier is a first value, the affine motion models include only a four-parameter affine model, or when the third identifier is a second value, the affine motion models include a four-parameter affine model and a six-parameter affine model, and the first value is different from the second value; 25. The device according to item 23 or 24. (Item 26) When the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, constructing a first candidate motion vector list, the first candidate motion vector list including a first element, the first element including motion information of three control points for constructing the six-parameter affine motion model; or When the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the first value, constructing a second candidate motion vector list, the second candidate motion vector list including a second element, the second element including only motion information of two control points for constructing the four-parameter affine motion model. 26. The apparatus of item 25, further comprising a construction unit configured to: (Item 27) The device described in Item 26, wherein when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, the first candidate motion vector list further includes the second element. (Item 28) The analysis unit further: configured to parse the bitstream to obtain a fourth identifier when the second identifier indicates that the affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value; when the fourth identifier is a third value, the affine motion model is the six-parameter affine motion model; or when the fourth identifier is a fourth value, the affine motion model is the four-parameter affine motion model, and the third value is different from the fourth value; 28. Apparatus according to any one of items 25 to 27. (Item 29) When parsing the bitstream to obtain the third identifier, the parsing unit specifically: 29. The apparatus of any one of items 25 to 28, configured to analyze the sequence parameter set of the bitstream to obtain the third identifier. (Item 30) An apparatus described in any one of Items 25 to 29, wherein the preset conditions include the width of the processing target block being greater than or equal to a first preset threshold and the height of the processing target block being greater than or equal to a second preset threshold. (Item 31) The device described in Item 30, wherein the first preset threshold is equal to the second preset threshold. (Item 32) A video image prediction device, 2. An apparatus comprising: an analysis unit configured to analyze a bitstream to obtain a first identifier, wherein when the first identifier indicates that a candidate motion model for inter prediction of an image block in a slice including the current block includes an affine motion model and the current block satisfies a preset condition for inter prediction using the affine motion model, the analysis unit is further configured to analyze the bitstream to obtain a second identifier and determine a prediction mode for inter prediction of the current block based on the second identifier, wherein the prediction modes include an affine motion model type merge mode, an affine motion model type AMVP mode, and a non-affine motion model type prediction mode. (Item 33) When parsing the bitstream to obtain the first identifier, the parsing unit specifically: The apparatus of item 32, configured to parse a slice header of the slice in the bitstream to obtain the first identifier. (Item 34) The analysis unit further: When the first identifier indicates that the candidate motion models for inter prediction of the image block in the slice including the current block include the affine motion model, Item 34. The apparatus of item 32 or 33, configured to analyze the bitstream to obtain a third identifier, wherein when the third identifier is a first value, the affine motion model includes only a four-parameter affine model, or when the third identifier is a second value, the affine motion model includes a four-parameter affine model and a six-parameter affine model, and the first value is different from the second value. (Item 35) When the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, constructing a first candidate motion vector list, the first candidate motion vector list including a first element, the first element including motion information of three control points for constructing the six-parameter affine motion model; or When the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the first value, constructing a second candidate motion vector list, the second candidate motion vector list including a second element, the second element including only motion information of two control points for constructing the four-parameter affine motion model. Item 35. The apparatus of item 34, further comprising a construction unit configured to perform the steps of: (Item 36) The device described in Item 35, wherein when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the third identifier is the second value, the first candidate motion vector list further includes the second element. (Item 37) The analysis unit further: When the second identifier indicates that the affine motion model type AMVP mode is used for inter prediction of the current block and the third identifier is the second value, analyzing the bitstream to obtain a fourth identifier; when the fourth identifier is a third value, the affine motion model is the six-parameter affine motion model; or when the fourth identifier is a fourth value, the affine motion model is the four-parameter affine motion model, and the third value is different from the fourth value; 36. The device according to item 34 or 35. (Item 38) When parsing the bitstream to obtain the third identifier, the parsing unit specifically: 38. The apparatus of any one of items 34 to 37, configured to parse the slice header of the slice in the bitstream to obtain the third identifier. (Item 39) Before parsing the bitstream to obtain the first identifier, the parsing unit further 39. The device of any one of items 32 to 38, configured to analyze the bitstream to obtain a fifth identifier, and when the fifth identifier is a fifth value, candidate motion models for inter prediction of image blocks in a video image including the current block include the affine motion model, or when the fifth identifier is a sixth value, candidate motion models for inter prediction of image blocks in a video image including the current block include only the non-affine motion model, and the fifth value is different from the sixth value. (Item 40) When parsing the bitstream to obtain the fifth identifier, the parsing unit specifically: 40. The apparatus of claim 39, configured to parse a sequence parameter set of the bitstream to obtain the fifth identifier. (Item 41) The apparatus described in Item 39 or 40, wherein the parsing unit is further configured to parse the bitstream to obtain the sixth identifier after parsing the bitstream to obtain the fifth identifier and before parsing the bitstream to obtain the first identifier, and the sixth identifier is used to determine that the bitstream includes the third identifier. (Item 42) When parsing the bitstream to obtain the sixth identifier, the parsing unit specifically: Item 42. The apparatus of item 41, configured to parse the sequence parameter set of the bitstream to obtain the sixth identifier. (Item 43) An apparatus described in any one of Items 32 to 42, wherein the preset conditions include the width of the processing target block being greater than or equal to a first preset threshold and the height of the processing target block being greater than or equal to a second preset threshold. (Item 44) The device described in Item 43, wherein the first preset threshold is equal to the second preset threshold. (Item 45) A decoder, A memory and a processor, the memory configured to store program instructions; The processor is configured to call and execute the program instructions stored in the memory to implement the method according to any one of items 1 to 22. decoder. (Item 46) A chip, the chip being connected to a memory and configured to read and execute a software program stored in the memory and to implement a method according to any one of items 1 to 22.

Claims

1. 1. A method for predicting a video image, comprising: parsing the bitstream to obtain a first identifier; when the first identifier indicates that affine motion model-based motion compensation is enabled for a video sequence including the current block, parsing the bitstream to obtain a third identifier, the value of the third identifier being a true value or a false value, the true value indicating that the affine motion models include a four-parameter affine motion model and a six-parameter affine motion model, and the false value indicating that the affine motion models do not include the six-parameter affine motion model; analyzing the bitstream to obtain a second identifier when the first identifier indicates that the affine motion model based motion compensation is enabled for the video sequence and the current block satisfies a preset condition for inter prediction using the affine motion model; constructing a first candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and when the value of the third identifier is the true value, the first candidate motion vector list including a first element and a second element, the first element including motion information of three control points for constructing the six-parameter affine motion model, and the second element including motion information of only two control points for constructing the four-parameter affine motion model; constructing a second candidate motion vector list when the second identifier indicates that an affine motion model type merge mode is used for inter prediction of the current block and the value of the third identifier is a false value, the second candidate motion vector list including the second element, the second element including only motion information of two control points for constructing the four-parameter affine motion model; A method for providing the above.

2. The method of claim 1 , wherein parsing the bitstream to obtain the first identifier comprises parsing a sequence parameter set of the bitstream to obtain the first identifier.

3. 3. The method of claim 2, wherein the first identifier is represented by an sps_affine_enabled_flag indicating whether the affine motion model based motion compensation is enabled for the video sequence, and when the sps_affine_enabled_flag is equal to 1, it indicates that the affine motion model based motion compensation is enabled for the video sequence.

4. The method of claim 1 , wherein parsing the bitstream to obtain the third identifier comprises parsing a sequence parameter set of the bitstream to obtain the third identifier.

5. 5. The method of claim 4, wherein the third identifier is represented by an sps_affine_type_flag indicating whether six-parameter affine motion model type motion compensation is enabled for the video sequence, the sps_affine_type_flag having a value of 1 or 0, the sps_affine_type_flag having a value of 1 indicating that the six-parameter affine motion model type motion compensation is enabled for the video sequence, and the sps_affine_type_flag having a value of 0 indicating that the six-parameter affine motion model type motion compensation is disabled.

6. The method according to claim 1 , wherein the preset conditions include that the width of the processing block is 8 or more, and that the height of the processing block is 8 or more.

7. A decoder comprising: A memory and a processor, the memory is configured to store program instructions; The processor is configured to call and execute the program instructions stored in the memory to implement the method of any one of claims 1 to 6. decoder.

8. 1. A video data decoding device, comprising: a non-transitory memory storage configured to store video data in the form of a bitstream; A video decoder configured to perform the method according to any one of claims 1 to 6; 1. A video data decoding device comprising:

9. A program, which when said program is run on a computer, enables said computer to carry out the method according to any one of claims 1 to 6.

10. A computer-readable storage medium storing the program according to claim 9.

11. A non-transitory storage medium comprising a bitstream decoded by the method of any one of claims 1 to 6, the bitstream comprising a plurality of syntax elements for performing inter prediction of a current block, the plurality of syntax elements comprising a first identifier, a second identifier, and a third identifier.

12. A chip connected to a memory and configured to read and execute a software program stored in said memory to implement the method of any one of claims 1 to 6.

13. An electronic device comprising the chip of claim 12.

Citation Information

Patent Citations

  • Affine motion prediction for video coding

    WO2017200771A1