Video bitstream decoding method, video frame encoding method and electronic device

Abstract

Provided in the present application are a video bitstream decoding method, a frame encoding method, an electronic device and a medium. The video bitstream decoding method comprises: first receiving a video bitstream comprising a candidate index of an affine Merge mode or an affine UMVE mode; then constructing an affine MVP candidate list for a current decoding block in a current frame, wherein the affine MVP candidate list may comprise a plurality of affine MVP candidates, and candidate types corresponding to the affine MVP candidates may comprise an inherited affine candidate type, a constructed affine candidate type, and at least one of an HACD affine candidate type and an HFACD affine candidate type; and extracting, on the basis of the candidate index, an affine MVP candidate corresponding to the current decoding block from the affine MVP candidate list, and, on the basis of the extracted affine MVP candidate, decoding the current decoding block.

Description

Video stream decoding methods, video frame encoding methods, and electronic devices

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202510212883.0, filed on February 24, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to, but is not limited to, the field of image processing technology, and particularly to a video stream decoding method, a frame encoding method, an electronic device, and a medium. Background Technology

[0004] History-Based Affine Candidate Derivation (HACD) is an encoding tool introduced by AVS4 (Advanced Visual Studio 4) to further improve the compression performance of the affine Merge / UMVE mode. When encoding using the affine Merge / UMVE mode, corresponding decoding processing based on the affine Merge / UMVE mode at the decoding end yields the required video content. HACD stores the parameters of previous affine blocks in a history affine table (HAT) and combines this with the actual motion vectors (MVs) of adjacent blocks to construct virtual affine neighbor blocks, obtaining more affine candidates and aiding in accurate prediction. However, the current AVS4 affine Merge / UMVE mode has many problems in constructing the motion vector prediction (MVP) candidate list, leading to issues during both encoding and decoding. First, the construction order and quantity limitations have drawbacks. The construction order is: inheriting affine candidates (maximum 2), constructing affine candidates (maximum 6), and then HACD affine candidates, with a maximum limit of 11. However, in practice, the number of inherited and constructed affine candidates often falls short of this limit, and insufficient candidates restrict the improvement of coding performance. Second, the HACD affine candidate update strategy is flawed. It uses coding tree units (CTUs) as the update unit, and HAT is cleared at the beginning of a new CTU line. This makes it difficult to utilize affine coding blocks from previous CTU lines, and the current line may have fewer affine coding blocks, resulting in insufficient HACD affine candidates. Third, the fixed construction order affects coding performance, fails to consider the characteristics and requirements of video content, and is difficult to handle diverse scenarios.

[0005] Due to the aforementioned issues, further improvements to the encoding performance of the affine Merge / UMVE mode will be limited to some extent, resulting in reduced video encoding efficiency and consequently, video decoding performance falling short of expectations. Summary of the Invention

[0006] This application provides a video stream decoding method, a frame encoding method, an electronic device, and a medium.

[0007] On one hand, embodiments of this application provide a video stream decoding method, comprising: receiving the video stream, the video stream including candidate indices for affine Merge mode or affine UMVE mode; constructing an affine motion vector prediction (MVP) candidate list for the current decoded block in the current frame, the affine MVP candidate list including multiple affine MVP candidates, the candidate types corresponding to the multiple affine MVP candidates including inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate type derived from historical affine candidates and HFACD affine candidate type derived from historical frame affine candidates; retrieving the affine MVP candidate corresponding to the current decoded block from the affine MVP candidate list according to the candidate index, and decoding the current decoded block according to the retrieved affine MVP candidate.

[0008] On the other hand, embodiments of this application also provide a video frame encoding method, comprising: constructing an affine MVP candidate list for the current coding block in the video frame, the affine MVP candidate list including multiple affine MVP candidates, the candidate types corresponding to the multiple affine MVP candidates including inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types; performing rate-distortion-based cost calculation on each affine MVP candidate in the affine MVP candidate list to obtain the optimized cost of each affine MVP candidate in the affine MVP candidate list; encoding the current coding block based on affine Merge mode or affine UMVE mode according to the affine MVP candidate with the minimum optimized cost, and encoding the candidate index of the affine MVP candidate with the minimum optimized cost into the video bitstream and transmitting it to the decoding end.

[0009] On the other hand, embodiments of this application also provide an electronic device, including: at least one processor; at least one memory for storing at least one program; when at least one of the programs is executed by at least one of the processors, it implements the video stream decoding method described above, or implements the video frame encoding method described above.

[0010] On the other hand, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the video stream decoding method described above, or to execute the video frame encoding method described above.

[0011] On the other hand, embodiments of this application also provide a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium, a processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, causing the electronic device to perform the video stream decoding method as described above, or to perform the video frame encoding method as described above.

[0012] In this embodiment, firstly, a video bitstream including candidate indices of affine Merge mode or affine UMVE mode is received; then, an affine MVP candidate list for the current decoding block in the current frame is constructed, wherein the affine MVP candidate list may include multiple affine MVP candidates, and the candidate types corresponding to these affine MVP candidates may include inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types; next, the affine MVP candidate corresponding to the current decoding block is retrieved from the affine MVP candidate list according to the candidate index, and the current decoding block is decoded according to the retrieved affine MVP candidate. Since this embodiment uses the above process for decoding at the decoding end, the encoding end can encode the candidate index of the affine candidate with a high probability of selection with fewer bits when using the corresponding encoding method, thereby saving encoding bits and improving video compression performance. Attached Figure Description

[0013] Figure 1 is a schematic diagram of a video transmission scenario system architecture provided in an embodiment of this application;

[0014] Figure 2 is a flowchart of a video stream decoding method provided in an embodiment of this application;

[0015] Figure 3 is a schematic diagram of the affine inheritance candidate derivation provided in an embodiment of this application;

[0016] Figure 4 is a schematic diagram of the location of the affine candidate control points provided in an example of this application;

[0017] Figure 5 is a schematic diagram of the candidate update for historical motion vector prediction provided in an example of this application;

[0018] Figure 6 is a schematic diagram of history-based affine candidate derivation provided in an embodiment of this application;

[0019] Figure 7 is a schematic diagram of updating the historical frame affine table according to an embodiment of this application;

[0020] Figure 8 is a flowchart of reordering affine MVP candidates according to an embodiment of this application;

[0021] Figure 9 is a schematic diagram of a template matching process provided in an embodiment of this application;

[0022] Figure 10 is a flowchart of the encoding process of a video frame provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical methods, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described may be executed in a different order than that shown in the flowchart. In the description of the specification, claims, and the above-mentioned figures, "multiple" means two or more; "greater than," "less than," and "exceeding" are understood to exclude the stated number; "above," "below," and "within" are understood to include the stated number. The use of terms such as "first" and "second" is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly specifying the number of indicated technical features or their sequential relationship. Furthermore, in the description of the specification, claims, and the above-mentioned figures, the various values ​​mentioned (such as first value, second value, etc.) can be flexibly represented as single numeric codes or enumerated type values. These values ​​can clearly guide and control the execution flow and behavior patterns of various functional modules, ensuring the efficiency of decoding or encoding.

[0025] It is worth noting that in AVS4, the Affine Merge / UMVE mode plays a crucial role in improving video coding efficiency, and HACD (Affine Candidate Listing) is an important coding tool introduced by AVS4 to further enhance the compression performance of this mode. HACD technology stores the basic parameters of previous affine coded blocks in a History Affine Table (HAT) and constructs virtual affine neighbor blocks based on the parameters in the HAT and the actual MV (Multi-Modal Values) of adjacent blocks, thereby deriving more affine candidates and contributing to more accurate affine prediction. However, the current AVS4 Affine Merge / UMVE mode has several unresolved issues in the MVP candidate list construction process.

[0026] First, the construction order and quantity limitations of the MVP candidate list have drawbacks. It constructs candidates in the order of inherited affine candidates (maximum 2), constructed affine candidates (maximum 6), and HACD affine candidates, with a maximum limit of 11. However, in actual encoding, due to situations such as adjacent blocks being non-affine or unavailable, the number of inherited and constructed affine candidates often falls short of the limit, resulting in fewer than 11 candidates. This shortage of candidates significantly restricts further improvements in encoding performance, making it difficult to achieve more efficient encoding and more accurate prediction when processing complex video scenes.

[0027] Secondly, the HACD affine candidate update strategy has flaws. HACD affine candidates are updated in coding tree unit (CTU) rows, and the HAT (Hardware Address Table) is cleared at the beginning of a CTU row. Only if an affine pattern coding block exists within the current CTU row is it added to the HAT for encoding subsequent CTU coding blocks within that row. This strategy results in the ineffective utilization of affine coding blocks from previous CTU rows, while the current CTU row may have only a few or no affine coding blocks. This leads to an insufficient number of HACD affine candidates, failing to fully leverage the advantages of HACD technology and impacting overall coding efficiency and image quality.

[0028] Third, the fixed construction order of the MVP candidate list affects encoding performance. Constructing affine candidates in a fixed order of inheriting affine candidates, constructing affine candidates, and HACD affine candidates fails to fully consider the characteristics and encoding requirements of different video content. When facing diverse video scenarios, this fixed order may lead to suboptimal encoding performance.

[0029] Due to the aforementioned issues, further improvements to the encoding performance of the affine Merge / UMVE mode will be limited to some extent, resulting in reduced video encoding efficiency and suboptimal video decoding performance.

[0030] In view of this, embodiments of this application provide a video stream decoding method, a video frame encoding method, an electronic device, a computer-readable storage medium, and a computer program product. First, a video stream including candidate indices of affine Merge mode or affine UMVE mode is received. Then, an affine MVP candidate list for the current decoding block in the current frame is constructed. The affine MVP candidate list may include multiple affine MVP candidates, and the candidate types corresponding to these affine MVP candidates may include inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types. Next, the affine MVP candidate corresponding to the current decoding block is retrieved from the affine MVP candidate list according to the candidate index, and the current decoding block is decoded according to the retrieved affine MVP candidate. Because embodiments of this application use the above process for decoding at the decoding end, the encoding end, when using the corresponding encoding method, can encode the candidate index of the affine candidate with a high probability of selection with fewer bits, achieving the purpose of saving encoding bits and thus improving the compression performance of the video.

[0031] The technical solutions of this application embodiment can be applied to H.266 / VVC standards, Audio Video Coding Standards (AVS), such as AVS4, or next-generation video codec standards, and this application embodiment does not limit them.

[0032] Based on the above analysis, the embodiments of this application will be further described below with reference to the accompanying drawings.

[0033] Figure 1 is a schematic diagram of a video transmission scenario system architecture provided in an embodiment of this application. As shown in Figure 1, this scenario includes a terminal 110 and a server 120. The terminal 110 or server 120 can encode video using an encoder or decode video using a decoder. The terminal 110 or server 120 can also encode video using a video encoding program run by a processor or decode video using a video decoding program run by a processor. After receiving the encoded data sent by the terminal 110 through the input interface, the server 120 can directly transmit it to the processor for decoding or store it in a database for subsequent decoding. After obtaining the encoded data by encoding the original video frames through the processor, the server 120 can directly send it to the terminal 110 through the output interface or store the encoded data in a database for subsequent transmission.

[0034] The decoding method can be completed in terminal 110 or server 120. Terminal 110 can encode the input video stream and send the encoded data to server 120, or it can receive the encoded data from server 120, decode it, and generate a decoded video stream. Server 120 can encode video frames, in which case the decoding method is completed on server 120. If server 120 needs to decode the encoded data, the decoding method is completed on server 120. Of course, after receiving the encoded data sent by terminal 110, server 120 can send the encoded data to the corresponding receiving terminal for decoding. It is understood that the encoding end and the decoding end can be the same end or different ends. The aforementioned computer equipment, such as terminal or server, can be either the encoding end or the decoding end. Terminal 110 and server 120 are connected via a network. In this embodiment, terminal 110 can be a device related to image and video playback, such as: mobile phone, tablet computer, computer, laptop computer, wearable device, in-vehicle device, liquid crystal display, cathode ray tube display, holographic imaging display or projector, or other terminal devices, etc. This embodiment is not limited to these. Server 120 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0035] Referring to Figure 2, which is a flowchart of a video stream decoding method provided in an embodiment of this application, the decoding method may include, but is not limited to, steps S210 to S230.

[0036] Step S210: Receive video stream, wherein the video stream includes candidate indices for affine Merge mode or affine UMVE mode;

[0037] Step S220: Construct an affine MVP candidate list for the current decoded block in the current frame. The affine MVP candidate list may include multiple affine MVP candidates, and the candidate types corresponding to these affine MVP candidates may include inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types.

[0038] Step S230: Retrieve the affine MVP candidate corresponding to the current decoding block from the affine MVP candidate list according to the candidate index, and decode the current decoding block according to the retrieved affine MVP candidate.

[0039] For example, a video bitstream refers to the binary data stream generated during video encoding, after the original video signal has undergone a series of encoding processes (such as prediction, transform, quantization, entropy coding, etc.). This data stream contains all the information of the video, such as pixel values, motion information, and encoding mode, to facilitate transmission over a network or storage on a storage device. In video encoding, motion compensation can be used to reduce redundant information between video frames.

[0040] It's important to note that video streams can be either block-level or frame-level. A block-level stream is generated by dividing a video frame into multiple smaller blocks and encoding each block individually. In modern video coding standards, video frames are typically divided into fixed-size or variable-size coding blocks, such as coding tree units (CTUs) and their further subdivisions like coding units (CUs), prediction units (PUs), and transform units (TUs). Each coding block has independent coding parameters and information, such as motion vectors, quantization parameters, and coding modes. These combined information constitute the block-level stream. A frame-level stream, on the other hand, is obtained by uniformly encoding the entire video frame. In this approach, the encoding process considers the statistical characteristics and motion information of the entire frame, assigning uniform coding parameters to the entire frame. The frame-level stream contains the image data, motion information, and other relevant coding information for the entire frame.

[0041] For example, the Affine Merge mode is a motion-compensated coding mode that assumes the motion of image blocks in a video conforms to an affine transformation model. Affine transformations can describe complex motions such as translation, rotation, scaling, and shearing of image blocks. In Affine Merge mode, appropriate motion information can be selected from adjacent encoded blocks to predict the motion of the current encoded block without needing to additionally encode the motion vector of the current block, thus reducing the number of encoded bits. The Affine UMVE (Ultimate Motion Vector Expression) mode is also a motion-compensated coding mode based on affine transformations. Building upon the affine motion model, it employs a more flexible approach to explore and select motion vectors, further improving the accuracy of motion compensation and coding efficiency. Unlike Affine Merge mode, Affine UMVE mode may perform more detailed adjustments and encoding of motion vectors to adapt to different video content and motion characteristics.

[0042] For example, in affine Merge and affine UMVE modes, to find suitable motion vector prediction values, an affine motion vector prediction (MVP) candidate list is typically constructed. This list contains multiple possible motion vector prediction values. A candidate index is a number pointing to a specific candidate in this candidate list. When encoding a video block using affine Merge or affine UMVE mode, it selects a candidate from the candidate list that best matches the motion of the current block and includes that candidate's index value in the video stream. After receiving the video stream, the decoder can retrieve the corresponding motion vector prediction value from its own constructed candidate list based on this candidate index, reconstruct the true motion vector of the current block, and thus complete the decoding of the video block.

[0043] For example, in the Affine Merge pattern, the process of constructing the Affine MVP candidate list includes: constructing the Affine MVP candidate list in the order of inheriting Affine candidates, constructing Affine candidates, and HACD Affine candidates. It is worth noting that the maximum number of candidates in this candidate list can be limited to 11.

[0044] For example, the inherited affine candidate is derived from the adjacent affine coded blocks, as shown in Figure 3. During the derivation, adjacent blocks are checked according to specific rules. First, blocks F, G, C, A, and D are checked in sequence to see if they use the affine coding mode. When a block is detected as an affine coded block (e.g., block F in Figure 3), the gradients of the control point predicted motion vector (CPMV) of the affine coded block relative to the X-axis and Y-axis need to be calculated. It should be noted that in the field of video coding, the 6-parameter affine model and the 4-parameter affine model are important tools for describing the motion of video blocks. They can capture the complex motion of objects in the video more accurately and have better motion description capabilities than the traditional translation motion model. For the case of using the 6-parameter affine model, the gradient can be calculated according to Equation (1); for the case of using the 4-parameter affine model, the gradient is calculated according to Equation (2).

[0045] Furthermore, assuming the affine motion field varies linearly in both directions, the motion vector (MV) of any block can be derived as follows. Let's take the detected affine coded block F as an example. In equation (3), vx base and vy base Let vx4 and vy4 represent the horizontal motion vector component vx4 and vertical motion vector component vy4 of the 4x4 sub-block at the top left corner of the affine-coded neighboring block at position F, respectively. These two components are used as the basic motion information in equation (3). Meanwhile, (x base y base () represents the position coordinates of the 4x4 sub-block. Additionally, (△vx)x , △vx y ) and (△vy x , △vy y The motion information offset value is calculated using the motion vector information of the upper left, upper right, and lower left 4x4 sub-blocks of the affine-coded neighboring block at position F.

[0046] For example, constructing affine candidates involves combining the adjacent translational motion information of each control point. This motion information can be obtained from the specified spatial and temporal adjacent blocks shown in Figure 4. Here, CPMVk (k = 1, 2, 3, 4) represents the motion information of the k-th control point. For CPMV1, the checks are performed in the order of A->B->D blocks, using the MV of the first available block. That is, first check if block A is available; if it is, use the MV of block A; if block A is unavailable, then check block B, and so on. For CPMV2, the checks are performed in the order of G->C blocks, again using the MV of the first available block. For CPMV3, block F is checked; if it is available, its MV is used. For CPMV4, if the temporal motion vector prediction (TMVP) in the lower right corner of the current coding block is available, it is used as CPMV4. After obtaining the motion vectors of the four control points, affine merge candidates are constructed based on this motion information. Affine merging candidates are constructed according to the following combination order of CPMVs: {CPMV1,CPMV2,CPMV3},{CPMV1,CPMV2,CPMV4},{CPMV1,CPMV3,CPMV4},{CPMV2,CPMV3,CPMV4},{CPMV1,CPMV2},{CPMV1,CPMV3}. A combination of three CPMVs constitutes an affine merging candidate with 6 parameters, while a combination of two CPMVs constitutes an affine merging candidate with 4 parameters.

[0047] For example, the HACD affine candidate technique maintains a Historical Affine Table (HAT) to record recent affine block information. The HAT consists of 20 entries, each storing the reference index, control point predicted motion vector (CPMV), width, and height of the affine block. The HAT update strategy is similar to the Historical Motion Vector Prediction (HMVP) update strategy, as shown in Figure 5. In Figure 5, it is assumed that there is a table for storing HMVPs. Before the update, this table stores each HMVP in index order. Next, a redundancy check is performed, and HMVP2 is identified as a redundant HMVP using a specific algorithm. After the redundancy check, the table needs to be updated, including removing the redundant HMVP2 and adding HMVP candidate C. L-1The data was added to the table, completing the entire update process.

[0048] For example, when the current block is encoded using the affine Merge mode, virtual affine-coded neighbor blocks can be constructed. These virtual affine-coded neighbor blocks inherit the CPMV gradient of the previous affine-coded block and use the real motion vector (Real MV) extracted from the real neighbor blocks as the basic motion information. The derivation process of affine candidates under HACD is similar to that of inheriting affine candidates, but there are two differences. First, the basic motion information used is different; second, the source of the affine-coded neighbor blocks is different, and details can be found in Figure 6.

[0049] For example, UMVE mode is an encoding mode that optimizes the offset of CPMV in direct / skip mode. In this mode, offset values ​​can be used to modify CPMVs that are affine direct / skip candidates. For each CPMV, a distance index and a direction index are given in the bitstream. The distance offset table has a size of 5, as shown in Table 1 below. In Table 1, DistanceIDX (distance index) is an integer value ranging from 0 to 4. It is an identifier in the bitstream used to indicate the magnitude of the distance offset. During UMVE mode encoding, the encoder can select a suitable distance index based on the video content and encoding strategy, and include it in the bitstream to pass to the decoder. After receiving the bitstream, the decoder looks up the corresponding distance offset value in the distance offset table based on this distance index, thereby determining the specific magnitude of the offset of the CPMV. The Distance-offset (distance offset value) represents the specific size of the offset based on the CPMV, in pixels (pel). Different distance indices in the table correspond to different distance offset values, with the following specific relationships: When the distance index (DistanceIDX) is 0, the distance offset (Distance-offset) is 1 / 2-pel, meaning that when modifying the CPMV, it will be offset by half a pixel in the specified direction. When the distance index is 1, the distance offset is 1-pel, meaning an offset of one pixel. When the distance index is 2, the distance offset is 2-pel, meaning an offset of two pixels. When the distance index is 3, the distance offset is 4-pel, meaning an offset of four pixels. When the distance index is 4, the distance offset is 8-pel, meaning an offset of eight pixels. In this way, the encoder can flexibly select an appropriate distance index according to the motion of the video block and the encoding requirements, thereby adjusting the offset of the CPMV, making the predicted motion vector closer to the real motion, and improving the efficiency and quality of video encoding. Table 2 primarily clarifies the correspondence between the direction index and the horizontal (x) and vertical (y) offsets. The Direction IDX (direction index) is represented by two binary digits, with values ​​of 00, 01, 10, and 11. It is the identifier used in the bitstream to indicate the CPMV offset direction. During encoding, the encoder selects the appropriate direction index based on the video content and motion characteristics and inserts it into the bitstream. The decoder then uses this index to look up the corresponding offset direction in Table 2. The x (horizontal offset) column represents the offset in the horizontal direction, with the following specific values ​​and meanings: When the direction index is 00, x is +1, meaning an offset of one unit to the right (usually in pixels) in the horizontal direction. When the direction index is 01, x is -1, meaning an offset of one unit to the left in the horizontal direction.When the direction index is 10, the value of x is 0, indicating no offset in the horizontal direction. When the direction index is 11, the value of x is also 0, meaning no offset in the horizontal direction. The y (vertical offset) column represents the offset in the vertical direction, and its values ​​and meanings are as follows: When the direction index is 00, the value of y is 0, indicating no offset in the vertical direction. When the direction index is 01, the value of y is 0, meaning no offset in the vertical direction. When the direction index is 10, the value of y is +1, meaning an offset of one unit downward in the vertical direction. When the direction index is 11, the value of y is -1, meaning an offset of one unit upward in the vertical direction. As shown in Table 2, only one direction (x) or vertical (y) can have a motion vector difference. For each coding unit (CU), a flag can be used to indicate whether the CPMV has been modified. In unidirectional prediction, the offset distance is applied in the offset direction to generate the CPMV offset; while in bidirectional prediction, the offset distance is applied in the offset direction and its opposite direction, for prediction direction 0 and prediction direction 1 respectively, to generate the CPMV offset.

[0050] Table 1 Distance Offset Table

[0051] Table 2 Direction Offset Table

[0052] For example, when constructing the affine MVP candidate list for the current decoded block in the current frame, the first affine MVP candidate list for the current decoded block can be built first, following the order of inherited affine candidates, constructed affine candidates, and HACD affine candidates. Then, the affine MVP candidates in the first affine MVP candidate list are reordered. Specifically, in the first step, for inherited affine candidates, it is checked whether the adjacent blocks are affine coded blocks. If detected, their relevant motion vector gradients are calculated, and the candidates that meet the requirements are added to the list. For constructed affine candidates, candidates are generated by combining the adjacent translation motion information of control points and added to the list. For HACD affine candidates, virtual affine coded adjacent blocks are constructed using the historical affine table (HAT) and the motion information of real adjacent blocks, thereby obtaining the corresponding candidates and adding them to the list. The HAT records the affine coded blocks in the CTU row where the current block is located. In the second step, the reordering can be carried out according to specific rules or templates, such as placing candidates with a high probability of selection at the beginning of the candidate list. After reordering, the final affine MVP candidate list for the current decoded block is obtained.

[0053] For example, when constructing the affine MVP candidate list for the current decoded block in the current frame, the first affine MVP candidate list for the current decoded block in the current frame of the video stream can be constructed first, following the order of inheriting affine candidates, constructing affine candidates, HACD affine candidates, and HFACD affine candidates. Then, the affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list for the current decoded block. It should be noted that HFACD affine candidates can fully utilize the affine information in historical frames. Historical frames contain rich motion and structural information from past moments in the video sequence, which is then transformed into valid affine candidates and added to the first affine MVP candidate list.

[0054] For example, in addition to regular information, the video stream also includes a control flag, which plays a crucial role in constructing the affine motion vector prediction (MVP) candidate list. For instance, when constructing the affine MVP candidate list for the current decoded block in the current frame of the video stream, if the control flag value indicates that HFACD affine candidates should be used, the first affine MVP candidate list for the current decoded block can be constructed in the following order: first include inherited affine candidates, then add constructed affine candidates, then supplement with HACD affine candidates, and finally add HFACD affine candidates. If the control flag value indicates that HFACD affine candidates do not need to be used, the first affine MVP candidate list for the current decoded block can be constructed in the following order: first include inherited affine candidates, then add constructed affine candidates, and then supplement with HACD affine candidates.

[0055] For example, control flags can be set in the sequence header parameter set (also known as the sequence header syntax), the inter-frame prediction image header parameter set (also known as the inter-frame prediction image header syntax), or the coding unit parameter set (also known as the coding unit syntax), respectively generating different levels of control flags, including sequence-level, frame-level, or coding unit-level control flags. These control flags at different levels can determine whether to use HFACD affine candidates to construct the first affine MVP candidate list for the current decoded block. When a control flag is used to indicate the use of HFACD affine candidates when constructing the affine MVP candidate list for the current decoded block, the control flag can be set to a specific value (e.g., 1). Specifically, when the control flag is set in the sequence header, its value has a global indicative meaning. If the sequence-level control flag is set to 1, it means that during the decoding process of the entire video sequence, HFACD affine candidates will be used to construct the first affine MVP candidate list for all relevant decoded blocks. If the control flag is set in the inter-frame prediction image header, a frame-level control flag is formed. When the frame-level control flag of a frame is set to 1, the first affine MVP candidate list is constructed using HFACD affine candidates only for all decoded blocks within that frame. If the control flag is set in the coding unit parameter set, a coding unit-level control flag is formed. When the control flag of a coding unit is set to 1, the first affine MVP candidate list is constructed using HFACD affine candidates only for that coding unit.

[0056] It is worth noting that in practical applications, multiple levels of control flags may coexist with different values. Generally, a priority rule is followed to determine whether to ultimately use the HFACD affine candidate list. For example, the coding unit-level control flag has the highest priority, followed by the frame-level, and finally the sequence-level. That is, when the coding unit-level control flag has an explicit indication, the setting at the coding unit level is followed first; if the coding unit level is not set or has no explicit indication, the frame-level control flag is referenced; if the frame level also has no valid indication, then the sequence-level control flag is used.

[0057] It should be noted that this embodiment does not limit the specific value of the control flag. The value can be set to more than 1, as long as the value can indicate whether to use HFACD affine candidates to construct the first affine MVP candidate list of the current decoding block.

[0058] For example, the control identifier may include multiple control sub-identifiers set in different levels of parameter sets, which may collectively indicate whether to use HFACD affine candidates to construct the first affine MVP candidate list for the current decoded block.

[0059] For example, these control sub-identifiers may include a first control sub-identifier and a second control sub-identifier. The setting positions of the first control sub-identifier and the second control sub-identifier may include the following two cases: Case 1: The first control sub-identifier is set in the sequence header parameter set, and the second control sub-identifier is set in the inter-frame prediction image header parameter set; Case 2: The first control sub-identifier is set in the inter-frame prediction image header parameter set, and the second control sub-identifier is set in the coding unit parameter set.

[0060] For example, when it is necessary to determine whether to use HFACD affine candidates based on the values ​​of these control sub-identifiers, and thus construct the first affine MVP candidate list for the current decoded block in the current frame, four rules can be formulated for the case where the first control sub-identifier is set in the sequence header parameter set and the second control sub-identifier is set in the inter-frame prediction image header parameter set: Rule 1: Both levels of sub-identifiers indicate the use of HFACD affine candidates; Rule 2: The first sub-identifier indicates use, and the second sub-identifier does not indicate use; Rule 3: The first sub-identifier does not indicate use, and the second sub-identifier indicates use; Rule 4: Neither level of sub-identifier indicates use. Specifically, for Rule 1, if both the value of the first control sub-identifier in the sequence header and the value of the second control sub-identifier in the inter-frame prediction image header indicate that HFACD affine candidates should be used, then the first affine MVP candidate list for the current decoded block is constructed in the order of inheriting affine candidates, constructing affine candidates, HACD affine candidates, and HFACD affine candidates. For Rule 2, when the first control sub-identifier in the sequence header indicates the use of HFACD affine candidates, but the second control sub-identifier in the inter-frame prediction image header does not, the first affine MVP candidate list is constructed only by considering inherited affine candidates, constructed affine candidates, and HACD affine candidates, since the second control sub-identifier negates the use of HFACD affine candidates at a more specific inter-frame prediction level. This follows a more granular control instruction to adapt to the coding requirements of specific frames. For Rule 3, if the first control sub-identifier in the sequence header does not indicate the use of HFACD affine candidates, but the second control sub-identifier in the inter-frame prediction image header indicates their use, the higher-level control identifier usually prevails. That is, HFACD affine candidates are not used, and the first affine MVP candidate list is constructed only in the order of inherited affine candidates, constructed affine candidates, and HACD affine candidates. This is because the settings in the sequence header are usually for overall control of the entire video sequence and have higher authority. For rule 4, when neither the first control sub-identifier in the sequence header nor the second control sub-identifier in the inter-frame prediction image header indicates the use of HFACD affine candidates, only inherited affine candidates, constructed affine candidates, and HACD affine candidates are used to construct the first affine MVP candidate list, excluding the use of HFACD affine candidates.

[0061] It should be noted that this implementation does not restrict the values ​​of the first and second control sub-identifiers, as long as the combination of their values ​​can indicate whether to use HFACD affine candidates to construct the first affine MVP candidate list for the current decoded block. For example, when the first control sub-identifier is set in the sequence header and the second control sub-identifier is set in the inter-frame prediction image header, the specific situation can be referred to Tables 3 and 4. Table 3 shows the sequence header with the first control sub-identifier hfacd_enable_flag added, and Table 4 shows the inter-frame prediction image header with the second control sub-identifier picture_hfacd_enable_flag added. For instance, when both hfacd_enable_flag and picture_hfacd_enable_flag indicate that HFACD affine candidates are used to construct the affine MVP candidate list for the current decoded block in the current frame of the video stream, the values ​​of hfacd_enable_flag and picture_hfacd_enable_flag can be set to 1 simultaneously. At this point, when constructing the first affine MVP candidate list for the current decoding block, the order is: inheriting affine candidates first, then constructing affine candidates, followed by HACD affine candidates, and finally HFACD affine candidates. During subsequent decoding, the values ​​of `hfacd_enable_flag` and `picture_hfacd_enable_flag` can be parsed from the bitstream. If both are 1, the decoder can perform the same affine candidate derivation process based on historical frames as the encoder, thereby ensuring consistency between encoding and decoding and guaranteeing that the quality of the decoded video matches the expectations during encoding.

[0062] Table 3. Sequence header parameter set with added hfacd_enable_flag control flag.

[0063] Table 4. Set of inter-frame prediction image header parameters with the added picture_hfacd_enable_flag control flag.

[0064] For example, when the first control sub-identifier is set in the inter-frame prediction image header and the second control sub-identifier is set in the coding unit, four related rules can be formulated, including: Rule 5: Both levels of sub-identifiers indicate the use of HFACD affine candidates; Rule 6: The first sub-identifier indicates use, the second sub-identifier does not indicate use; Rule 7: The first sub-identifier does not indicate use, the second sub-identifier indicates use; Rule 8: Neither level of sub-identifier indicates use. Specifically, for Rule 5, if the value of the first control sub-identifier in the inter-frame prediction image header and the value of the second control sub-identifier in the coding unit both indicate the use of HFACD affine candidates, the first affine MVP candidate list of the current decoding block is constructed in the order of inheriting affine candidates, constructing affine candidates, HACD affine candidates, and HFACD affine candidates to make full use of various affine candidate resources. For Rule 6, when the first control sub-identifier value in the inter-frame prediction image header indicates the use of HFACD affine candidates, but the second control sub-identifier value in the coding unit does not indicate its use, since the coding unit is a more granular coding object, the second control sub-identifier, which is closer to the specific coding block, should be used. HFACD affine candidates are not used; instead, the first affine MVP candidate list is constructed in the order of inherited affine candidates, constructed affine candidates, and HACD affine candidates. For Rule 7, if the first control sub-identifier value in the inter-frame prediction image header does not indicate the use of HFACD affine candidates, but the second control sub-identifier value in the coding unit parameter set indicates its use, the control sub-identifier of the higher-level inter-frame prediction image header is usually used. HFACD affine candidates are not used, and the first affine MVP candidate list is constructed in the order of inherited affine candidates, constructed affine candidates, and HACD affine candidates. For rule 8, when neither the first control sub-identifier in the inter-frame prediction image header nor the second control sub-identifier in the coding unit indicates the use of HFACD affine candidates, the first affine MVP candidate list is constructed using only inherited affine candidates, constructed affine candidates, and HACD affine candidates, without considering HFACD affine candidates.

[0065] As we understand it, video is composed of a series of consecutive image frames. In video coding, depending on the coding method, frames are mainly divided into three categories: I-frames (keyframes), P-frames (one-way prediction frames), and B-frames (two-way prediction frames). P-frames and B-frames are both inter-frame frames. Inter-frame frames utilize the temporal correlation between frames, encoding them by referencing information from other frames. When the current coded frame is the first inter-frame frame, it means that the frames preceding it were I-frames. In subsequent inter-frame predictive coding processes, it can serve as an important reference frame, providing prediction reference for subsequent inter-frame frames. For example, if a P-frame is the first inter-frame frame, then subsequent P-frames or B-frames may use it as a reference for motion estimation and compensation, encoding by comparing differences with it, thereby achieving data compression.

[0066] The following details the process of constructing the first affine MVP candidate list for the current decoded block under different inter-frame scenarios, as well as the update rules for the Historical Frame Affine Table (HFAT). It should be noted that the Historical Frame Affine Table can be implemented by maintaining a First-In-First-Out (FIFO) table with no more than N (N is a positive integer). This means that when the table is full, the earliest candidate to enter the table will be removed first, ensuring that candidates with earlier positions in the table are always affine blocks closer to the current frame in the encoding order. This mechanism ensures that the Historical Frame Affine Table always stores the latest and most relevant affine block information, providing effective data support for the HFACD affine candidate derivation of subsequent frames. As shown in Figure 7, suppose affine blocks A, B, C, D, and E enter the Historical Frame Affine Table in sequence. The first time they are added, since the table is empty, they enter the table directly in order. At this point, the table is full, reaching the maximum candidate number N = 5. The second time they are added, affine block F needs to be added to the table. Since the table is full, according to the first-in-first-out (FIFO) mechanism, the earliest affine block A is removed from the table, and the other affine blocks move forward one position in sequence, with F being added to the end of the table. During the third addition, another affine block G needs to enter the table. Similarly, the earliest affine block B is removed, the other affine blocks move forward, and G is added to the end of the table. In this way, the historical frame affine table always maintains no more than N affine block information, and candidates with earlier positions in the table are always closer to the current frame in terms of encoding order.

[0067] For example, when the current frame corresponding to the current decoded block is the first inter-frame frame, because there may be insufficient historical frame information to support the generation of HFACD affine candidates, the first affine MVP candidate list for the current decoded block only includes inherited affine candidates, constructed affine candidates, and HACD affine candidates. However, when the current frame is the second or subsequent inter-frame frame, because there is sufficient historical frame information to support the generation of HFACD affine candidates, the first affine MVP candidate list for the current decoded block includes inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates. The HFACD affine candidates are obtained from the historical frame affine table.

[0068] For example, the construction process of the historical frame affine table may include: if the current decoded block is a decoded block of an inter-frame in the current sequence (including the first inter-frame and the second or subsequent inter-frames), and the current decoded block is an affine decoded block of the first affine mode, then the affine decoded block is added to the historical frame affine table as a candidate for the subsequent frame's historical frame affine table (i.e., an HFACD affine candidate). If the current frame is an I-frame in the current sequence, then the historical frame affine table is cleared.

[0069] For example, if the current frame is an inter-frame frame in the current sequence whose frame number modulo M is zero, then the historical frame affine table is cleared, and if the current decoding block is an affine decoding block of the first affine mode, the affine decoding block is added to the historical frame affine table as a candidate for the historical frame affine table of subsequent frames, where M is an integer greater than or equal to 2; if the current frame is an inter-frame frame in the current sequence whose frame number modulo M is not zero, and the current decoding block is an affine decoding block of the first affine mode, then the affine decoding block is added to the historical frame affine table as a candidate for the historical frame affine table of subsequent frames.

[0070] Understandably, in video coding, an I-frame (Intra-coded picture) is encoded independently, without relying on information from other frames. It contains complete image information itself and has no direct temporal correlation with preceding or following frames. When the current frame is determined to be an I-frame, it means that the affine information about other frames previously stored in the historical frame affine table is of no help in encoding or decoding the current I-frame, because I-frames do not utilize these historical affine relationships to construct their own image. Therefore, to avoid useless information occupying space and to ensure that subsequent affine information can be correctly stored and used, the historical frame affine table needs to be cleared. Furthermore, if the remainder of the current frame number divided by an integer M (M≥2) is zero, the historical frame affine table is cleared. In this way, the historical frame affine table can be reset at certain frame intervals. For example, when M=2, the system checks every other frame. If the frame number is 0 when divided by 2, the historical frame affine table is cleared. Furthermore, if there is an affine decoding block in the first affine mode in the current frame, the reconstruction of the historical frame affine table can be triggered.

[0071] For example, the first affine mode encompasses at least one of the affine inter mode, affine direct mode, and affine skip mode. When the current frame is an inter-frame frame, the update rules for the historical frame affine table are as follows: Once an affine decoding block of the first affine mode is detected in the current frame, this affine decoding block can be added to the historical frame affine table as a candidate for subsequent frames. Specifically, depending on the position of the current frame in the frame sequence and the specific mode to which the affine decoding block belongs, there are several possibilities. Case 1: If the current frame is the first inter-frame frame and contains an affine coding block of the inter mode, these affine coding blocks are added to the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and contains an affine coding block of the inter mode, these affine coding blocks are also added to the historical frame affine table. Scenario 2: If the current frame is the first inter-frame frame and contains affine coded blocks in affine direct mode, add these affine coded blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in affine direct mode, similarly add these affine coded blocks to the historical frame affine table. Scenario 3: If the current frame is the first inter-frame frame and contains affine coded blocks in affine skip mode, add these affine coded blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in affine skip mode, similarly add these affine coded blocks to the historical frame affine table. Scenario 4: If the current frame is the first inter-frame frame and contains affine coded blocks in inter, direct, and skip modes, add these affine coded blocks to the historical frame affine table. If the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in inter, direct, and skip modes, similarly add these affine coded blocks to the historical frame affine table. Scenario 5: If the current frame is the first inter-frame frame and contains affine coded blocks in inter and direct modes, add these affine coded blocks to the historical frame affine table. If the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in inter and direct modes, similarly add these affine coded blocks to the historical frame affine table. Case 6: If the current frame is the first inter-frame frame and contains affine coded blocks in both inter and skip modes, add these affine coded blocks to the historical frame affine table. Similarly, if the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in both inter and skip modes, add these affine coded blocks to the historical frame affine table. Case 7: If the current frame is the first inter-frame frame and contains affine coded blocks in both direct and skip modes, add these affine coded blocks to the historical frame affine table. Similarly, if the current frame is the second or subsequent inter-frame frame and contains affine coded blocks in both direct and skip modes, add these affine coded blocks to the historical frame affine table.Through the above rules, the historical frame affine table can be continuously updated, providing richer historical information for subsequent video encoding or decoding processes, which helps to improve the accuracy and efficiency of video encoding and decoding.

[0072] For example, when the current frame is an inter-frame frame, an I-frame, or the result of taking the remainder of the current frame number with respect to an integer M (M≥2) is zero, the update rules for the historical frame affine table are as follows: Case 1: If the current frame is the first inter-frame frame and there are affine coding blocks in the inter mode, put these affine coding blocks into the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and there are affine coding blocks in the inter mode, also put these affine coding blocks into the historical frame affine table; if the current frame is an I-frame, clear the historical frame affine table; if the result of taking the remainder of the current frame number with respect to an integer M (M≥2) is zero, and there are affine coding blocks in the inter mode, also put these affine coding blocks into the historical frame affine table. Scenario 2: If the current frame is the first inter-frame frame and there are affine coded blocks in affine direct mode, add these affine coded blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and there are affine coded blocks in affine direct mode, add these affine coded blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero and there are affine coded blocks in affine direct mode, add these affine coded blocks to the historical frame affine table as well. Case 3: If the current frame is the first inter-frame frame and there are affine coded blocks in the affine skip mode, add these affine coded blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame frame and there are affine coded blocks in the affine skip mode, add these affine coded blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero and there are affine coded blocks in the affine skip mode, add these affine coded blocks to the historical frame affine table as well. Case 4: If the current frame is the first inter-frame and contains affine coding blocks in affine inter, affine direct, and affine skip modes, add these affine coding blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame and contains affine coding blocks in affine inter, affine direct, and affine skip modes, add these affine coding blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero, and contains affine coding blocks in affine inter, affine direct, and affine skip modes, add these affine coding blocks to the historical frame affine table as well.Case 5: If the current frame is the first inter-frame and contains affine coding blocks in both inter and direct modes, add these affine coding blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame and contains affine coding blocks in both inter and direct modes, add these affine coding blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero, and contains affine coding blocks in both inter and direct modes, add these affine coding blocks to the historical frame affine table as well. Case 6: If the current frame is the first inter-frame and contains affine coding blocks in both inter and skip modes, add these affine coding blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame and contains affine coding blocks in both inter and skip modes, add these affine coding blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero, and contains affine coding blocks in both inter and skip modes, add these affine coding blocks to the historical frame affine table as well. Case 7: If the current frame is the first inter-frame and contains affine coded blocks in affine direct and affine skip modes, add these affine coded blocks to the historical frame affine table; if the current frame is the second or subsequent inter-frame and contains affine coded blocks in affine direct and affine skip modes, add these affine coded blocks to the historical frame affine table as well; if the current frame is an I-frame, clear the historical frame affine table; if the frame number of the current frame modulo an integer M (M≥2) is zero, and contains affine coded blocks in affine direct and affine skip modes, add these affine coded blocks to the historical frame affine table as well.

[0073] For example, the first affine MVP candidate list for the current decoded block is constructed in the order of inheriting affine candidates, constructing affine candidates, HACD affine candidates, and HFACD affine candidates. The number of affine MVP candidates in this list is no greater than Q, where Q is a positive integer. In practical applications, the value of Q can be set to 11.

[0074] For example, after constructing the first affine MVP candidate list for the current decoding block in the current frame of the video bitstream, the affine MVP candidates in the list can be further reordered to obtain the final affine MVP candidate list for the current decoding block. The specific process of this reordering is shown in Figure 8, which includes, but is not limited to, steps S810 and S820.

[0075] Step S810: Perform template matching-based cost calculation for each affine MVP candidate in the first affine MVP candidate list to obtain the matching cost of each affine MVP candidate in the first affine MVP candidate list.

[0076] Step S820: Reorder the affine MVP candidates in the first affine MVP candidate list in ascending or descending order according to the matching cost to obtain the affine MVP candidate list of the current decoding block.

[0077] It should be noted that template matching is a coding technique used to refine the motion information of the current coding unit. It minimizes the matching error between templates by finding the optimal motion signature (MV) between the current image and the reference image. In video coding, template matching can utilize information from neighboring blocks to adjust the MV by minimizing the matching error, making the MV of the current coding unit more accurate, thereby improving prediction accuracy and coding efficiency.

[0078] For example, step S810 aims to calculate the matching cost for each affine MVP candidate in the first affine MVP candidate list. The matching cost reflects the quality of each candidate in template matching, and calculating the cost quantifies the fit of each candidate with the current coding requirements. Using template matching techniques, a motion vector (MV) is found that minimizes the matching error between the template of the current image (typically the top and / or left adjacent blocks of the current coding unit) and the template of the reference image, as shown in Figure 9. The smaller the matching error, the lower the matching cost of the corresponding affine MVP candidate, indicating that the candidate is more suitable at the template matching level.

[0079] For example, in step S820, the affine MVP candidates in the first affine MVP candidate list are reordered in ascending order according to the matching cost, that is, candidates with lower matching costs are placed at the beginning of the list, i.e., candidates with higher selection probabilities are prioritized. The advantage of this is that in subsequent encoding processes, the encoder can encode the candidate indices of affine candidates with higher selection probabilities using fewer bits. By reordering, candidates more likely to be selected are placed at the front, achieving the goal of saving encoding bits and thus improving video compression performance. Prioritizing candidates with lower matching costs reduces unnecessary encoding attempts, lowers encoding complexity, and improves encoding efficiency.

[0080] For example, a first affine MVP candidate list is constructed according to inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates. This list can cover affine MVP candidates of inherited affine candidate types, constructed affine candidate types, HACD affine candidate types, and HFACD affine candidate types. When reordering the affine MVP candidates in the first affine MVP candidate list according to the matching cost, each type of affine candidate in the first affine MVP candidate list (inherited affine candidate, constructed affine candidate, HACD affine candidate, and HFACD affine candidate) can be considered. The template-matching-based cost calculation is performed on affine candidates (one of the following: constructed affine candidates, HACD affine candidates, and HFACD affine candidates), or any two of each of the following two types of affine candidates (inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates), or any three of each of the following three types of affine candidates (inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates), or all four types of affine candidates (inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates), and the candidate list is reordered in ascending order. For example, only HFACD affine candidates are reordered, with candidates with lower template costs positioned closer to HACD affine candidates in the affine candidate list.

[0081] For example, after obtaining the affine MVP candidate list for the current decoding block, the encoder can retrieve the affine candidate corresponding to the candidate index from the affine MVP candidate list and decode the current decoding block based on the retrieved affine MVP candidate. Specifically, during video encoding, the encoder can select the most suitable affine candidate for the current decoding block from the affine MVP candidate list. To ensure the decoder accurately knows which candidate the encoder has selected, the encoder can write the candidate's index in the affine MVP candidate list (i.e., the candidate index) into the video bitstream. This candidate index can be viewed as a pointer to a specific affine candidate, which the decoder can use to find the corresponding affine candidate from the affine MVP candidate list. Specifically, after the decoder completes the construction of the affine MVP candidate list for the current decoding block, it can locate and retrieve the corresponding affine candidate from the affine MVP candidate list based on this candidate index. This affine candidate contains key information describing the motion of the current decoding block, such as motion vectors and motion parameters. In affine Merge mode, the decoder can use the motion information of the retrieved affine candidate to predict the motion of the current decoding block. Specifically, it predicts the position and shape of the current decoded block in the reference frame based on the motion vectors and motion parameters in the affine candidates. Then, it compares the predicted block with the current decoded block, calculates the prediction error, and decodes and reconstructs based on the prediction error to obtain the final decoding result of the current decoded block. In the affine UMVE mode, in addition to utilizing the basic motion information of the extracted affine candidates, it also modifies the control point predicted motion vector (CPMV) of the affine candidates using offset values. The decoder performs corresponding offset operations on the CPMV based on the distance and direction indices provided in the bitstream to further optimize the accuracy of motion prediction. Then, based on the offset motion vector, it performs motion compensation prediction and error decoding reconstruction to complete the decoding of the current decoded block.

[0082] In addition, in order to achieve efficient encoding of coded blocks in video frames, this embodiment proposes a video frame encoding method. Referring to Figure 10, Figure 10 is a flowchart of video frame encoding provided in this embodiment of the application, which includes, but is not limited to, steps S1010 to S1030.

[0083] Step S1010: Construct an affine MVP candidate list for the current coding block in the video frame, wherein the affine MVP candidate list includes multiple affine MVP candidates, and the candidate types corresponding to the multiple affine MVP candidates may include inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types.

[0084] Step S1020: Perform rate-distortion-based cost calculation for each affine MVP candidate in the affine MVP candidate list to obtain the optimization cost of each affine MVP candidate in the affine MVP candidate list.

[0085] Step S1030: Based on the affine MVP candidate with the lowest optimization cost, encode the current coding block according to the affine Merge mode or the affine UMVE mode, and encode the candidate index of the affine MVP candidate with the lowest optimization cost into the video bitstream and transmit it to the decoding end.

[0086] For example, the purpose of step S1010 is to construct a list containing multiple types of affine candidates for the current coded block, so as to select the optimal motion prediction in subsequent steps. The affine MVP candidate list includes inherited affine candidates and constructed affine candidates, and includes at least one of HACD affine candidates and HFACD affine candidates. Specifically, inherited affine candidates: obtain motion information from adjacent affine coded blocks, and use the motion correlation between adjacent blocks in the spatial domain to provide a basis for prediction of the current block. Constructed affine candidates: generate by combining the adjacent translational motion information of each control point, and comprehensively utilize the motion vectors of adjacent blocks to construct candidates suitable for the current block. HACD affine candidates: generate candidates based on historical affine candidate derivation, by maintaining a historical affine table to record recent affine coded block information, and constructing virtual affine coded adjacent blocks. HFACD affine candidates: generate candidates based on historical frame affine candidate derivation, by mining affine information in historical frames, and providing more motion prediction options for the current block.

[0087] It should be noted that the specific definitions and generation methods of inheriting affine candidates, constructing affine candidates, HACD affine candidates, and HFACD affine candidates in this embodiment are consistent with the corresponding content in the decoding method described above. Specific details can be found in the previous text and will not be repeated here.

[0088] For example, in step S1010, constructing the affine MVP candidate list for the current coding block in the video frame can be done in two ways: Method 1: First, construct the first affine MVP candidate list for the current coding block in the video frame according to the order of inherited affine candidates, constructed affine candidates, and HACD affine candidates; then, reorder the affine MVP candidates in the first affine MVP candidate list to obtain the affine MVP candidate list for the current coding block. Method 2: First, construct the first affine MVP candidate list for the current coding block in the video frame according to the order of inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates; then, reorder the affine MVP candidates in the first affine MVP candidate list to finally obtain the affine MVP candidate list for the current coding block.

[0089] For example, when the video frame corresponding to the current coding block is the first inter-frame frame, there may be insufficient historical frame information to support the generation of HFACD affine candidates. Therefore, the first affine MVP candidate list for the current coding block only includes inherited affine candidates, constructed affine candidates, and HACD affine candidates. However, when the video frame is the second or subsequent inter-frame frame, there is sufficient historical frame information to support the generation of HFACD affine candidates. Therefore, the first affine MVP candidate list for the current coding block includes inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates. The HFACD affine candidates are obtained from the historical frame affine table. The historical frame affine table, as a data structure, stores affine coding block information from historical frames. This information can provide additional motion prediction candidates for the coding of subsequent frames, thereby improving coding efficiency and video quality.

[0090] For example, the construction process of the historical frame affine table may include: if the current coded block is a coded block of an inter-frame in the current sequence (including the first inter-frame and the second or subsequent inter-frames), and the current coded block is an affine coded block of the first affine mode, then the affine coded block is added to the historical frame affine table as a candidate for the subsequent frame's historical frame affine table (i.e., an HFACD affine candidate). If the video frame is an I-frame in the current sequence, then the historical frame affine table is cleared.

[0091] For example, if the video frame is an inter-frame frame in the current sequence whose frame number modulo M is zero, then the historical frame affine table is cleared, and if the current coding block is an affine coding block of the first affine mode, the affine coding block is added to the historical frame affine table as a candidate for the historical frame affine table of subsequent frames, where M is an integer greater than or equal to 2; if the video frame is an inter-frame frame in the current sequence whose frame number modulo M is not zero, and the current coding block is an affine coding block of the first affine mode, then the affine coding block is added to the historical frame affine table as a candidate for the historical frame affine table of subsequent frames.

[0092] It should be noted that the specific process of constructing the first affine MVP candidate list of the current coding block in the video frame in this embodiment is similar to the process of constructing the first affine MVP candidate list of the current decoding block in the previous decoding method embodiments. Furthermore, the definition and update method of the historical frame affine table in this embodiment are the same as those described in the previous embodiments. Given that the above content has been described in detail in the previous embodiments, it will not be repeated here to avoid repetition.

[0093] For example, the affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list for the current coding block. The specific process is as follows: First, for each affine MVP candidate in the first affine MVP candidate list, a template matching-based cost calculation is performed. This calculation process yields the matching cost corresponding to each affine MVP candidate in the first affine MVP candidate list. This matching cost reflects the quality of each candidate in template matching; the smaller the matching error and the lower the matching cost, the more suitable the candidate is in terms of template matching. Next, based on the obtained matching cost, the affine MVP candidates in the first affine MVP candidate list are reordered in ascending order. Candidates with lower matching costs are placed at the beginning of the list, that is, candidates with a higher probability of selection are prioritized. After this reordering operation, the affine MVP candidate list for the current coding block is finally obtained. In this way, during subsequent encoding processes, the encoder can find suitable candidates more quickly, reducing search time and computational load, thereby improving the efficiency of video encoding.

[0094] For example, the first affine MVP candidate list constructed based on inherited affine candidates, constructed affine candidates, HACD affine candidates, and HFACD affine candidates can cover affine MVP candidates of the inherited affine candidate type, constructed affine candidate type, HACD affine candidate type, and HFACD affine candidate type. When reordering the affine MVP candidates in the first affine MVP candidate list according to the matching cost to obtain the affine MVP candidate list for the current coding block, the specific operation is as follows: At least one of the four types of affine MVP candidates in the first affine MVP candidate list—inherited affine candidate type, constructed affine candidate type, HACD affine candidate type, and HFACD affine candidate type—can be reordered according to the matching cost. By reordering the candidates of the above types in ascending order according to the matching cost, candidates that better match the motion features of the current coding block can be placed at the top of the candidate list. In this way, during subsequent encoding, the encoder can quickly select the optimal candidate from the top positions, reducing search time and computational load, thereby improving encoding efficiency. Meanwhile, by prioritizing candidates with high matching degree, motion prediction becomes more accurate, which can effectively reduce coding error, improve the quality of reconstructed video, and ultimately build a suitable affine MVP candidate list for the current coding block.

[0095] It should be noted that the specific process of reordering the affine MVP candidates in the first affine MVP candidate list is similar to the reordering process in the previous decoding method embodiment. For details, please refer to the detailed description in the previous embodiment. To avoid repetition, it will not be repeated here.

[0096] For example, the video stream contains a control identifier, and the selection of whether to execute mode one or mode two in step S1010 is closely related to this control identifier. For instance, if mode two (i.e., the mode that includes HFACD affine candidates when constructing the affine MVP candidate list) is required, the value of the control identifier can be set to a specific value used to indicate the use of HFACD affine candidates. In this way, the encoder can flexibly select the appropriate construction method according to the setting of the control identifier to adapt to the encoding requirements of different video content, thereby improving the efficiency and quality of video encoding.

[0097] For example, control flags can be set in the sequence header parameter set, the inter-frame prediction image header parameter set, or the coding unit parameter set, respectively generating sequence-level, frame-level, or coding unit-level control flags. These control flags at different levels determine whether to use HFACD affine candidates to construct the first affine MVP candidate list for the current coding block. Specifically, when the control flag is set in the sequence header, its value has a global indicative meaning. If the sequence-level control flag is set to 1, it means that during the encoding process of the entire video sequence, HFACD affine candidates will be used to construct the first affine MVP candidate list for all relevant coding blocks. If the control flag is set in the inter-frame prediction image header, a frame-level control flag is formed. When the frame-level control flag of a certain frame is set to 1, HFACD affine candidates are used only for all coding blocks within that frame to construct the first affine MVP candidate list. If the control flag is set in the coding unit, a coding unit-level control flag is formed. When the control flag of a certain coding unit is set to 1, HFACD affine candidates are used only for that coding block to construct the first affine MVP candidate list. It should be noted that this embodiment does not limit the specific value of the control flag. The value can be set to more than 1, as long as the value can indicate whether to use HFACD affine candidates to construct the first affine MVP candidate list of the current coding block.

[0098] For example, the control identifiers in the video bitstream can be divided into a first control sub-identifier and a second control sub-identifier. The setting positions of these two control identifiers can be in two scenarios: Scenario 1: The first control sub-identifier is set in the sequence header parameter set, and the second control sub-identifier is set in the inter-frame prediction image header parameter set; Scenario 2: The first control sub-identifier is set in the inter-frame prediction image header parameter set, and the second control sub-identifier is set in the coding unit parameter set. For both of these different setting scenarios, various rules can be formulated to indicate whether to use HFACD affine candidates to construct an affine MVP candidate list. Specifically, in Scenario 1, the activation of HFACD affine candidates can be determined based on the combination of values ​​of the control sub-identifiers in the sequence header and inter-frame prediction image header; in Scenario 2, the judgment is made based on the values ​​of the control sub-identifiers in the inter-frame prediction image header and the coding unit. It should be noted that the process of formulating these rules is similar to the rules specified based on the setting positions of the first and second control sub-identifiers in the decoding method described above; please refer to the relevant descriptions above for details, which will not be repeated here.

[0099] It should be noted that the specific process of constructing the affine MVP candidate list of the current coding block in the video frame in this embodiment is similar to the process of constructing the affine MVP candidate list of the current decoding block in the current frame of the video bitstream described above. For specific details, please refer to the previous content, which will not be repeated here.

[0100] For example, the number of affine MVP candidates in the affine MVP candidate list is no greater than Q, where Q is a positive integer. In practical applications, the value of Q can be set to 11.

[0101] For example, in step S1020, after obtaining the affine MVP candidate list, a rate-distortion optimization-based cost calculation can be performed on each affine MVP candidate in the list. Rate-distortion optimization is a method that comprehensively considers the coding bit rate (rate) and the reconstruction image distortion (distortion). By calculating the rate-distortion cost of different candidates, the performance of each candidate in terms of coding efficiency and image quality can be quantified, and the optimization cost of each affine MVP candidate can be obtained.

[0102] For example, in step S1030, based on the optimization cost calculated in step S1020, the affine MVP candidate with the lowest optimization cost is selected. This candidate is optimal in terms of both coding efficiency and image quality. Then, this candidate is used to encode the current coding block based on either the affine Merge mode or the affine UMVE mode. Finally, the candidate index of the affine MVP candidate with the lowest optimization cost is encoded into the video bitstream and transmitted to the decoding end. The decoding end can retrieve the corresponding candidate from its own constructed affine MVP candidate list based on this candidate index, thereby achieving accurate decoding.

[0103] In addition, one embodiment of this application discloses an electronic device, which includes at least one processor; at least one memory for storing at least one program; and when the at least one program is executed by the at least one processor, it implements the decoding method as in any of the preceding embodiments, or implements the frame encoding method as in any of the preceding embodiments.

[0104] In addition, one embodiment of this application discloses a computer-readable storage medium storing computer-executable instructions for performing a decoding method as described in any of the preceding embodiments, or for performing a frame encoding method as described in any of the preceding embodiments.

[0105] Furthermore, one embodiment of this application discloses a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the electronic device to perform a decoding method as described in any of the preceding embodiments, or to perform a frame encoding method as described in any of the preceding embodiments.

[0106] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0107] The above is a detailed description of the preferred embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the essence of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for decoding a video stream, comprising: Receive the video stream, which includes candidate indices for either the affine Merge mode or the affine UMVE mode; Construct an affine motion vector prediction MVP candidate list for the current decoded block in the current frame. The affine MVP candidate list includes multiple affine MVP candidates. The candidate types corresponding to the multiple affine MVP candidates include inherited affine candidate types, constructed affine candidate types, and at least one of the following: HACD affine candidate type derived from historical affine candidate types and HFACD affine candidate type derived from historical frame affine candidate types. The affine MVP candidate corresponding to the current decoding block is retrieved from the affine MVP candidate list according to the candidate index, and the current decoding block is decoded according to the retrieved affine MVP candidate.

2. The decoding method according to claim 1, wherein, The construction of the affine MVP candidate list for the current decoded block in the current frame includes: Construct the first affine MVP candidate list for the current decoding block in the current frame according to the inherited affine candidate, constructed affine candidate, and HACD affine candidate; The affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list of the current decoding block.

3. The decoding method according to claim 1, wherein, The construction of the affine MVP candidate list for the current decoded block in the current frame includes: Construct the first affine MVP candidate list for the current decoding block in the current frame according to the inherited affine candidate, constructed affine candidate, HACD affine candidate, and HFACD affine candidate; The affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list of the current decoding block.

4. The decoding method according to claim 3, wherein: If the current frame is the first inter-frame frame in the current sequence, the first affine MVP candidate list of the current decoding block includes the inherited affine candidate, the constructed affine candidate, and the HACD affine candidate; If the current frame is the second or subsequent inter-frame in the current sequence, the first affine MVP candidate list of the current decoding block includes the inherited affine candidate, the constructed affine candidate, the HACD affine candidate, and the HFACD affine candidate.

5. The decoding method according to claim 4, wherein, The HFACD affine candidates are obtained from the historical frame affine table.

6. The decoding method according to claim 5, wherein, The construction process of the historical frame affine table includes the following steps: If the current frame is an inter-frame frame in the current sequence, and the current decoding block is an affine decoding block of the first affine mode, the affine decoding block is placed into the historical frame affine table as a candidate for the historical frame affine mapping of subsequent frames. If the current frame is an I-frame in the current sequence, clear the affine table of the historical frames.

7. The decoding method according to claim 6, wherein, If the current frame is an inter-frame frame in the current sequence, and the current decoded block is an affine decoded block of the first affine mode, then the affine decoded block is added to the historical frame affine table as a candidate for historical frame affine mapping for subsequent frames, including: If the current frame is an inter-frame frame in the current sequence whose frame number modulo M is zero, the historical frame affine table is cleared, and if the current decoding block is an affine decoding block of the first affine mode, the affine decoding block is placed into the historical frame affine table as a historical frame affine candidate for subsequent frames, where M is an integer greater than or equal to 2. If the current frame is an inter-frame frame in the current sequence whose frame number modulo M is not zero, and the current decoding block is an affine decoding block of the first affine mode, then the affine decoding block is placed into the historical frame affine table as a candidate for the historical frame affine mapping of subsequent frames.

8. The decoding method according to any one of claims 5 to 7, wherein, The historical frame affine table is implemented by maintaining a first-in-first-out table with no more than N affine candidate numbers, where N is an integer greater than zero.

9. The decoding method according to any one of claims 6 to 7, wherein, The first affine mode includes at least one of the following: Affine inter mode; Affine direct mode; Affine skip mode.

10. The decoding method according to claim 1, wherein, The number of affine MVP candidates in the affine MVP candidate list is no greater than Q, where Q is an integer greater than zero.

11. The decoding method according to claim 10, wherein, The value of Q is 11.

12. The decoding method according to claim 2 or 3, wherein, The step of reordering the affine MVP candidates in the first affine MVP candidate list to obtain the affine MVP candidate list for the current decoding block includes: For each affine MVP candidate in the first affine MVP candidate list, perform template matching-based cost calculation to obtain the matching cost of each affine MVP candidate in the first affine MVP candidate list. The affine MVP candidates in the first affine MVP candidate list are reordered in ascending or descending order according to the matching cost to obtain the affine MVP candidate list of the current decoding block.

13. The decoding method according to claim 12, wherein, The candidate types corresponding to the affine MVP candidates in the first affine MVP candidate list include inherited affine candidate types, constructed affine candidate types, HACD affine candidate types, and HFACD affine candidate types. The step of reordering the affine MVP candidates in the first affine MVP candidate list according to the matching cost to obtain the affine MVP candidate list of the current decoding block includes: Based on the matching cost, the affine MVP candidates in the first affine MVP candidate list of at least one of the following types are reordered in ascending or descending order to obtain the affine MVP candidate list of the current decoding block: The inherited affine candidate type; The construction of affine candidate types; The HACD affine candidate type; The HFACD affine candidate type.

14. The decoding method according to claim 3, wherein, The video stream also includes a control identifier, which indicates whether the HFACD affine candidate is used when constructing the affine MVP candidate list for the current decoding block.

15. The decoding method according to claim 14, wherein, The control identifier is set in any one of the sequence header parameter set, the inter-frame prediction image header parameter set, and the coding unit parameter set.

16. The decoding method according to claim 14, wherein, The control identifier includes multiple control sub-identifiers set in different levels of parameter sets; Multiple control sub-identifiers are used together to indicate whether the HFACD affine candidate is used when constructing the affine MVP candidate list for the current decoding block.

17. The decoding method according to claim 16, wherein, The plurality of control sub-identifiers includes a first control sub-identifier and a second control sub-identifier, and the setting positions of the first control sub-identifier and the second control sub-identifier include one of the following: The first control sub-identifier is set in the sequence header parameter set, and the second control sub-identifier is set in the inter-frame prediction image header parameter set; The first control sub-identifier is set in the inter-frame prediction image header parameter set, and the second control sub-identifier is set in the coding unit parameter set.

18. A method for encoding video frames, comprising: Construct an affine MVP candidate list for the current coding block in the video frame. The affine MVP candidate list includes multiple affine MVP candidates. The candidate types corresponding to the multiple affine MVP candidates include inherited affine candidate types, constructed affine candidate types, and at least one of HACD affine candidate types and HFACD affine candidate types. For each affine MVP candidate in the affine MVP candidate list, a cost calculation based on rate distortion optimization is performed to obtain the optimization cost of each affine MVP candidate in the affine MVP candidate list. Based on the affine MVP candidate with the lowest optimization cost, the current coding block is encoded using either the affine Merge mode or the affine UMVE mode, and the candidate index of the affine MVP candidate with the lowest optimization cost is encoded into the video bitstream and transmitted to the decoding end.

19. The encoding method according to claim 18, wherein, The construction of the affine MVP candidate list for the current coded block in the video frame includes: Construct the first affine MVP candidate list for the current coding block in the video frame according to the inherited affine candidate, constructed affine candidate, and HACD affine candidate; The affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list for the current coding block.

20. The encoding method according to claim 18, wherein, The construction of the affine MVP candidate list for the current coded block in the video frame includes: Construct the first affine MVP candidate list for the current coding block in the video frame according to the inherited affine candidate, constructed affine candidate, HACD affine candidate, and HFACD affine candidate; The affine MVP candidates in the first affine MVP candidate list are reordered to obtain the affine MVP candidate list for the current coding block.

21. The encoding method according to claim 20, wherein: If the video frame is the first inter-frame frame in the current sequence, the first affine MVP candidate list of the current coding block includes the inherited affine candidate, the constructed affine candidate, and the HACD affine candidate; If the video frame is the second or subsequent inter-frame in the current sequence, the first affine MVP candidate list of the current coding block includes the inherited affine candidate, the constructed affine candidate, the HACD affine candidate, and the HFACD affine candidate.

22. The encoding method according to claim 21, wherein, The HFACD affine candidates are obtained from the historical frame affine table.

23. The encoding method according to claim 22, wherein, The construction process of the historical frame affine table includes the following steps: If the video frame is an inter-frame frame in the current sequence, and the current coding block is an affine coding block of the first affine mode, the affine coding block is placed into the historical frame affine table as a candidate for the historical frame affine mapping of subsequent frames. If the video frame is an I-frame in the current sequence, clear the affine table of the historical frames.

24. The encoding method according to claim 23, wherein, If the video frame is an inter-frame frame in the current sequence, and the current coding block is an affine coding block of the first affine mode, then the affine coding block is added to the historical frame affine table as a candidate for historical frame affine mapping for subsequent frames, including: If the video frame is an inter-frame frame in the current sequence whose frame number modulo M is zero, the historical frame affine table is cleared, and if the current coding block is an affine coding block of the first affine mode, the affine coding block is placed into the historical frame affine table as a historical frame affine candidate for subsequent frames, where M is an integer greater than or equal to 2. If the video frame is an inter-frame frame in the current sequence whose frame number modulo M is not zero, and the current coding block is an affine coding block of the first affine mode, the affine coding block is placed into the historical frame affine table as a candidate for historical frame affine mapping of subsequent frames.

25. The encoding method according to any one of claims 22 to 24, wherein, The historical frame affine table is implemented by maintaining a first-in-first-out table with no more than N affine candidate numbers, where N is an integer greater than zero.

26. The encoding method according to any one of claims 23 to 24, wherein, The first affine mode includes at least one of the following: Affine inter mode; Affine direct mode; Affine skip mode.

27. The encoding method according to claim 18, wherein, The number of affine MVP candidates in the affine MVP candidate list is no greater than Q, where Q is an integer greater than zero.

28. The encoding method according to claim 27, wherein, The value of Q is 11.

29. The encoding method according to claim 19 or 20, wherein, The step of reordering the affine MVP candidates in the first affine MVP candidate list to obtain the affine MVP candidate list for the current coding block includes: For each affine MVP candidate in the first affine MVP candidate list, perform template matching-based cost calculation to obtain the matching cost of each affine MVP candidate in the first affine MVP candidate list. The affine MVP candidates in the first affine MVP candidate list are reordered in ascending or descending order according to the matching cost to obtain the affine MVP candidate list of the current coding block.

30. The encoding method according to claim 29, wherein, The candidate types corresponding to the affine MVP candidates in the first affine MVP candidate list include inherited affine candidate types, constructed affine candidate types, HACD affine candidate types, and HFACD affine candidate types. The step of reordering the affine MVP candidates in the first affine MVP candidate list in ascending or descending order according to the matching cost to obtain the affine MVP candidate list of the current coding block includes: Based on the matching cost, the affine MVP candidates in the first affine MVP candidate list of at least one of the following types are reordered in ascending or descending order to obtain the affine MVP candidate list of the current coding block: The inherited affine candidate type; The affine candidate type is constructed; The HACD affine candidate type; The HFACD affine candidate type.

31. The encoding method according to claim 20, wherein, The video stream also includes a control identifier; the control identifier is used to indicate whether the HFACD affine candidate is used when constructing the affine MVP candidate list for the current coding block.

32. The encoding method according to claim 31, wherein, The control identifier is set in any one of the sequence header parameter set, the inter-frame prediction image header parameter set, and the coding unit parameter set.

33. The encoding method according to claim 31, wherein, The control identifier includes multiple control sub-identifiers set in different levels of parameter sets; Multiple control sub-identifiers are used together to indicate whether the HFACD affine candidate is used when constructing the affine MVP candidate list for the current coding block.

34. The encoding method according to claim 33, wherein, The plurality of control sub-identifiers includes a first control sub-identifier and a second control sub-identifier, and the setting positions of the first control sub-identifier and the second control sub-identifier include one of the following: The first control sub-identifier is set in the sequence header parameter set, and the second control sub-identifier is set in the inter-frame prediction image header parameter set; The first control sub-identifier is set in the inter-frame prediction image header parameter set, and the second control sub-identifier is set in the coding unit parameter set.

35. An electronic device comprising: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, it implements the video stream decoding method of any one of claims 1 to 17, or the video frame encoding method of any one of claims 18 to 34.

36. A computer-readable storage medium storing computer-executable instructions, wherein, The computer-executable instructions are used to execute the video stream decoding method according to any one of claims 1 to 17, or to execute the video frame encoding method according to any one of claims 18 to 34.

37. A computer program product comprising a computer program or computer instructions, wherein, The computer program or the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer program or the computer instructions from the computer-readable storage medium. The processor executes the computer program or the computer instructions, causing the electronic device to perform the video stream decoding method according to any one of claims 1 to 17, or the video frame encoding method according to any one of claims 18 to 34.

Images